agentic ai

The USB-C for AI: a complete guide to the Model Context Protocol

Understand MCP through a restaurant analogy, then build, connect and deploy your own server from scratch.

Four-panel diagram of the Model Context Protocol. Panel one, the host: Claude Desktop and the LLM, which knows nothing about how any of it works. Panel two, the client: initialize, list_tools, call_tool, and a tool-to-session map that remembers which server owns which tool. Panel three, the servers: research, filesystem and fetch, each exposing the same three primitives — tools, resources and prompts. Panel four, composition: an orchestrator agent acting as a server to the host above it and a client to research, code and data sub-agents below. — The whole protocol on one page: host, client, servers, and the composition step where a server becomes a client to other servers.

01 The short version

Five AI apps and ten tools isn't fifteen integrations to build. It's fifty. Every app has to re-implement how to talk to every tool — custom endpoints, custom parsing, custom error handling, rewritten again and again for the same ten tools. That's the M×N problem, and it's why "just let the model read our database" kept turning into a two-week project.

The Model Context Protocol collapses it. Build the tool once as an MCP server and every MCP-compatible AI app can use it immediately. Fifty becomes fifteen; M×N becomes M+N.

The mental model I use throughout is a restaurant. The LLM is the customer: it orders, and it never walks into the kitchen. The MCP client is the waiter, carrying the menu one way and the order the other. The MCP server is the kitchen, owning the recipes, the ingredients and the mess. The customer never learns to cook, and that separation is the entire point — swap the kitchen, add a dish, or change waiters, and nobody else has to relearn a thing.

The part most people miss is that a server can also be a client. One kitchen ordering from another is an orchestrator agent, and it's how you get multi-agent systems with no framework at all. Just clients and servers, all the way down.

02What you'll take away

A working MCP server is roughly ten lines of Python. The @mcp.tool() decorator generates the schema from your type hints and docstring, so the boilerplate disappears.
Tools, Resources and Prompts map cleanly onto ideas you already know: a POST endpoint, a GET endpoint, and a prompt library.
One client can hold sessions to many servers at once, merging them into a single menu the model sees as one — the M+N payoff in practice.
Going remote is a transport swap, not a rewrite. stdio for local, streamable HTTP for networked; your tools, resources and prompts are untouched.
Composability is the real unlock: an orchestrator is a server to whatever calls it and a client to its specialists, and the pattern nests without any agent framework.