What does MCP protocol versioning look like in practice, and how do date-based spec revisions work?
Quick Answer
MCP has released several dated spec revisions since its initial announcement — 2024-11-05 (the original release, including the older two-endpoint HTTP+SSE transport), 2025-03-26 (introduced the OAuth 2.1-based authorization framework, tool annotations, and the Streamable HTTP transport replacing HTTP+SSE), and 2025-06-18 (added structured tool output, elicitation, resource links in tool results, removed JSON-RPC batch support, and tightened security guidance). Each revision is negotiated per-connection during initialize (covered in the fundamentals topic), so a client and server built against different spec dates can still interoperate as long as they agree on a mutually supported version. In practice, this means implementers need to track which spec revision an SDK or server actually targets, since a feature discussed in a blog post or tutorial (like sampling, or JSON-RPC batching) may or may not be present depending on the spec date both sides negotiate down to.
Detailed Answer
MCP versions by release date rather than semver, so it helps to have a rough timeline of what actually changed and when. "Does MCP support X" often depends on which spec revision you mean.
A rough timeline of major revisions
| Revision | Notable additions/changes |
|---|---|
2024-11-05 | Original public spec: core lifecycle, tools/resources/prompts, sampling, the original two-endpoint HTTP+SSE transport |
2025-03-26 | OAuth 2.1-based authorization framework for HTTP transport, tool annotations (readOnlyHint etc.), Streamable HTTP transport replacing HTTP+SSE, audio content support |
2025-06-18 | Structured tool output (structuredContent/outputSchema), elicitation, resource links in tool call results, removal of JSON-RPC batching, expanded security best-practices guidance |
Why this matters practically
If a tutorial or blog post describes MCP behavior without mentioning a spec date, it may be describing an earlier revision. Assuming batching is supported, or that Streamable HTTP doesn't exist yet, can lead to writing code against assumptions that no longer hold for the current spec.
How negotiation handles the gap
// A client built against 2025-06-18 connecting to an older server
{"method": "initialize", "params": {"protocolVersion": "2025-06-18", ...}}
// Server, only supporting an earlier revision, responds with what it has
{"result": {"protocolVersion": "2025-03-26", ...}}
The client then knows not to expect 2025-06-18-only features, like elicitation or structured output, for this particular connection, and should behave accordingly. This is exactly what the capability negotiation covered in the fundamentals topic is for.
The practical habit worth building
When picking an SDK, or reading MCP documentation and tutorials, check which spec revision it targets before assuming a specific feature — sampling, elicitation, a particular transport — is available. The protocol's backward-compatible negotiation model means old and new implementations can still talk to each other. That only works, though, if both sides are honest about, and respect, which revision they actually understand.