Why a protocol

N agents and M tools need N·M adapters point to point, or N+M implementations of one protocol; then one tool call followed from the model to the server and back.

Loading the animation…

Concept

An agent is only as useful as the tools it can reach: a file system, a database, a ticket tracker, a search index. Before a shared protocol, every agent application wrote its own connector for every tool it wanted, and every tool vendor wrote a plug-in for every agent it wanted to reach. With $N$ agents and $M$ tools that is $N \cdot M$ pieces of glue, each with its own way of describing a tool, calling it and reporting an error. Five agents and six tools need 30 adapters.

The Model Context Protocol (MCP) cuts that to $N + M$ : each agent implements an MCP client once, each tool ships an MCP server once, and any client can talk to any server. The same five agents and six tools need 11 implementations. Anthropic published MCP as an open protocol in November 2024 (announcement, accessed 2026-10-08); the specification is versioned by date, and the current revision is 2026-07-28 (versioning, accessed 2026-10-08).

The count is of things to build, not of connections at run time: a host that uses six servers still opens six connections. What the protocol removes is the per-pair glue.

One tool call, end to end

The specification names three roles (architecture, accessed 2026-10-08). The host is the application the user runs (a chat app, an IDE, a coding agent); it holds the model and decides what reaches it. Inside the host, one client per server keeps a 1:1 connection to that server. The server offers tools, resources and prompts. The model itself never speaks MCP: it writes a tool call in its own API's format, and the host turns it into a JSON-RPC request through the right client.

Loading the animation…

Concept

Follow the packet. The model asks for add; the host looks up which connected server offers a tool of that name (it learnt the list earlier with tools/list); that server's client sends a tools/call request; the server runs the tool and answers; the client hands the content back to the host, which adds it to the model's context as a tool result. Only the two middle legs are MCP. Switch the revision: in 2026-07-28 the request also carries the protocol version and the client's identity in _meta, and the result names the server and says resultType: "complete", because there is no handshake any more to have settled those things once (chapter 2).

In this session the 2025-11-25 exchange takes 17 messages and 3,790 bytes of JSON for a handshake, a ping and one use of each primitive; the 2026-07-28 one takes 12 messages but 5,262 bytes, since every request repeats its envelope.

Maths

With $N$ agents and $M$ tools, point-to-point integration needs one adapter per pair and a protocol needs one implementation per party:

A_{\text{p2p}} = N M, \qquad A_{\text{MCP}} = N + M, \qquad \frac{A_{\text{p2p}}}{A_{\text{MCP}}} = \frac{NM}{N+M}.

For $N = M$ the saving is $N/2$ : it grows with the size of the ecosystem, which is why a shared protocol pays off more the more agents and tools there are. For $N = 1$ there is nothing to save ( $M$ adapters either way): one agent and its own tools do not need a protocol.

Code

The server's side of the call above, cut from the vendored engine (src/lib/engine/vendor/protocols/mcp.ts; its Python reference in Agent_Loop_Sim produces the same messages, which equal the SDK's). An unknown tool comes back as a result the model can read, as the SDK does it (the specification's own example treats an unknown tool as a -32602 protocol error; tools, accessed 2026-10-08):

const names = (this.spec.tools as Obj[]).map((t) => t.name);
if (!names.includes(name)) return [response(id, this.toolResult("Unknown tool: " + String(name), false, true))];
if (name === "add") {
  const v = args.a + args.b;
  const r: Obj = { content: textContent(String(v)), isError: false, structuredContent: { result: v } };
  return [response(id, this.modern(r, false))];
}