Every MCP Revision, and What Each One Took Back

The Model Context Protocol is twenty months old and has had five specification revisions. They are scattered across three of my own articles, which is a bad place for them, so here they are in one table.

The reason to collect them is not tidiness. It is that the shape of the list makes an argument that no single row makes, and the argument is this: read the removals, not the additions. Everybody publishing a changelog wants you to read the left-hand column. The right-hand column is where a protocol tells you what it got wrong.

Each revision has its own anchor below, so you can link to a row rather than to the page.

The base revision, published three weeks before the announcement that made it public, which is why the version strings and the launch date disagree. JSON-RPC as the envelope — a format whose second version was published in 2010 and has not moved since 2013, taken off the shelf precisely because there was nothing left to argue about in it. Two transports. And the departure from everything that came before it: the list of capabilities is requested while the program is running, not read in advance by a programmer.

Nothing is taken back in a first revision, but it is worth noticing what was already in it, because two of those three things have quietly stopped mattering. Servers ship tools. Resources and prompts exist and are rare, mine included.

Five months in, the transport is replaced. Streamable HTTP arrives — one address written to and read from, able to hold a connection open — and HTTP+SSE, which had used two endpoints, is obsolete from this revision onward. If a tutorial you are reading uses two endpoints, it is stale in other ways too.

OAuth 2.1 arrives in the same revision, with PKCE mandatory, which is the moment MCP stops being a local-machine convenience and starts being something you can expose. And batching arrives, which is the row the rest of this page exists for.

Structured output: a tool can now return a second register alongside its prose, one for the model to read and one for the program to act on. Useful, undramatic.

And batching is removed, before it was three months old. This is the cheapest lesson in the whole list and the one I would put in front of anyone about to build on a young protocol. A capability that ships in March and is deleted in June was never load-bearing. Nothing had been built on it, so nothing broke, and the specification was free to admit the mistake. That freedom is exactly what runs out later.

Icons, default values in schemas, and an upgrade to JSON Schema 2020-12. Housekeeping. As far as the revision list goes, nothing was taken back here, which makes this the only one of the five that reads like a normal release of a settled protocol.

I include it anyway, because a table of only the dramatic revisions would be dishonest about the pace. Four of five revisions in twenty months changed something structural. One did not.

The largest rework in the protocol's history, and the change list reads as a single move: everything that assumed the two sides remember each other has been taken out.

Sessions are gone, and with them the handshake that used to open every connection. State moves into arguments the server itself hands out; the client gives back what it was given, and any instance of the server can answer. The version and the capabilities that used to be negotiated once now ride along on every request. Recovery of a broken stream is gone too — a client used to reconnect and ask for what it had missed, and now it asks again from the start. Simpler protocol, more repeated work, a trade this revision makes over and over.

In plain words: MCP became stateless. That is Roy Fielding's second REST constraint, adopted twenty months late by a protocol that had started from the opposite premise. Everything else in the revision follows from it. Response cache hints, because a stateless server can be told it need not be asked again yet. Routing headers, because a proxy has to be able to direct a request without parsing the body, and in MCP every call goes to the same endpoint saying tools/call, so from outside every envelope looks identical. These are the features you add when your protocol has to survive contact with ordinary infrastructure.

Four capabilities are deprecated rather than deleted, with a year of grace: the server calling back to the model, folder access, protocol-level logging, and dynamic client registration. The first three have one thing in common — each assumed a durable relationship between two processes. The fourth was the most convenient part of the authorization flow and the most abused.

Nothing broke on 28 July. The revision arrived as a Release Candidate rather than a final standard, the SDKs implementing it are in beta, and servers written against the session model still work. The uncomfortable half of that same fact: tutorials still teach the handshake, and the gap between what the specification says and what the tools do is the widest it has been.

A capability deleted in month seven is a correction. A rework of the foundations in month twenty means the foundations were wrong, and that is a different kind of news.

My reading, and you are welcome to argue with it: the reversal is late and right. Sessions in a protocol that lives between two processes owned by different people were a mistake from the beginning. The two ends are deployed, restarted, scaled and upgraded on separate schedules, and a shared memory between them is a liability one side always ends up holding.

The practical consequence for anyone building now is not "wait". It is: budget for rewriting. Five revisions in twenty months, the latest of which removed foundations. Whatever you build this quarter, plan to touch it again within the year, with some comfort in the direction of travel being toward simplification rather than away from it.

For pasting into an issue or a chat, where a screenshot is useless:

This table lists what changed, not everything that changed. Each revision contains housekeeping I have left out on the grounds that nobody would link to a row about it, and that judgement is mine and arguable. Where a revision says "nothing taken back", that means the revision list records nothing, not that I have diffed the specifications line by line.

The primary source is one click away and is the thing you should check before quoting me. I will keep this page current as revisions land — it is the only thing I have written about MCP that does not go stale.

This page pulls together material from three longer articles: where MCP and REST came from, what MCP costs in tokens, and what an MCP server is actually made of.

The MCP specification is published at modelcontextprotocol.io; this used revisions 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28, plus the official changelog for the last of them. Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures (2000), chapter 5, for the statelessness constraint. Last updated 19 August 2026.