MCP Explained Against the Spec: What a Server Really Is

Before the wire, the arithmetic. You have $N$ AI applications and $M$ things they should be able to reach — a calendar, a ticket tracker, a warehouse database, a design tool. Without a shared contract, somebody writes $N \times M$ integrations, and every one of them is a schema plus an endpoint plus an authentication story plus a maintenance burden. With one, the tool vendor writes a server, the application vendor writes a client, and the total is $N + M$.

That is not a new observation, and the specification says whose idea it was:

MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.¹

Take that comparison literally rather than as a compliment. Before that protocol, supporting a language in an editor meant a plugin per editor; afterwards, a language team shipped one server and every editor got it. The measure of success was not elegance, it was that the integration count stopped multiplying. The same thing follows here: the value is in the number of implementations, not in the design. A protocol that two products speak is a data format with extra ceremony.

MCP messages are JSON-RPC 2.0. A request is an object with jsonrpc, an id, a method and optional params; a response carries the same id and either result or error; a notification is a request with no id and gets no reply. The specification adds three constraints on top: the id must be a string or a number and must not be null, it must not collide with another request still in flight, and every result must carry a resultType field.²

On the stdio transport — the one the command above used — the framing rule is one line per message:

Messages are delimited by newlines, and MUST NOT contain embedded newlines. […] The server MUST NOT write anything to its stdout that is not a valid MCP message.³

That last clause is the most common way a homemade server breaks, and it breaks silently: a stray console.log, a progress bar, a deprecation warning from a dependency, and the client's line parser hits something that is not JSON. The escape hatch is in the same section — the server may write anything it likes to stderr, and the client should not treat that as an error. The reference server above prints Starting default (STDIO) server... on every launch, on stderr, which is why the pipe still worked.

The other standard transport is Streamable HTTP: each message is a POST to a single endpoint, and the reply is either a JSON object or a request-scoped stream of Server-Sent Events — the wire format Chapter 14 parsed by hand. Semantics are identical on both, because a transport is a binding: it defines framing and delivery, not meaning.⁴

The command above sent tools/list and nothing else. Under the current revision that request is malformed, and a conformant server must reject it.

Since 2026-07-28, MCP is a stateless protocol, and the specification states it without hedging:

The Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream.²

So every request carries its own protocol version and its own client capabilities, in a reserved _meta object inside params. Two of those fields are required on every single request; a request missing either is malformed and the server must answer -32602:²

Written out, a correct tools/list is this — and it is the last time this chapter shows the metadata in full, because it is on every request from here:

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}},
  "io.modelcontextprotocol/clientInfo":{"name":"bare-hands","version":"0.0.1"}}}}

The capability object is the negotiation. There is no separate negotiation step any more: the client declares what it can do on each request, the server declares what it can do in the result, and neither side may use a feature the other has not claimed. A server that needs a capability the client did not declare must answer -32021 and name the missing capability in data.requiredCapabilities. A server that does not speak the requested version must answer -32022 and list the versions it does speak.²

Clients that want the answer up front can ask for it: server/discover is a mandatory RPC that returns supported versions, capabilities, identity and an optional block of instructions in one round trip.⁵ Calling it is optional. Implementing it is not.

The command worked. Under the current revision it should not have, and the reason it did is worth a measurement rather than a paragraph, because it is the state of the entire ecosystem in one line.

Probe the reference server the way the specification tells a modern client to probe:

echo '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{}}}}' \
  | npx @modelcontextprotocol/server-everything stdio

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

That is the third branch of the compatibility rule: a DiscoverResult means modern, a recognised modern error means modern-but-wrong-version, and anything else — including -32601 — means legacy, fall back to the initialize handshake.³ So do that, asking for the current revision:

→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28",
   "capabilities":{},"clientInfo":{"name":"bare-hands","version":"0.0.1"}}}

← {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},
   "prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},
   "logging":{},"tasks":{…},"completions":{}},"serverInfo":{"name":"mcp-servers/everything",
   "title":"Everything Reference Server","version":"2.0.0"},"instructions":"…"}}

The client asked for 2026-07-28 and the server answered 2025-11-25. On 7 September 2026, the official reference server — npm package @modelcontextprotocol/server-everything, version 2026.8.31, published 31 August 2026 — does not implement the current revision. Neither, on the dates, does the TypeScript SDK it is built on: release 1.30.0 went out on 27 July 2026, the day before the revision did.

Read the consequence rather than the gossip. Nearly everything written about MCP describes a protocol with an initialize handshake, a session, a roots/list request the server sends to the client, and an HTTP+SSE transport. All four are gone or going. When you read anything about MCP, including this page, the first thing to look for is a revision number.

And the reason the very first command worked is stated in the specification as a hazard, not a feature:

some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics. Probing yields a deterministic failure instead.³

Measured: sending tools/list to that server with no handshake at all returns the full catalogue. A method that should have been refused was served, which is exactly why the specification says to probe with server/discover first even when you only support modern versions.

MCP has three parties, and the distinction between the first two is the one people collapse:

Server. A process or a service that exposes resources, tools and prompts. It can be local or remote, it operates independently, and its whole job is one focused area.⁶

That "exactly one server" rule is not bookkeeping. It is what makes the design principle below implementable, and this is the sentence to take from the specification if you take only one:

Servers should not be able to read the whole conversation, nor "see into" other servers. Servers receive only necessary contextual information. Full conversation history stays with the host. Each server maintains isolation. Cross-server interactions are controlled by the host.⁶

That overturns the mental model most people arrive with. A weather server you connect to your assistant does not see what you asked. It sees a tools/call with the arguments the model chose, and nothing else — not the previous turns, not your system prompt, not the results the calendar server returned a moment ago. If two servers need to cooperate, the host carries a value from one to the other, deliberately, because the model asked it to. Which is why isolation is the security property Chapter 30 leans on: a compromised server has a small, defined blast radius, and enlarging it requires the host to cooperate.

The first command asked that server for tools and got thirteen. Ask it the other two questions and it answers those too: resources/list returns seven, prompts/list returns four. None of them appeared, because nothing asked. Which brings us to the pedagogical spine of MCP, sitting in the specification as a table that almost nobody quotes:

Not "three ways to expose a capability". Three answers to who decides that this happens. The model decides to call a tool. The application decides to attach a resource. The person decides to run a prompt. Get that wrong and the feature still works, but it works at the wrong moment and for the wrong reason.

The clearest way to feel it is a calendar. Here is a server that exposes the same calendar three times, once as each primitive, in a hundred lines of plain Node with no dependencies:

const TOOL = {
  name: "create_event",
  description: "Create a calendar event. Writes to the calendar.",
  inputSchema: {
    type: "object",
    properties: {
      title:    { type: "string", description: "Event title." },
      startsAt: { type: "string", format: "date-time", description: "Start, ISO 8601 UTC." },
    },
    required: ["title"],
  },
};

switch (method) {
  case "resources/read":                                          
    return ok(id, { contents: [{ uri: "calendar://week",
      mimeType: "application/json", text: JSON.stringify(EVENTS) }],
      ttlMs: 60000, cacheScope: "private" });

  case "prompts/get":                                             
    return ok(id, { description: PROMPT.description, messages: [{ role: "user",
      content: { type: "text", text: `Read calendar://week and draft a plan. ` +
        `Focus: ${params.arguments?.focus ?? "balance"}.` } }] });

  case "tools/list":                                              
    return ok(id, { tools: [TOOL], ttlMs: 300000, cacheScope: "public" });
}

Run it and ask it all three ways. Real output, one message per line on the wire, wrapped here for the page, with the request _meta and the server's identity block elided:

→ resources/read  {"uri":"calendar://week"}
← {"resultType":"complete","contents":[{"uri":"calendar://week",
   "mimeType":"application/json","text":"[{\"id\":\"e1\",\"title\":\"Standup\",
   \"startsAt\":\"2026-09-07T09:00:00Z\"},{\"id\":\"e2\",\"title\":\"Design review\",
   \"startsAt\":\"2026-09-09T15:00:00Z\"}]"}],"ttlMs":60000,"cacheScope":"private"}

→ prompts/get    {"name":"prepare_week","arguments":{"focus":"deep work"}}
← {"resultType":"complete","description":"Read the week and draft a plan.",
   "messages":[{"role":"user","content":{"type":"text",
   "text":"Read calendar://week and draft a plan. Focus: deep work."}}]}

→ tools/call     {"name":"create_event","arguments":{"title":"Dentist",
                  "startsAt":"2026-09-10T08:30:00Z"}}
← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],
   "structuredContent":{"id":"e3","title":"Dentist","startsAt":"2026-09-10T08:30:00Z"},
   "isError":false}

Three methods, three shapes, one calendar. Now the point:

Almost everybody makes all three of these tools. The result is a catalogue where a read the application should have attached silently competes for the model's attention with a write that needs approval, and where the one thing a person wanted a button for is buried in a schema. It costs nothing to get right, and it is decided before you write a line.

The calendar tool has one required argument, title, and an optional startsAt. Ask it to create an event without a date, and something interesting comes back:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"}}

← {"resultType":"input_required",
   "inputRequests":{"when":{"method":"elicitation/create","params":{"mode":"form",
     "message":"When should \"Dentist\" start?",
     "requestedSchema":{"type":"object",
       "properties":{"startsAt":{"type":"string","format":"date-time"}},
       "required":["startsAt"]}}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

The server did not send a request. It answered the one it was given, with resultType: "input_required" and a description of what it still needs. The client collects the answer from the person, and then re-sends the original call — with a new id, carrying inputResponses and echoing the opaque requestState back:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"},
   "inputResponses":{"when":{"action":"accept",
     "content":{"startsAt":"2026-09-10T08:30:00Z"}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],"isError":false}

This is Multi Round-Trip Requests, introduced in the current revision, and it replaced the older design where servers sent JSON-RPC requests back at clients. The transport specification now states the rule flatly: "servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses".⁴ There is one direction of initiative, and it belongs to the host.

Two client-side features ride on that mechanism, and one of them has a name that will trip you.

Elicitation is the server asking the person for something: a form with a deliberately restricted JSON Schema — flat objects, primitive properties, no nesting — so any client can render it without a layout engine. It carries a hard rule: servers must not use form mode to ask for "passwords, API keys, access tokens, or payment credentials", and must use URL mode for those, which sends the user to a page the client never reads.⁷

Sampling is the server asking the host's model for a generation, so a server can be intelligent without holding an API key. And here is the vocabulary warning, because this word already means something else in this course: this is not Chapter 17's sampling. Nothing here is about temperature, top-p or the shape of a probability distribution. It is a nested model call travelling backwards through a protocol.

There is a second reason not to reach for it: as of this revision, sampling is deprecated, alongside roots and logging, under SEP-2577, with a blunt suggested migration — "integrate directly with LLM provider APIs instead of Sampling".⁸ The idea did not fail technically; it failed to justify its surface area, and a protocol that can remove things is healthier than one that cannot.

Statelessness sounds like a wire-format detail until you test it. Take the three-message exchange above and run each message in a separate process — a fresh node calendar.mjs, no shared memory, nothing carried over:

process A   tools/call (no date)   → resultType: input_required
                                     requestState: eyJ0aXRsZSI6IkRlbnRpc3QifQ==
process B   tools/call (with the answer, same requestState)
                                   → resultType: complete
                                     "Created e3: Dentist at 2026-09-10T08:30:00Z"
process C   resources/read calendar://week
                                   → events: 2  (Standup, Design review)

Process B, which never saw the question, completed a multi-round-trip call that process A started. That is the point of requestState: the continuation travels in the message, so nothing depends on the process being the same one.

Process C is the failure. The event was created and it is not there — because the toy server keeps EVENTS in a module-level array, and a module-level array is connection state. The specification's note names the mistake precisely:

an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.²

The prescribed fix is not a session. It is an explicit handle: a creation tool returns an opaque identifier, and every later call takes it as an ordinary argument. The protocol has no concept of it at all — "from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls".⁹ Which puts the model in charge of carrying it, and puts the server in charge of validating that this caller is allowed to use it on every single call, because a handle is a name and not a permission.

Every tool a server exposes is a schema that goes into your prompt on every request, and Chapter 24 measured what that does to a window. MCP adds a second line item that is easy to miss, so both are worth counting on the reference server above.

13 tool definitions (name + description + inputSchema):  1,307 tokens
  cheapest tool, get-tiny-image                              52
  costliest tool, gzip-file-as-resource                     235
server `instructions`, returned by discovery:               312 tokens
                                                          ------
one server, connected, before it is used:                 1,619 tokens

Two observations. The first is arithmetic: connect five servers of this size and roughly eight thousand tokens of your window are spoken for on every turn, forever, whether or not the model uses any of them — which is the mechanism behind the 150,000-to-2,000 reduction Chapter 24 quoted, and the reason just-in-time tool discovery exists.

The second is a security note wearing an accounting costume. instructions is natural-language text, written by the server author, that lands in the host's prompt, and the tool descriptions beside it are the same. The specification says what to do about that in its own security principles: tool annotations and descriptions "should be considered untrusted, unless obtained from a trusted server", and hosts "must obtain explicit user consent before invoking any tool".¹ Connecting an MCP server is not adding a dependency. It is granting a stranger 1,619 tokens of your system prompt and the right to be called. Chapter 30 is what happens when that stranger is hostile.

Everything in this section is true of protocol revision 2026-07-28, the current one, read on 7 September 2026. Revisions are dated YYYY-MM-DD and the date is the last time a backwards-incompatible change was made.¹⁰ The normative document is a TypeScript file, schema/2026-07-28/schema.ts; the JSON Schema beside it is generated from it, which is why the specification is read here in TypeScript and why teaching MCP from anything else is teaching a translation.

The governance change underneath that table matters more than any single row. This revision adopted a feature lifecycle and deprecation policy: features are Active, Deprecated or Removed, a deprecated feature documents its migration path and stays in the specification for at least twelve months before it becomes eligible for removal, and there is a registry listing everything currently in the Deprecated state.⁸ Before that policy, "deprecated" in an AI protocol meant whatever the last blog post said. Now it means a date.

This is the vocabulary of the whole block in one place.

Two of those deserve a sentence each, because they are where the confusion actually lives.

MCP against A2A is not a rivalry, and both specifications say so. The A2A documentation draws the line by what is on the other end: MCP "defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API", where a tool performs "specific, often stateless, functions"; A2A addresses agents, "more autonomous systems" that "reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues". Its own summary is the sentence to remember: "A2A is about agents partnering on tasks, while MCP is more about agents using capabilities."¹¹ The two nest — an application uses A2A to reach other agents, and each agent uses MCP to reach its own tools. Chapter 25 drew that line inside one process, between asking a sub-agent and handing it the conversation; A2A draws it between organisations.

MCP against ACP is a comparison with a stale premise, which is exactly why it is worth answering. The Agent Communication Protocol was a separate open standard for agent-to-agent messaging. Its own documentation now opens with the notice: "ACP is now part of A2A under the Linux Foundation!"¹² The honest answer to "MCP or ACP?" in September 2026 is that the question has one fewer option than the pages ranking for it suggest.

And the comparison people ask for most, mcp vs api, has the least interesting answer: MCP is an API. What it adds is not power, it is conventions — a fixed set of method names, a discovery call, a control hierarchy over the primitives, and an isolation model. You give up the freedom to design your own interface and you get every host that speaks the protocol, which is the trade every protocol has ever offered.

You can now read the specification without a translator, tell a resource from a tool from a prompt by who is in charge of it, type a request by hand when a client library is lying to you, and date any MCP article you read by which of the deprecated features it still teaches as current.

What you have not done is ship one. Chapter 27 writes the same server twice — TypeScript and Python, side by side, because MCP is the one genuinely bilingual territory in this course and the numbers say so in both directions. It covers the two live transports properly, the inspector, packaging, and the half of the protocol this chapter deliberately left alone: authorization. Because the moment your server is remote rather than a subprocess on your own laptop, a stranger's client will present a token, and the specification's rule about what you may do with it is unusually strict.

Which raises the question the next chapter has to answer, and it is not a friendly one: if a token arrives at your server and it was issued for somebody else's audience, what exactly stops you from forwarding it?

Every quotation, method name, error code and rule in this chapter was read from the Model Context Protocol specification, revision 2026-07-28, on 7 September 2026. Every trace was produced locally on Node 22: the toy calendar server is 101 lines with no dependencies, and the reference server is the published npm package named below. No paid API was called to write this chapter — nothing here needs a model, which is itself the point.

The measurements: @modelcontextprotocol/server-everything@2026.8.31, published 31 August 2026, built on @modelcontextprotocol/sdk@1.30.0, published 27 July 2026 — one day before the revision this chapter describes. It answers server/discover with -32601, negotiates 2025-11-25 when asked for 2026-07-28, and serves tools/list with no handshake at all. Its catalogue is 13 tools in 7,663 bytes; token counts are o200k_base via tiktoken, over the name, description and inputSchema of each definition, which is what a provider renders into your prompt and not what the JSON-RPC frame weighs.

Anthropic, Code execution with MCP: building more efficient agents, 4 November 2025, is the source of the 150,000-to-2,000 figure, quoted and used in Chapter 24 and only referenced here.