MCP 2026-07-28

What the spec changed and who should care

MCP — the Model Context Protocol — is an open specification for how an agent talks to tools and external context. One wire format, in practice JSON-RPC over stdio or HTTP, describing what a server offers (tools, resources, prompts) and how a client calls it. The date in this page's title is the spec revision, not a product version: like HTTP or TLS, the protocol is dated, and this is the current text as of late September 2026.

The changes in this revision are about weight and rigour. The stateless core means a server can serve requests without holding a session open, which is what makes servers cheap to run behind ordinary HTTP infrastructure. Per-request capability negotiation lets the two sides agree on what is supported for each request rather than once at handshake, so a client and server of different vintages degrade gracefully instead of failing to connect. Cacheable list results cut the round trips spent re-listing tools on every turn. And the formal extensions framework takes what used to be vendor conventions and gives them a defined, negotiated shape — that last one has its own page on this board, MCP extensions.

Who should care: anyone writing a server, and anyone choosing how their agent reaches the outside world. The negotiation and caching details are exactly the kind of thing to verify against the dated spec text rather than a summary — this page describes the shape of the changes, not their normative wording.

When it earns its place in a stack

When you have more than one agent, or more than one tool consumer. Without a protocol, every tool is written twice — once for each framework that calls it — and the second integration is where the drift starts. MCP's pitch is that a server written once is callable from any conforming client: the same connector serves a coding harness, an internal assistant and a batch pipeline. It also earns its place when the tools belong to a different team or vendor than the agent: the protocol is a contract boundary, and a contract beats a shared codebase for crossing team lines.

For one agent and three tools in a single codebase, it is an extra process and an extra protocol to debug. A typed function call is simpler right up until the second consumer arrives.

Limits

• A protocol standardises transport, not trust. A conforming server can still lie, leak or be prompt-injected through its results; the wire format authenticates nobody. The security write-up linked below covers the surfaces worth worrying about.
• Conformance is not uniformity. Clients and servers implement different slices of the spec and its extensions; “supports MCP” tells you the socket connects, not which features work.
• Versioning is now your problem too. Dated revisions with negotiation are the right design for compatibility, and the cost is that you must reason about which revision each party implements.
• It says nothing about the agent. Loops, memory, permissions and evaluation are all outside the protocol's scope by design.

Alternatives on this board

• MCP extensions — the negotiated layer on top: long-running tasks, inline UI, structured skills.
• OpenAI Agents SDK, LangGraph and Google ADK — frameworks that consume this protocol; the choice between them is separate from the wire format.