Every MCP revision, and what each one took back
MetronomMCP is twenty months old and has had five specification revisions. I put them all in one table...
MCP is twenty months old and has had five specification revisions. I put them all in one table because the shape of the list says more than any single entry does.
Read the removals, not the additions. Batching arrived in March 2025 and was gone by June, before it was three months old, which tells you it was never load-bearing: nothing had been built on it, so the specification was free to admit the mistake. Sessions and the opening handshake went on 28 July 2026, and that is a different kind of news entirely. A capability deleted in month seven is a correction. A rework of the foundations in month twenty means the foundations were wrong.
| Revision | Added | Taken back |
|---|---|---|
| 2024-11-05 | JSON-RPC; stdio and HTTP+SSE; tools, resources, prompts | — |
| 2025-03-26 | OAuth 2.1; Streamable HTTP; batching | HTTP+SSE |
| 2025-06-18 | Structured output | Batching, under three months old |
| 2025-11-25 | Icons; schema defaults; JSON Schema 2020-12 | Nothing the revision list records |
| 2026-07-28 | Capability-listing call; "input required"; response cache hints; routing headers | Sessions; the handshake; stream resumption. Deprecated with a year of grace: server-to-model calls, folder access, protocol-level logging, dynamic client registration |
The 2026-07-28 row is the one worth arguing about. Removing sessions made MCP stateless, which is Fielding's second REST constraint, adopted twenty months late by a protocol that had started from the opposite premise. Everything else in that revision follows from it: response cache hints, and headers carrying enough routing information that a proxy can direct a request without parsing the body. These are the features you add when your protocol has to survive contact with ordinary infrastructure.
My reading, and you are welcome to disagree with it: the reversal is late and right. Sessions in a protocol living 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.
Nothing broke on 28 July. The revision came out as a Release Candidate, the SDKs are in beta, and everything deprecated has a year of grace. The practical consequence is not "wait", it is "budget for rewriting".
Source: modelcontextprotocol.io, 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. I keep this table current as revisions land, with per-revision anchors so you can link to a row rather than to a page: https://dorokhovich.com/blog/mcp-revision-history
One real question: is there a row here you would have filled in differently? The 2025-11-25 line in particular says "nothing the revision list records", and that is a claim about a changelog rather than a line-by-line diff. If you have diffed it, tell me what I missed.