MCP Explained

The Model Context Protocol, explained from the beginning: short videos, one idea each, animated diagrams and code scenes, and a companion repo with a runnable folder for every video that has code. The series is for developers who are hearing about MCP for the first time. The first four videos need no code at all, and the rest assume you are comfortable with Python and with calling a model API.

One idea runs through every episode. An AI application needs things that are not in the prompt: your files, your database, the services your team already uses. Without a standard, every app needs its own hand-written integration for every tool, and each new app or tool adds more of them. MCP puts one agreed standard between the two sides. A tool is wrapped once, as an MCP server, and every app that speaks the protocol can use it. An app implements the client side once and can use every server.

Three sections, thirteen episodes.

The idea

• 1. What Is MCP, and Why Do We Need It? One assistant and one tool need one integration; as apps and tools multiply the integrations do too, and a shared standard is the fix.
• 2. Why Is It Called Model Context Protocol? The name taken apart one word at a time, and read back as a plain description of what MCP does.
• 3. Host, Client, and Server. One request followed through a real connection, naming the three roles and who talks to whom.
• 4. Tools, Resources, and Prompts. The three kinds of things a server can offer, and who chooses each: the model, the app, or you.

Building and connecting a server

• 5. Plug In Your First Server. A fifty-line host fails a weather question, then connects to a public server somebody else built and answers it with a real forecast.
• 6. Build the Smallest Possible MCP Server. Ten lines of Python wrap a stock-price lookup into one tool, and the host calls it over standard input and output.
• 7. Give Your Server More to Offer. The stock server gains two more tools, a resource and a prompt, and we say which of the three you will meet most in practice.
• 8. What Goes Over the Wire. A logging program sits between app and server, and we read the messages one at a time: the introduction, the tool list, the call and its reply.
• 9. You'll Never Write an MCP Client. Why the client side does the same job everywhere, shown with a complete hand-written client of thirty five lines.

Using MCP for real

• 10. Give Your Agent MCP. One small agent holds three connections at once, and a morning briefing needs all three servers.
• 11. Trusting a Server Is a Decision. What a connected server is allowed to touch, and the three decisions the host has to make about it.
• 12. Wrap a Real API. GitHub's own MCP server plugged into the agent with one entry and one scoped token, and what makes its tools well made.
• 13. Going Remote. The stock server leaves the machine: one line names a transport, and we go through what a deployed server takes on.

The two ideas the series rests on: connection work is written once per side, never once per pairing, and the custom side is the server, because clients do the same job everywhere and come from a package.