MCP 2026-07-28 Spec: Stateless Core, What Breaks

On 28 July 2026 the Model Context Protocol published its 2026-07-28 specification. The headline change from the previous revision, 2025-11-25, is that the protocol is now stateless: the initialize handshake and session IDs are gone, and every request is self-contained. That makes serverless and edge deployment straightforward, but it also guarantees work for existing MCP server implementations. This article walks through the changes from a migration standpoint.

Previously a connection opened with initialize, was confirmed by notifications/initialized, and subsequent requests assumed that context. The handshake is gone entirely; every request now carries its own context in _meta.

- io.modelcontextprotocol/protocolVersion — the protocol version for this request
- io.modelcontextprotocol/clientCapabilities — client capabilities
- io.modelcontextprotocol/clientInfo — client identity (SHOULD)
- Servers SHOULD identify themselves via io.modelcontextprotocol/serverInfo in each result's _meta

Version mismatches return UnsupportedProtocolVersionError. The implication is blunt: servers that assume state persists between requests will not work as written. Code that stashes handshake capabilities in an instance variable has to be rewritten to read them per request.

In place of the handshake, servers MUST implement the server/discover RPC, which advertises supported protocol versions, capabilities and identity. Clients MAY call it before anything else for up-front version selection, or use it over STDIO as a backward-compatibility probe. Because the call is optional for clients, a server must still answer correctly when it is never called.

The Mcp-Session-Id header is removed from the Streamable HTTP transport, and tools/list, resources/list and prompts/list must no longer vary per connection. The same request to the same server returns the same listing for everyone.

So where does cross-call state live? The spec's answer: server-minted handles passed as ordinary tool arguments. A post-login cursor, an in-flight job ID, a temp-file reference — all become explicit parts of the tool schema rather than implicit protocol state. The more your implementation leaned on the session, the larger the redesign.

The HTTP GET endpoint and resources/subscribe / resources/unsubscribe are replaced by subscriptions/listen, a single long-lived POST-response stream. Clients opt in to specific notification types (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions), and the server tags notifications with io.modelcontextprotocol/subscriptionId.

Watch one detail: request-scoped notifications such as notifications/progress and notifications/message do not flow on that stream. They continue to arrive on the response stream of the request they belong to. Moving progress handling to subscriptions/listen is a mistake. Separately, logging/setLevel is gone; log level is set per request via io.modelcontextprotocol/logLevel in _meta, and servers MUST NOT emit notifications/message for requests that omit that field.

Statelessness makes server-initiated requests (roots/list, sampling/createMessage, elicitation/create) untenable. The replacement is the MRTR pattern.

- When a server needs more information mid-request, it returns an InputRequiredResult (resultType: "input_required") whose inputRequests field carries what it needs
- The client re-issues the original request with inputResponses attached
- Every result now carries a required resultType, either complete or input_required
- Results from earlier-protocol servers that omit the field MUST be treated as complete

As a consequence, notifications/elicitation/complete and the elicitationId field of URL-mode elicitation — both introduced in 2025-11-25 — are removed. With outcomes learned via retry, a completion signal and its correlation ID no longer fit. Servers that need to correlate across retries encode their own identifier in requestState.

A governed framework for official extensions arrives, with an extensions field added to ClientCapabilities and ServerCapabilities. The experimental tasks feature leaves core and is redesigned as the official io.modelcontextprotocol/tasks extension.

- The blocking tasks/result method is replaced by polling via tasks/get
- A new tasks/update carries client-to-server input
- tasks/list is removed
- Servers may return task handles unsolicited, without per-request opt-in

If you implemented long-running work as a core feature, you now declare it as an extension capability. For hands-on integration of MCP servers, see Claude Code and MCP integration guide.

The OAuth 2.0 / OIDC surface gets practical tightening so MCP servers connect to enterprise identity systems such as Entra or Okta without workarounds.

This revision formalises a feature lifecycle and deprecation policy: Active, Deprecated and Removed states, a minimum twelve-month deprecation window, and a registry of deprecated features. The following remain in the spec but should not be adopted by new implementations.

- Cache hints required on listings: tools/list and friends must return ttlMs and cacheScope (public / private) to cut polling
- Deterministic tool order: tools/list SHOULD return a stable order to help client-side caching and prompt cache hit rates
- Request headers: Mcp-Method and Mcp-Name are required on Streamable HTTP POSTs, and x-mcp-header allows custom headers from tool parameters
- SSE resumability removed: Last-Event-ID and event IDs are gone; a broken stream means re-issuing the request with a new request ID (MUST)
- Error code policy: -32000 to -32019 stays implementation-defined, -32020 to -32099 is reserved for the spec; resource-not-found moves from -32002 to -32602 (Invalid Params)
- Looser schemas: inputSchema / outputSchema accept any JSON Schema 2020-12 keywords, and structuredContent accepts any JSON value
- Tracing: OpenTelemetry trace context propagation via _meta keys traceparent, tracestate and baggage is now documented convention
- ping removed: implementations that relied on it for liveness need another mechanism

- Have you replaced every dependency on initialize data with per-request _meta reads?
- Have you implemented server/discover (MUST)?
- Has session-based state moved to server-minted handles passed as tool arguments?
- Do tools/list and friends return identical results regardless of connection?
- Are ttlMs and cacheScope present on listing results?
- Does every result carry resultType?
- Are server-initiated requests (sampling / elicitation / roots) reworked as MRTR?
- Is task support re-declared as the io.modelcontextprotocol/tasks extension?
- Have subscriptions moved to subscriptions/listen, with progress notifications left on the response stream?
- Is log level read from _meta, with no notifications/message emitted for requests that omit it?
- Are credentials keyed by issuer, and is iss validated?
- Do any clients still rely on SSE resumability instead of re-issuing broken requests?

The twelve-month minimum deprecation window means implementations using Roots, Sampling or Logging will not break immediately. Statelessness itself, however, is a breaking change: adding resultType and implementing server/discover are unavoidable the moment you target the new revision. The pragmatic order is to handle the core first — statelessness, resultType, server/discover — and replace deprecated features over the grace period. If you are writing a new MCP server today, design it without the deprecated features from the start.

The 2026-07-28 revision moves MCP from a bidirectional stateful protocol toward something that behaves like an ordinary request/response HTTP API. In exchange for easy serverless deployment and scaling, the initialize handshake, session IDs, server-initiated requests and SSE resumability are all gone. For existing implementations, the two design decisions that matter most are where state now lives — server-minted handles — and how server-side questions fold into MRTR.