Revisions and Era Compatibility

## What the string is A Model Context Protocol version is a date, written `YYYY-MM-DD` — for example `2026-07-28`. It is an opaque identifier that both sides compare for equality against a list; it is not a semantic version, so there is no major/minor/patch split and no arithmetic like "anything 2.x is compatible". Ordering by date is meaningful for humans reading a changelog, but a client does not get to assume that a later date is a superset of an earlier one. ## What the date actually marks The date names the day of the **last backwards-incompatible change** to the specification. This is the detail interviewers probe. A revision can keep receiving backwards-compatible work — clarifications, a new optional field, a new optional error detail — without the version string moving at all. So two implementations both claiming `2026-07-28` may have been written against slightly different snapshots of the same revision, and the only guarantee is that nothing incompatible separates them. The converse is the useful rule for implementers: **if the date changed, something breaking changed**, and you must read the migration notes rather than assume a drop-in upgrade. ## The revision history The released revisions, in order, are: - `2024-11-05` — the first published revision. - `2025-03-26` — introduced Streamable HTTP and deprecated the older HTTP+SSE transport. - `2025-06-18` - `2025-11-25` — the last revision of the handshake era. - `2026-07-28` — **current**. This is the revision that removed the `initialize` handshake and protocol-level sessions and made MCP a stateless protocol in which every request is self-contained. That last jump is why the version string matters so much in practice in 2026: the deployed fleet straddles the two eras, and the version a request declares is what tells a server which set of rules the caller is playing by. ## Draft, Current, Final Each revision also carries a lifecycle status: - **Draft** — still being written. Not ready for implementation; anything in it may change. - **Current** — the latest revision that is ready to implement. It may still take backwards-compatible changes without a new date. - **Final** — no longer receiving changes of any kind. Superseded revisions end up here, which is what makes them safe to implement against for compatibility purposes. At the time of writing, `2026-07-28` is Current and the earlier dates are Final. ## Where the version travels Before revision 2026-07-28, the two sides agreed a version once, during the `initialize` handshake, and the connection then ran under it. That handshake was removed in 2026-07-28. In the current revision every single request declares its own protocol version in its metadata, and over Streamable HTTP the same value is also carried as a request header. There is no negotiation step and no agreed state: the server simply looks at each request, decides whether it will serve that revision, and answers or rejects it independently. A consequence worth stating out loud in an interview: a server does not "become" a version for the duration of a connection. It has a set of revisions it is willing to serve, and each request is judged against that set on its own. ## What happens on a mismatch If the declared revision is one the server will not serve, it answers that request with the JSON-RPC error `-32022`, `UnsupportedProtocolVersionError`, whose `data` carries `supported` (the revisions the server will serve) and `requested` (what the caller asked for). Because there is no session to invalidate, this is a rejection of one request, not of the connection — the correct client behaviour is to re-issue with a version from `supported`, not to tear the transport down. ## Why date-based versioning at all Date versions suit a specification that evolves as a series of dated snapshots rather than a library with a release cadence. They read unambiguously in a changelog, they sort naturally, they never invite a false compatibility inference from a shared major number, and they make "which snapshot were you written against" a question with one obvious answer. The cost is that you cannot look at two versions and mechanically decide whether one contains the other — you have to consult the revision's own compatibility notes. ## Interview framing Say plainly: dates, not semver; the date is the last breaking change; additive work does not move it; statuses are Draft, Current, Final; `2026-07-28` is current and is the revision that made MCP stateless. Getting the "last backwards-incompatible change" phrasing right is the part that separates a memorised answer from an understood one.