protocol version
Also written protocol revision, protocolVersion
The latest MCP protocol version is 2026-07-28. MCP versions by date rather than by number, and the spec calls each version a revision. On 2025-11-25 and earlier the client proposes one during initialize and the server answers with the one it will use; from 2026-07-28 every request names its version in _meta.
Updated
What is the MCP protocol version?
A dated snapshot of the specification, such as 2025-06-18 or 2025-11-25. The spec calls each one a revision, and it appears as protocolVersion in the initialize exchange on every revision up to 2025-11-25.
The date marks the last time a backwards-incompatible change was made. Compatible changes land inside the current revision without a new date, so a later date means something broke, and the shape of the string tells you nothing about how much.
Every revision so far
| Revision | What changed |
|---|---|
2024-11-05 |
The first published revision. Remote servers used the HTTP+SSE transport. |
2025-03-26 |
Streamable HTTP replaced HTTP+SSE, OAuth 2.1 authorization arrived, and tools gained annotations such as read-only and destructive. |
2025-06-18 |
JSON-RPC batching removed, structured tool output and elicitation added, servers classed as OAuth resource servers, and HTTP requests must carry an MCP-Protocol-Version header. |
2025-11-25 |
Icons on tools, URL-mode elicitation, tool calling inside sampling, Client ID Metadata Documents for registration, and experimental tasks. |
2026-07-28 |
The current revision. The initialize handshake and Mcp-Session-Id are gone, every request carries its version in _meta, and servers must answer server/discover. |
Each line is a summary of the official changelog for that revision, which lists the full set.
Which version will a server actually use?
Whichever one it answers with, not the one you asked for. Up to 2025-11-25 the client proposes a revision in initialize, and the server decides and states its choice in the response.
This is the part implementers most often get wrong, because a proposal that goes unchallenged looks like agreement. A client that assumes its own preference was accepted will send messages the server may not understand.
From 2026-07-28 there is no handshake to get wrong. Each request names its version, a server that does not support it returns UnsupportedProtocolVersionError with the versions it does, and a client that wants to choose up front calls server/discover first.
Which versions do servers actually run?
Mostly not the latest one. On 20 August 2026 we called the remote servers listed in the official MCP registry, and 694 completed a handshake. These are the revisions they answered with:
| Revision | Servers |
|---|---|
2025-11-25 |
382 |
2025-03-26 |
147 |
2024-11-05 |
82 |
2025-06-18 |
80 |
2026-07-28 |
3 |
So 309 of 694 were on a revision older than 2025-11-25, 82 were still on the first one ever published, and only 3 answered on the current one. The method and the rest of the figures are in the registry census.
Any figure we publish records the revision it was measured on, because a result stored today becomes uninterpretable once the handshake that produced it no longer exists.
Example
The 2026-07-28 revision is the sharpest case for why the recorded revision matters: it removes the initialize handshake and Mcp-Session-Id entirely, moves client info into _meta on every request, and adds server/discover. A tool count captured under 2025-11-25 was produced by a conversation that revision no longer has, so the number only means something alongside the revision it came from.