The switch: the manual is written, the hands are missing
Skills part complete: you can transfer know-how to the model, test it, govern it. But reread the skill from our connecting thread: it explains how to write a meeting summary… from notes the model has no way of fetching. The manual is perfect; the hands are missing.
That is the whole point of the next four steps. And we start by understanding the protocol itself — not for theory's sake: because the decisions that matter (what to plug in, with which rights, where it runs) are made badly when you do not know what flows through the pipes.
The problem before: M × N hell
Rewind to 2023-2024. Every AI application vendor wanted to connect its assistant to the same services: messaging, code repositories, databases, CRMs. And each built its own connectors, in its own format. The result:
At three applications and three services, the gap looks anecdotal. At real scale — dozens of host applications, thousands of services — M × N is a wall: every bespoke integration is code to build, secure and maintain, at every vendor, for every service. That wall is what MCP knocks down, and it is the precise meaning of the "USB-C of AI" analogy: before the standard socket, every device had its proprietary charger; after, one cable for everything. A service implements MCP once and becomes reachable by every compatible application — and vice versa.
The architecture: host, client, server
Three technical roles, often conflated, easy to untangle:
The host — the application the user sees and uses: a desktop assistant, an IDE, a business agent. It embeds the model and decides which servers are plugged in (with, one hopes, the governance from step 4 in mind).
The client — the component inside the host that manages the connection to one given server: one connection, one client. Internal plumbing; as a user or architect you never touch it directly, but knowing it exists makes the official documentation's diagrams click.
The server — the program that exposes the capabilities: what we have called "the hands" since step 1. It can run locally on the host's machine, or remotely as a network service — a seemingly minor distinction with heavy security consequences (a full section of step 8 is devoted to it).
Remember the chain: the host houses the model, the client holds the line, the server lends the hands. And the step 1 principle holds at every link: nothing fires without a decision by the model.
The three primitives: tools, resources, prompts
An MCP server does not expose "functions" in bulk: the protocol distinguishes three natures of things, and the distinction is a design aid, not an implementer's nicety.
The architect's reflex to install right away: whatever can be a resource should not be a tool. Exposing document reading through a read_document tool works — but a tool can have side effects, and every security analysis will treat it as such. A resource says by construction "this is read-only". Less surface, fewer questions: half of step 8's work is won in this design choice.
The sequence of a tool call, step by step
The beating heart of the protocol. Let's follow our thread — "write up this morning's meeting summary" — through the circuit:
① The decision. The model realizes it is missing the notes. In its tool catalog (transmitted by the connected servers, each tool with a name, a description and an argument schema), it spots get_meeting_notes. The tool's description plays exactly the role a skill's description plays: it is what enables the right choice — you have known that tune since step 2.
② The call. The model produces a structured call: the tool name and arguments ("this morning's meeting" becomes a date). The input schema declared by the server lets those arguments be validated before execution — the first line of defense against malformed calls.
③ The execution. The server does its job: it queries the note-taking tool. Capital point, to hold on to for step 8: it does so with its own rights — its service account, its token, its scope. The model never had those credentials; it asked, the server acted. That is exactly why secrets have no place in a skill.
④ The return. The result — the raw notes — flows back to the client, which injects it into the context window. From that instant, this data is context like any other: the model reads it… and can be influenced by what it contains. Keep that sentence in mind: it is the entry door of indirect injection, the main course of step 8.
⑤ The continuation. The model resumes its reasoning, applies the house format from the skill to the retrieved notes — and if the task requires it, chains a second call (send_summary). The skill + MCP loop of our thread is complete: the manual said how, the hands supplied what.
What the protocol standardizes (and why it concerns you)
Three mechanisms of the standard are worth knowing even without writing a line of code, because they ground properties you will exploit:
Discovery. On connection, the host asks the server for the list of its capabilities — tools, resources, prompts, with descriptions and schemas. No hard coupling: plugging in a server is enough to make its tools visible. That is the property that makes the ecosystem composable… and that forces the governance question "what exactly did we just make possible?" at every plug-in.
Input schemas. Every tool declares the exact shape of its arguments. For the architect, it is a readable contract: a tool's declaration says precisely what can be asked of it — auditable before any use, like a mobile app's permission list.
Transports. The same protocol travels over two channels: stdio for a local server (a child process on the host's machine) and HTTP for a remote one. Same grammar, opposite operational properties — who holds the secrets, where the data flows, who can connect. The local/remote choice is the first trade-off of step 6.
📚Going deeper
For the geeks: under the hood, JSON-RPC 2.0. MCP messages are JSON-RPC: named requests (tools/list for discovery, tools/call for invocation, their resources/* and prompts/* counterparts), responses correlated by id, and notifications expecting no reply. Practical consequence #1: everything is observable — a proxy that logs the frames gives you the complete audit trail of model↔server exchanges, the base brick of the supervision we will build at step 8. Consequence #2: the session has a life cycle (initialization with version and capability negotiation, then exchanges) — a server can notify that its tool list changed mid-session, which is powerful for composability and interesting to watch for security: a server that "grows" tools after the initial audit phase is a pattern worth detecting.
📚Going deeper
For the geeks: stdio vs HTTP, the full mental table. stdio: the host launches the server as a child process and talks to it over standard input/output. Properties: no network exposure, secrets in the process's local environment, life cycle tied to the host, one user = one instance. Ideal for personal hands: local files, machine tooling. HTTP (streamable): the server is a network service, potentially shared, with authentication as a first-class concern (typically OAuth for remote servers) and the classic exposed-service toolkit — TLS, access control, centralized logging, scaling. Ideal for team hands: the CRM, the shared database. The pocket rule: stdio = the rights of your session; HTTP = the rights of a service, with everything that implies in engineering on both sides. In both cases the step 8 principle already applies: the server holds the secrets; the model never sees their color.
📍 Skills & MCP path — step 5/9
- 🗺️ The map before the territory
- 🔬 Anatomy of a skill
- 🛠️ Create your first skill
- 🏛️ Skills in the enterprise: governance
- 🔌 MCP: the protocol explained ← you are here
- ⚡ Use an existing MCP server
- ⚙️ Build your minimal MCP server
- 🛡️ Secure your MCP servers
- 📡 The ecosystem: where to find, where it moves
Next step → Use an existing MCP server: plug in before you build — reading a manifest, understanding what you authorize, and the first local-vs-remote trade-off.
Itching to browse the tool catalog already? Our 40 Claude & MCP tools sheet maps the ecosystem, GitHub stars live.