The Model Context Protocol published revision 2026-07-28 on July 28, replacing 2025-11-25, and the release post describes it as the change that makes MCP plain stateless request and response. For anyone running MCP servers in production, it is a migration: the maintainers themselves say the cost falls “especially for developers that did depend on session identifiers.”
What changes in the core
The changelog removes the initialize handshake and protocol-level sessions, including the Mcp-Session-Id header. Each request now carries its protocol version, client identity and client capabilities in _meta. Servers must implement a server/discover call that advertises what they support, though clients do not have to use it. State that a server still needs between calls travels as explicit handles that the server issues and the client passes back as ordinary tool arguments.
Several other pieces move with it:
- Headers for routing. Over Streamable HTTP,
Mcp-MethodandMcp-Nameheaders are required and must match the body, so gateways can route and authorize without reading it. - Cacheable lists. Results of
tools/list,prompts/listand resource listings now declarettlMsand acacheScope; private results must not be shared across authorization contexts. - Input mid-request. Servers no longer send their own requests to clients for elicitation, sampling or roots. They return a result marked
input_required, and the client retries the original request with the answers. - One subscription stream. A single
subscriptions/listenstream replaces the HTTP GET stream and resource subscriptions, and resuming a broken stream is no longer supported: the request has to be sent again. - Removed and deprecated.
pingandlogging/setLevelare gone. Roots, sampling and logging are deprecated with at least twelve months’ notice, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.
What does not have to change at once
Compatibility works by eras. A server can serve legacy initialize sessions and modern per-request _meta from the same endpoint, and the specification’s own matrix shows where it breaks: a modern-only client fails against a legacy server, a legacy client fails against a modern-only server, and dual-era clients and servers bridge both. Extensions such as long-running Tasks or MCP Apps are optional, disabled by default and outside the core.
Where the official SDKs stand
According to the release post, the four Tier 1 SDKs speak the new revision, and their release notes give the detail. The Python SDK 2.0.0 supports it and serves every earlier revision from the same server. TypeScript ships it in its 2.0 line, described in the release notes as a first beta, with a codemod and a migration guide. The Go SDK 1.7.0 supports it, but over Streamable HTTP only with its stateless option enabled; otherwise clients fall back to 2025-11-25. C# 2.0.0 aligns with the revision and flags the deprecated features with compiler warnings.
The practical order for a team: update the SDK, check where the code relies on session identifiers or server-initiated requests, and decide whether the server needs to be dual-era while older clients remain in use.
Related reading
- Versioning and compatibility in revision 2026-07-28 — MCP specification
- Python SDK migration guide — MCP
- Meta turns its developer tools into MCP services — IA al Día