SignorCrypto note · AI
MCP 2026-07-28 Specification: What Changes for Developers
The stateless core, MRTR and authorization changes in the 2026-07-28 release, and what server builders must check

The 2026-07-28 revision of the Model Context Protocol (MCP) turns the protocol into a stateless request/response system. Each request now carries its own protocol version and client capabilities, the initialization handshake and the Mcp-Session-Id header are removed, and any server instance behind a plain round-robin load balancer can answer. Server-initiated requests for elicitation, sampling and roots are replaced by a retry pattern called Multi Round-Trip Requests (MRTR). For teams running remote MCP servers, this is a migration project rather than a patch: the maintainers say the biggest changes are breaking ones.
What the 2026-07-28 release changes
Verified facts: the MCP maintainers released the 2026-07-28 specification and updated the TypeScript, Python, Go and C# SDKs on the same day, with a Rust SDK in beta. The previous revision was 2025-11-25. The maintainers describe the stateless core as the headline change, moving MCP from a bidirectional stateful protocol to a request/response one (MCP blog, 2026-07-28).
SignorCrypto analysis: the practical gain is that scaling no longer depends on sticky sessions or shared session storage. The cost is that any code relying on session identifiers must be redesigned.
Stateless requests and discovery
The initialize and initialized exchange and the Mcp-Session-Id header are retired. Every request carries its protocol version, client identity and capabilities in _meta, under keys such as io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities. The official changelog states that servers MUST implement server/discover, which advertises supported versions, capabilities and identity; clients MAY call it before other requests. A version mismatch returns UnsupportedProtocolVersionError.
Dropping protocol-level sessions does not make an application stateless. The maintainers recommend minting an explicit handle from a tool and letting the model pass it back as an argument, so the state is visible rather than hidden in the transport.
What tool authors should change
- Replace session-identifier logic with explicit, server-minted handles.
- Make tool catalogs independent of the connection: list endpoints no longer vary per connection.
- Expect clients to send
clientInfoon every request.
Multi Round-Trip Requests replace held-open streams
MRTR lets a server pause a call that needs input. The server returns a result with resultType set to input_required and an inputRequests field; the client repeats the original call with the answers in inputResponses. This replaces the server-initiated elicitation/create, sampling/createMessage and roots/list requests that previously required an open stream.
Every result now carries a required resultType: complete for ordinary responses, input_required for interim MRTR results. Clients must treat a result from an older server that omits the field as complete. The changelog also removes the elicitation completion notification and the elicitationId field; the client learns the outcome of an out-of-band interaction by retrying the original request.
Routing, caching and error codes
Streamable HTTP POST requests must include Mcp-Method and Mcp-Name headers, so gateways can route, meter or authorize without parsing JSON bodies. Results from tools/list, prompts/list, resources/list and resources/read carry ttlMs and cacheScope, which lets clients cache catalogs safely.
SignorCrypto analysis: these headers are set by the client, so a gateway should reconcile them with the JSON body before making authorization decisions. The changelog's addition of HeaderMismatchError to the schema suggests the specification expects that check. The resource-not-found code also changed from -32002 to -32602 (Invalid Params), so error handlers that match the old number need updating.
Authorization hardening and deprecations
Authorization servers should return the iss parameter defined in RFC 9207, and clients must validate it before redeeming an authorization code. Client credentials are bound to the issuer that minted them. Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents (CIMD); it still works but will be removed in a future version.
Roots, Sampling and Logging are deprecated and will keep working for at least twelve months. The legacy HTTP+SSE transport has a year-long offramp. Tasks move into the io.modelcontextprotocol/tasks extension, with polling through tasks/get and client input through tasks/update.
Migration checklist
- Inventory every use of
initialize,Mcp-Session-Idand server-initiated requests. - Move per-session state into tool-minted handles or an external store keyed by an explicit identifier.
- Implement
server/discoverand test version negotiation. - Validate
Mcp-MethodandMcp-Nameat the gateway. - Confirm that clients validate the
issparameter. - Plan the move from Dynamic Client Registration to CIMD.
Frequently asked questions
Does MCP 2026-07-28 remove sessions completely? Protocol-level sessions and the handshake are removed. Applications can still keep state, but it must be explicit, for example a handle returned by a tool.
Do existing servers break? Some do. The maintainers say the SDKs include migration notes, and that developers who depended on session identifiers face the largest migration cost.
Sources and limits
- MCP blog: The 2026-07-28 Specification (primary, maintainers)
- MCP specification 2026-07-28: Key Changes (primary, normative changelog)
- Cloudflare: The next generation of MCP (vendor implementation notes)
- RFC 9207: OAuth 2.0 Authorization Server Issuer Identification (standard referenced by the release)
The primary sources cover the specification and SDK status. Vendor statements from Cloudflare, AWS and Microsoft describe their own deployments and are not independent measurements. This article does not verify production performance gains or how many clients already support the new revision.
Next step
If your team is planning an MCP server migration, the work usually touches authorization, gateway routing and state design at the same time. Ask SignorCrypto for a technical review of the architecture before you change production endpoints.