Home · Guides

MCP protocol versions

MCP versions are dates in YYYY-MM-DD form, and the date is the last time a backwards incompatible change was made, not the last release. The current protocol version is 2026-07-28, read off modelcontextprotocol.io/specification/versioning on 2026-09-08. Backwards compatible improvements ship without moving the number.

Where the version lives

Every request declares its own version in the io.modelcontextprotocol/protocolVersion key of its _meta field, and the server accepts or rejects each request independently. On streamable HTTP the same value is mirrored into the MCP-Protocol-Version header so an intermediary can read it without parsing the body. Clients and servers MAY support several versions at once.

That is a real change in shape. Earlier revisions established a connection-scoped session with an initialize handshake, and negotiated once. Now the unit of negotiation is the request.

What changed in 2026-07-28

The GET stream endpoint was removed from streamable HTTP.
Protocol-level sessions were removed from streamable HTTP.
Server-to-client interactions, meaning sampling, elicitation and roots, are embedded in results as input requests under the multi round-trip request model rather than sent as separate JSON-RPC requests on a stream. In revisions 2025-03-26 through 2025-11-25 a server could send such requests on an SSE stream; it cannot now.
Servers no longer initiate JSON-RPC requests at all. The specification states the only two message directions: client requests and notifications to the server, server responses and notifications to the client.

The versions people still run into

Version	What it is remembered for
`2024-11-05`	The HTTP+SSE transport, two endpoints, replaced in 2025-03-26.
`2025-03-26`	Streamable HTTP introduced. A server supporting older clients MAY read a request with no `MCP-Protocol-Version` header as this version.
`2025-06-18`	Introduced the `MCP-Protocol-Version` header. Before it, there was no header to omit.
`2026-07-28`	Current. Sessions and the GET stream removed; per-request negotiation.

The header rule is the one worth writing down. A server that supports pre-2025-06-18 clients MAY treat a request with no MCP-Protocol-Version header as 2025-03-26. A server that does not support them MUST reject a request without the header. Both are conformant, which means the same missing header produces a working connection against one server and a rejection against another.

Deprecation, and how long you have

Features can be marked Deprecated without being removed. A deprecated feature documents a migration path or states that none is needed, and stays in the specification for at least twelve months, or at least ninety days under the expedited-removal exception, before it is eligible for removal. Revisions themselves are marked Draft, Current or Final; a Final revision will not change again.

How to tell what you are speaking

# streamable HTTP: the header is on the request, so read your own client's
curl -i -X POST https://example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/list' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

On stdio there is no header to read, so the version is in the body of every message you send. If you are debugging a version mismatch on stdio, log the _meta block rather than looking for an envelope that does not exist.

Why this bites server authors more than client authors

A client ships as one product and can decide which version it speaks. A published server is called by clients of several eras at once. This repository's 30 servers are reachable from Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline and the claude.ai connector form, and those do not move in step. The compatibility matrix in the specification's backward compatibility section is the thing to read before you assume the version you developed against is the one arriving.

Questions

Do I have to support old versions?

No, and the specification makes both choices conformant. A server that rejects a request with no MCP-Protocol-Version header is correct; so is one that reads it as 2025-03-26. Pick one deliberately and document it, because callers cannot tell which you chose except by being rejected.

Does the version number change on every release?

No. It moves only when a backwards incompatible change lands, which is why the dates are months apart. A specification update that adds something compatible keeps the same identifier.

What replaced the initialize handshake?

Per-request negotiation. Each request carries its protocol version and client capabilities in its _meta field, and the server accepts or rejects it on its own. Earlier revisions set that up once per connection, and the backward compatibility rules describe how each side detects which era the other is from.

Where does the MCP-Protocol-Version header apply?

Streamable HTTP only. It mirrors a body field so intermediaries can route without parsing. stdio has no header layer, so the same information lives only in _meta.

All MCP servers and prices · All guides · Buy the bundle $39