IA al Día
Back to archive
Tools explainer Jul 28, 2026 3 min read

MCP goes stateless: what a team running MCP servers has to change after the July 28 revision

The MCP revision of July 28, 2026 drops sessions and the handshake, adds cacheable lists and deprecates three features. What breaks and where SDKs stand.

primary source · modelcontextprotocol.io — Model Context Protocol 2026-07-28 changelog

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-Method and Mcp-Name headers are required and must match the body, so gateways can route and authorize without reading it.
  • Cacheable lists. Results of tools/list, prompts/list and resource listings now declare ttlMs and a cacheScope; 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/listen stream 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. ping and logging/setLevel are 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.