Lesson 10 of 30, Module 1: The Whole Idea. You understand what MCP is, why it exists, and you have FELT the problem it solves.
What you can do after this lesson
Before reaching for a protocol or a server, ask two questions: where does this have to run, and who else has to use it. If it only ever runs in a shell you control, today, write the script. If it needs no shell, a second app, a second person, or a stop-and-ask step before anything gets written, build the server. That decision rule outlives MCP; it is how you choose between a quick script and shared infrastructure for any tool.
Downloads
- Module 1 checkpoint (scribe-checkpoint-m1.zip): working code as the module leaves it, so a broken session costs you nothing
- The course GitHub repo: every checkpoint, the README and the full lesson list
Prefer to read?
The written version of this part of the course is on Substack: https://genaiunplugged.substack.com/p/the-three-superpowers-of-mcp-tools.
Lesson transcript
Where we started
10 lessons ago you could not get an AI anywhere near your Google Drive. Today you know exactly why, and exactly what to build about it.
The map so far
Hello, and welcome to lesson 10 of the MCP Masterclass. This lesson is a quick recap of everything we have learned in the last 9 lessons. And we start with our map, as always.
6 lit boxes on the diagram. You, Claude Desktop, a second app, the client inside them, the pipe, and your Google Drive folder.
The box in the middle is still empty, and that is the whole point of what comes next.
Well, there is nothing new in this lesson. 7 points, and then module 2.
The 7 points
Point number 1. MCP is nothing but a universal remote for AI.
One handset, and it drives everything in the room. You connect a tool to the protocol one time, and every app that speaks it can use your tool.
Point number 2. Your machine is ready.
Python, uv, Node, Claude Desktop, and a scribe folder. You also know where the Claude Desktop settings file lives, and that paths inside it must be full paths.
Point number 3. Your robot user has a key to one folder.
A service account is a user with an email address and no human behind it. You shared one folder with it, and it can read and change what is in there.
It cannot make new files, and Scribe never needs to. Sharing the folder is what granted the access, not any role in the Cloud console. And every search names the folder, because a search by name alone comes back empty.
Point number 4. The script worked, and it still was not enough.
You wrote 14 lines and printed a real draft from Drive. That script is good, and there is nothing wrong with it.
Then Claude Desktop could not run it. Not because it has no shell, because it does have one, but because that shell sits in a sandbox in the cloud and cannot see your machine at all. That is reason number 1.
Then a second app needed its own glue. 2 jobs across 2 apps came to 4 pieces of glue, and it grows every time you add either one. That is reason number 2, and it has a name, which is the M×N problem.
Point number 5. One server fed 2 apps, with no code from you.
You installed the same server into 2 different apps, and both of them used it. You wrote 4 lines of settings and nothing else.
Multiplying turned into adding. That is M+N, and you did it with your hands rather than reading about it.
Point number 6. There are 3 pieces, and 1 of them is yours.
The host is the app you look at. The client hides inside the host. And the server is the small program you write.
You will never write a host or a client. You write servers, and every host comes free.
A server offers 3 kinds of thing. Tools are jobs it can do. Resources are things your AI can look at. And prompts are jobs you saved.
Point number 7. A tool describes itself, and a script cannot.
When a host connects, it asks your server what it can do. Your server answers with names, descriptions and input shapes.
That is reason number 3, and it is why nobody has to explain your tools in a prompt.
Reason number 4 is safety. A script runs with everything you can reach, while a tool call is approved one call at a time. The asking is done by the host, so in module 3 you add your own layer that travels with your server.
Script or server
And if you remember one thing from this whole module, remember the decision rule.
Where does this have to run, and who else has to use it?
A shell, only you, only today. Write the script.
No shell, or a second app, or a second person, or you want to be asked before anything gets written. Build the server.
Oh, and one more thing worth carrying forward. External intelligence. That is everything your model needs that sits outside its trained knowledge, and giving it that is the whole reason MCP exists.
What module 2 opens with
So what is coming next?
Module 2 opens with a wall.
There is an official Google Drive server. You will install it, and Claude will read every document in your folder perfectly.
Then you will ask it to fix that typo, and it will not. It cannot change anything at all, and the reason is written into the way it was built.
And that wall is where your first real build begins.
So where does our map stand at the end of module 1?
6 boxes lit, and 1 hole in the middle, which has been open since lesson 1.
In module 2 you finally fill it.
Bye now, and I will see you in the next lesson.
What we covered
- MCP is a universal remote for AI: connect a tool to the protocol once and every app that speaks it can use it.
- The machine and the robot user are both ready: Python, uv, Node, Claude Desktop, and a scribe folder, plus a service account holding a key to exactly one shared folder, which it can read and change but never create files in, and which every search must name.
- The plain script worked and still was not enough: Claude Desktop's shell cannot see your machine (reason 1), and a second app needs its own glue, which is the M times N problem (reason 2); one server installed into two apps turned that multiplying into adding, M plus N.
- There are three pieces and only one is ever yours to write, host, client, server, offering tools, resources, and prompts; a tool describes itself to any host that connects (reason 3), and a tool call is approved one call at a time rather than running with your whole shell (reason 4).
- The carry-forward decision rule: shell, only you, only today, write the script; no shell, or a second app, or a second person, or a stop-and-ask step, build the server. And external intelligence, everything the model needs from outside its training, is named as the whole reason MCP exists.
