Lesson 9 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
Choose the connection layer by two questions only, where the work has to run and who else has to use it, never by which technology is newer. A script wins when the work is local and single-user; a protocol wins the moment a second host, a second person, or a consent boundary enters the picture.
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
The question I get in every cohort
This is the question I get asked in every single cohort I teach, and my honest answer surprises people.
Hello, and welcome to lesson 9 of the MCP Masterclass. Last lesson we covered the 3 superpowers. Today we settle MCP against an API and against a plain command line tool. And we start with our map, as always.
Same 6 boxes. Well, this lesson adds no code and lights no box. It hands you a decision instead.
This is the most asked question about MCP, and I hear it in every single cohort I teach. One of my students asked it in plain words. What is the difference between an MCP and an API?
It is a good question, and the honest answer surprises people.
The three rivals picture, and why it is wrong
So what is the picture sitting underneath that question?
It is a picture of 3 rivals. 3 ways to connect AI to a tool, with MCP as the modern one that replaces the older two.
That picture is wrong, and it costs money. It makes you choose on what is new, instead of choosing on where the work has to happen.
What each one actually is
So let us understand each one of them in simple way.
An API is nothing but a way for one program to ask another program for something, over the network. Google Drive has one. Substack has one.
A command line tool is nothing but a program you run by typing its name. Your script from lesson 5 is one of those.
And an MCP server is nothing but a wrapper that describes some jobs, and offers them to any AI app.
Now notice one thing about those 3. Notice who each one was built to be read by.
An API was built for code to read. Some program on your side, written by a person, that already knows the address.
A command line tool was built for a person to read. You type the name, and you read what comes back.
An MCP server was built for a model to read. And that is why the other 2 want a person sitting in the middle.
MCP sits on top of an API
And here is the part that ends the argument.
MCP sits on top of an API. It does not compete with one.
Look at what Scribe will do. It calls the Google Drive API underneath. And in module 4 it calls the Substack API as well.
Every MCP server in the world does one of 3 things underneath. It calls an API, or it reads a file, or it runs a command.
Wrapping is the entire job. So asking whether to use MCP or an API is a bit like asking whether to use a plug socket or electricity.
But that wrapper does one thing the other 2 cannot do.
Remember from last lesson. Your server hands over its own list of jobs, in plain words, the moment a host connects.
So you add a job to your server, you restart, and the model sees it. Nobody else has to be told.
Now hold that next to an API. A person wrote code that knows the address. Change the address, and that code breaks wherever it happens to live.
One of those you keep fixing by hand. The other one describes itself every time it connects.
Two questions that decide it
So what is the thing that actually decides it?
Forget which one is newer, and ask yourself 2 questions instead.
First question. Where does this have to run? If the work happens where your shell already is, a script is the cheapest thing that works. Claude Code runs its shell on your machine. Claude Desktop runs one too, but in a sandbox in the cloud, which is no use for your files.
Second question. Who else has to use it? If the answer is only you, only today, a script is fine. If the answer includes a second app or a second person, the script starts multiplying.
When a plain command wins
And now the part where I argue against my own course.
Inside a coding agent that has a shell, a plain command line tool often wins. It is smaller, there is less to go wrong, and the agent can chain commands together without asking anybody.
It is also cheap to describe. A help text is a few lines, and the model reads it only when it needs it.
If your job is a one line command, and the only user is you, sitting in Claude Code, then write the command. Do not build a server. You will be finished in 5 minutes.
And I say that out loud, because it is what makes the rest of this course worth believing.
The token argument is out of date
Now, about the token argument, and why it is out of date.
You will find articles saying MCP wastes your context window. Those articles are mostly from twenty twenty five, and they were correct at the time.
Back then every tool definition loaded at the start of a session. Anthropic's own docs put a typical setup with several servers at around 55 thousand tokens of definitions, before the model does a single piece of work.
That has changed. Tool search now loads only the names at startup, and pulls the full definitions when they are needed. And it is on by default in Claude Code.
Anthropic's docs put the saving at more than 85 percent for a typical setup. In one extreme case they report 150 thousand tokens dropping to 2 thousand.
So use the token argument if you like. Just do not quote a number from twenty twenty five as though it were today's number.
What it cost me to get this wrong
So what does it cost to get this wrong?
Here is one from my own machine, and it is genuinely embarrassing.
My research agent carried an MCP config, a Google client library, 46 packages and a lock file for 4 months. The script never imported any of it, and the server was never called once.
Nothing broke. And that is exactly why it lasted 4 months.
A layer you added out of habit throws no error. So it is the one you carry longest.
Who gets asked before it runs
And there is a 4th reason, which is about safety.
There is one more thing an MCP server gives you that a script simply does not.
Your script runs with everything you can reach. Your whole disk, your whole shell, all of it. Once it starts, nobody is checking.
An MCP tool call gets approved one call at a time. The host stops and asks you before it runs.
And your key stays out of it as well.
Think back to the key file you made in lesson 4. It sits next to your server, and only your server ever opens it.
The model asks for a job by name. Your server does the work with the key, and hands back the answer.
So the key sits on one side of a wall, and the model sits on the other side of it.
Your script has no wall. Whatever runs your script gets everything your script can reach.
One honest note on that, because it matters. The asking is done by the host, and it is not a promise built into the protocol. Claude Desktop asks. Another app might not.
In module 3 you build a second layer of your own, inside your server, which travels wherever your server goes.
The rule, and where the map stands
So here is the rule to take away.
Ask yourself one question next time. Where does this have to run, and who else has to use it?
A shell, only me, only today. Write the script.
No shell, or a second app, or a second person, or you want to be asked before it writes anything. Build the MCP server.
So where does our map stand at the end of this lesson?
Nothing lit, and nothing changed. You have a decision rule now, and you can use it on jobs that have nothing at all to do with this course.
Next lesson is a short recap, and then module 2 opens with a wall you cannot climb.
Bye now, and I will see you in the next lesson.
