Lesson 8 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
A capability that describes itself (a name, a plain-sentence description, and the exact shape of the input it wants) needs no external explanation catalog. Discoverability beats documentation: anything that has to be re-explained in a prompt every time does not scale the way a self-describing capability does.
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
What a server can offer
Your server can offer 3 kinds of thing, and only one of them can change anything in the world.
Hello, and welcome to lesson 8 of the MCP Masterclass. Last lesson we named the host, the client and the server. Today we look at what goes inside your server. And we start with our map, as always.
Same diagram, and the server box is still dark. Well, today we look at what will be inside it when we finally light it up.
An MCP server can offer 3 kinds of thing. People call them the 3 superpowers, and Scribe will use all 3 of them before this course ends.
Tools
So let us start with tools.
A tool is nothing but a job the server can do when your AI asks for it.
Read this document. Save this document. Post this draft. Each one of those is a tool.
A tool takes some input, does something, and gives an answer back. When you write one, it is an ordinary Python function with 1 extra line above it.
And tools are the only one of the 3 that can change something in the world. That one fact is the seed of the whole of module 3.
Resources
Now, resources.
A resource is nothing but something your AI can look at.
Your Drafts folder is a resource. Each document in it is a resource. Claude can browse the list and read what is there.
The difference between a resource and a tool is who is in charge. A tool is a verb, and the model chooses to run it. A resource is a noun, and the model is allowed to look at it.
Later in module 2 we hand Claude the whole folder as a resource, and it stops needing you to name the file.
Prompts
And prompts.
A prompt here is nothing but a saved job.
You know that long instruction you retype every week? Tighten this draft, keep my voice, do not touch the quotes, keep it under 800 words.
Save that once as a prompt. From then on it shows up in the app as something you pick, rather than something you type.
So, tools are what the model can do. Resources are what the model can see. And prompts are what you saved for later.
Why a tool beats a script
And here is the part I want you to hold onto, because it answers a question you have probably been sitting on since lesson 5.
Your script from lesson 5 worked. So why is a tool any better than that script?
Because a tool describes itself.
When a host connects to your server, it asks one question. What can you do?
Your server sends back a list. Every entry has a name, a plain sentence saying what it does, and the exact shape of the input it wants.
The model reads that list and picks. Nobody has to explain your tools in a prompt, and nobody has to remember them.
Your script cannot do that. A script is a file sitting on a disk. It has no way to announce itself, and no way to say what it takes.
That is reason number 3. You met reasons 1 and 2 in lesson 5, when the script would not run and the glue kept multiplying. This is the third one, and it pays off in module 2, the first time you write a tool.
How little code it takes
So how little do you actually have to write?
In module 2 you will write a plain Python function. Then you put 1 line above it, and you write 1 sentence of description inside it.
From those, the list gets built for you. The name comes from the function name. The input shape comes from the type hints you already wrote. And the description comes from that one sentence.
So you describe your tool once, in the place you were writing code anyway.
What Scribe uses, and what we skip
Now, which of the 3 does Scribe use, and when?
Tools arrive first in module 2, with the tool that edits a document. Resources and prompts follow later in the same module, when we hand over the whole folder and save your editing job.
And one thing we are leaving out on purpose.
Older articles about MCP mention a few more features. Some of them have since been retired from the protocol.
I am not teaching those, because they would waste your time. Tools, resources and prompts are what a server offers today.
Where the map stands
So where does our map stand at the end of this lesson?
Still 6 boxes, and the hole is still open. You now know the 3 shapes of thing that will fill it.
Next lesson is the question I get asked in every single cohort I teach. How is this different from an API, and when should you use a plain command line tool instead?
Bye now, and I will see you in the next lesson.
