Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, email [email protected] and we’ll put it right.
MCP protocol Scoring Remote servers Packages Building

MCP specification versions and changes

The Model Context Protocol is versioned by date, not by a semver number, and the current revision is 2026-07-28. Five revisions have shipped so far (2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28), each identified by the YYYY-MM-DD string of the day it shipped.

How that string is exchanged changed in the current revision. Up to and including 2025-11-25, client and server agreed on a version during an initialize handshake: the client proposed a protocolVersion and the server replied with the version it would actually speak. 2026-07-28 removed that handshake. Every request now declares its own version in _meta (and in the MCP-Protocol-Version header over HTTP), and a server that does not implement it replies with an UnsupportedProtocolVersionError listing the versions it does support. Servers must also implement server/discover, which reports supported versions, capabilities and identity in a single call.

The spec calls those two halves legacy (handshake-based, 2025-11-25 and earlier) and modern (per-request metadata, 2026-07-28 and later). They are not wire-compatible, so a client that speaks only one era cannot talk to a server that speaks only the other.

Whichever era a server is on, one pinned to an old revision quietly opts out of everything added since, and risks falling out of support as clients drop older revisions.

The published revisions

Newest first:

  • 2026-07-28 (current), the revision VerifyMCP treats as up to date, and the one that made the protocol stateless.
  • 2025-11-25, the last revision built on the initialize handshake.
  • 2025-06-18
  • 2025-03-26
  • 2024-11-05, the original release, with no prior version.

The canonical list of revisions lives on the official specification site.

How does VerifyMCP use the spec version?

When we score a remote server we ask it which version it speaks, and check the answer against the current revision. We probe server/discover first and read the newest version it advertises; if the server is on the legacy era we fall back to initialize and read the version it negotiates. Either way, the version we score is the newest one the server told us it can speak.

The current version (2026-07-28) earns full recency credit, and so does the one immediately before it (2025-11-25), which stays at full marks for a release cycle so you have time to upgrade. Anything older is penalised: it earns only partial credit, and the older the revision, the less it earns. The mechanics, including the supported-version window, are set out in the remote endpoint rubric.

If your server is negotiating an old version, the fix is almost always a single SDK upgrade. See negotiate a current protocol version for the concrete steps.

Per-version adoption statistics across the servers we have scored are coming to this page.

Written by Stuart Blackler.