All lessons · 44
MCP: The USB Port for AI
The Model Context Protocol — the open standard that connects models to tools and data, and why the industry needed it.
The USB port for AI
You plug a mouse into any laptop and it works. You do not buy a mouse built for one exact laptop model, and the mouse maker does not write a separate driver for every computer on earth. It was not always like that: keyboards had their own round plug, printers had a wide one, mice used a third — and none of them fitted anything else. Then everyone agreed on one port, paid the one-time cost of switching, and the mess disappeared.
AI apps had no such port. Before MCP, connecting an AI app to a tool was a custom job: an editor wanted to read files — hand-written integration; a chat app wanted your calendar — another hand-written integration. With M apps and N tools you needed up to M times N connectors, each one fragile, each one maintained separately.
In November 2024 Anthropic published the Model Context Protocol (MCP) — the USB port for AI: an open standard for connecting models to tools and data. It was adopted remarkably fast by OpenAI, Google, Microsoft and dozens of tool makers. Today “does it speak MCP?” is a real question you ask about AI software.
One protocol instead of M times N connectors
With MCP, a tool author writes one MCP server, and every MCP-compatible app can use it. An app author implements the protocol once, and every MCP server works inside it. M times N collapses to M plus N.
What is a protocol, anyway?
Worth clearing up from zero, because the word does a lot of work here.
A protocol is simply an agreed set of rules for how two sides talk. Nothing more. It says which messages exist, what shape they have, who speaks first, and what happens when something goes wrong.
The easiest everyday example is a phone call. Both sides follow a script nobody wrote down: the caller says hello, the receiver answers, they take turns, one of them says goodbye, and the call ends. If one side started shouting product names without a greeting, the conversation would still technically be sound waves — but it would not work. The script is the protocol.
For computers it is the same thing, just written down exactly. The web runs
on HTTP, a protocol that says: the client sends a request with a method
(GET) and an address; the server replies with a status code (200, 404)
and a body. That agreement is the only reason a browser written by one
company can read a page served by a completely different one.
MCP is that kind of agreement, for one narrow job: how an AI app and a tool provider talk to each other. It fixes four things:
- The handshake — the app asks “who are you, and what do you offer?”, and the server answers with a list of tools, resources and prompts.
- The message format — every message is a JSON-RPC 2.0 envelope, so both sides know where the method name, the parameters and the id go.
- The call — “run this tool with these arguments”, and “here is the result” (or “here is the error”).
- The transport — how the bytes physically travel: a local pipe or HTTP.
That is the whole idea. Nobody is sharing a brain, and nobody is granting anyone access to their internals: two programs agreed on the same four rules and can now work together without ever having met. The three roles below are just the names MCP gives to the participants in that conversation.
The three roles
MCP has a deliberately small vocabulary. Three roles, clearly separated:
- MCP Host — the application the human uses: an editor like Cursor or VS Code, a chat app like Claude Desktop, an agent framework.
- MCP Client — the connector living inside the host. It maintains the connection to one MCP server and speaks the protocol on the host’s behalf. One host usually runs several clients, one per connected server.
- MCP Server — a small program that exposes capabilities: tools to call, resources to read, prompts to reuse. A server can wrap anything — a filesystem, a database, GitHub, Slack, your company’s internal API.
The mental model: the host is the computer, the client is the USB port, the server is the device you plug in.
Two layers: transport and data
MCP is specified in two layers, and keeping them apart makes everything click.
The transport layer answers “how do bytes travel?”
- stdio — the server runs as a local process, and messages flow through standard input and output. Simple, fast, private. This is the default for local setups like Claude Desktop.
- HTTP (Streamable HTTP, with SSE for server-to-client messages) — the server runs remotely, so a team can host one shared server with real authentication. This is how you expose tools to a whole organization.
The data layer answers “what do we say?” All messages are JSON-RPC 2.0 — requests, responses and notifications with a standard envelope. On top of that sit the three capability types:
- tools — actions the model can call: query a database, send a message, create a ticket. The model decides when to use them.
- resources — data the app can read and inject into context: files, schemas, documents. App-controlled, not model-controlled.
- prompts — reusable, parameterized prompt templates the server offers, often surfaced as slash commands in the UI.
Watch a request flow through the stack
Here is the full journey of one user request:
"What is on my calendar tomorrow?" — typed into the host app.
So the full round trip is: you to host, host to model, model back to host, host to client, client to server, server back to client, client to host, host to model again, and finally the answer back to you. The model and the server never talk to each other directly — the host is always in the middle.
The same shape you already know from function calling — but now the tool lives in a separate process, possibly on another machine, and any MCP-compatible app can use it.
How tools reach the model
A subtle but crucial detail: the model never “connects” to anything. The host collects the tool definitions from all connected servers and puts their schemas — name, description, JSON Schema of parameters — into the model’s context. The model reads those descriptions like a menu and chooses what to call. That is why a tool’s description is not documentation: it is the tool’s entire pitch to the model. Write it carelessly and the model will pick the wrong tool, or none.
See it in conversation
A real exchange, with the tool step visible:
Check yourself
In the USB analogy, what is the MCP server?
Who actually talks to the model during an MCP tool call?
How does the model know which tools exist?
Where to go from here
You now know what MCP is and how a request flows through host, client and server. Later in the roadmap: multimodal AI — models that work with images, audio and video, not just text. And if you want to see where tool calling started, tools and function calling is the lesson MCP builds on.