Protocol Revisions

MCP revisions are dated, not numbered. The current revision is 2025-11-25. The previous one was 2025-06-18. Before that, 2025-03-26. Date-based versioning has two virtues: nobody argues about whether a change is "major" enough for v2, and everyone knows at a glance how stale a given pin is.

Each revision is its own immutable URL on the spec site (modelcontextprotocol.io/specification/2025-11-25). Once published, a revision does not change — typo fixes get errata pages or roll into the next revision, never silent edits. This is what lets you pin a server to a revision and reason about its behavior: "this server conforms to 2025-11-25" is a sentence that retains its meaning forever.

Implementations advertise the highest revision they understand at the initialize handshake. The negotiated revision for a session is the highest both sides know about. New revisions add features (CIMD, async tasks, the extensions framework) and occasionally deprecate old ones (HTTP+SSE), but always inside the additive-with-deprecation-window discipline of the next lesson.

Code

Pinning + negotiating a revision·python

# Client side — what we know how to speak
client_protocol_version = "2025-11-25"

# Server's response in initialize tells you what was actually negotiated
init = await session.initialize()
print(init.protocolVersion)  # may equal or be lower than what client advertised

# In tests, assert the negotiated version. A drift is a signal that one
# side fell behind.
assert init.protocolVersion == "2025-11-25"

Code

External links

Exercise

Progress

Comments 0