Eleven ideas, one per screen. Each is a thing to point at while you explain. The drama is in the watching, so take the silences.
Four moves: grasp what MCP is, then learn its three primitives (tools, resources, prompts) one at a time, server side and client side.
Without a standard, every app wires up to every tool by hand. MCP is the standard connector that ends the tangle.
MCP is a standard, like USB-C for AI: build to the protocol once and every compliant tool just works. It also splits the work: app builders on one side, tool builders on the other.
The app you use is the host. Inside it, each client holds one connection to one server, and the server wraps the real tool or data.
Messages travel as JSON-RPC over a transport: stdio for a local server, HTTP for a remote one. The host can hold many clients at once, but each client talks to exactly one server.
What does each side hold? The server offers the capabilities: tools, resources, prompts. The client is the connection that reaches one server and brokers them to the host. Supplier vs. connector.
Is the client one shared pipe? No: one client per server. The host opens a separate, named line to each server, so you grant and revoke them one at a time.
The Python SDK's FastMCP does the protocol plumbing. You create a server, register capabilities, and run it over a transport.
stdio runs the server as a local subprocess of the host; HTTP exposes it as a remote service. Same server code either way; the transport is just how messages travel.
What does "transport-agnostic" mean? MCP fixes the language, not the channel. The JSON-RPC messages are identical whether they ride a local stdio pipe or an HTTP connection; neither side's logic changes.
Rewrite the server to go remote? No. Its tools, resources and prompts stay the same; you swap the transport (stdio → HTTP), not the code.
Decorate a function and its name, docstring and typed arguments become a schema the model reads. The model decides when to use it.
A clear name and description matter: that text is all the model has to decide whether and how to call the tool. Treat the docstring as a prompt, not a comment.
The Inspector connects straight to your server, no LLM involved. List what it exposes, call each tool by hand, read the raw response.
Debug the server on its own first. If the Inspector can list and call everything cleanly, the problem later is in the client wiring, not the server.
Your client lists the server's tools, hands their schemas to Claude, runs whatever Claude asks for, and feeds the result back, until it has an answer.
This is the same agentic loop a chat window doesn't have: the model can act, see the result, and decide what to do next. MCP is just how the tools get there.
Read-only data the server exposes at an address. No side effects: think GET, not POST.
A URI scheme like docs:// names the data. Direct resources return a collection; templated ones take a parameter to fetch exactly one: a single document, a single record.
Unlike tools, the model doesn't reach for resources. The application (often the user) chooses what context to bring in.
That's the difference from a tool: a tool is the model's to call, a resource is the app's to load. Same server, two different control models, which is the heart of MCP.
A tested, parameterized prompt the server exposes, so the right wording is baked in instead of reinvented every time.
Prompts move hard-won phrasing out of people's heads and into the server. The author tunes it once; everyone else just calls it and gets the good version.
The client lists the server's prompts and offers them to the user. Pick one, fill the arguments, and it expands into the full message.
If you've used a slash command in Claude Code, you've used an MCP prompt. The server ships the command; the client makes it a one-keystroke action.
The whole protocol, in one picture: what the server exposes, and who gets to trigger each one.
Everything in the course hangs off this: tools the model calls, resources the app loads, prompts the user triggers. Get the owners straight and the rest follows.
Tools, resources and prompts, exposed by a server and reached by a client inside your host, so context and capability plug in once instead of being rebuilt every time.
tutto.one/praxis · daniel@tutto.one