MCP goes stateless: what changed in the 2026-07-28 specification

The 2026-07-28 revision of the Model Context Protocol (MCP) specification removes the initialize handshake, the Mcp-Session-Id header and server-initiated requests, making each request stateless and self-describing, according to the specification changelog. The fifth MCP revision requires every server to implement the new server/discover method, moves tasks into an extension, and deprecates roots, sampling and logging, which keep working for at least twelve months. Servers needing input now return an input_required result and clients retry the original request with the answers under the Multi Round-Trip Requests pattern.

MCP goes stateless: what changed in the 2026-07-28 specification What struck me most about the 2026-07-28 revision https://modelcontextprotocol.io/specification/2026-07-28/changelog of the Model Context Protocol MCP is how much it takes away. The handshake is gone, sessions are gone, and a server can no longer send requests to the client. It’s the fifth revision of the specification, and its changes reach every layer of a server. This is part 2 of my series on what an MCP server does under the 2026-07-28 specification; part 1 https://pournasserian.com/writing/mcp-2026-what-a-server-does was about why a server is much more than a list of tools. I’ve summed up this change in a paragraph twice before, in my review of MCP testing tools https://pournasserian.com/writing/mcp-server-testing-tools-2026 and in what AI hosts require of an MCP server https://pournasserian.com/writing/what-ai-hosts-require-of-an-mcp-server . This is the longer version, with the facts as I read them in October 2026. In brief 1. MCP no longer has sessions. The initialize handshake and the Mcp-Session-Id header are gone, so each request stands on its own and names the protocol version it speaks. 2. A server can’t send requests to the client any more. To ask for input, it answers with an input required result, and the client sends the request again with the answers. 3. Every server MUST implement the new server/discover method. Calling it is optional for clients. 4. Tasks moved into an extension, and roots, sampling and logging are deprecated. A deprecated feature keeps working for at least twelve months, with two exceptions. 5. I see this as mostly good news for a server in the cloud. Any request can land on any instance; what stays long-lived or stateful needs deliberate design. Five revisions, named by date MCP versions are named by their release date, not by a number. Each revision has its own changelog, and the specification’s home page always points at the latest one. Here are the five so far, with the headline changes of each. The original HTTP transport, HTTP with Server-Sent Events SSE , known as HTTP+SSE, gave way to Streamable HTTP https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http in the 2025-03-26 revision and is now on its way out. Sampling, roots and elicitation all arrived in earlier revisions, and all three relied on the server sending requests to the client. That mechanism is what 2026-07-28 takes away. The headline: no more sessions MCP used to be a stateful, bidirectional protocol. A client opened a session with an initialize handshake, the server handed back an Mcp-Session-Id , and the two sides could send requests to each other for as long as the session lasted. Under the 2025-11-25 revision, a tool call that needed the user’s input went like this: That model fits a long-running desktop process well. It fits a horizontally scaled cloud service badly: you need sticky load balancing or shared session storage, and a dropped connection takes its context with it. The 2026-07-28 revision removes all of that: - No handshake. The initialize and notifications/initialized exchange is gone. Every request carries its own protocol version and client capabilities in meta . - No sessions. The Mcp-Session-Id header is gone, and list results no longer vary per connection. A server that needs state across calls mints explicit handles and passes them as ordinary tool arguments. - No server-initiated requests. A server that needs input returns an input required result, and the client retries the original request with the answers. This is the Multi Round-Trip Requests MRTR https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr pattern. The same tool call now looks like this. The retry is a new request with a new ID, and it carries the answers and the requestState the server returned: Required of servers, optional for clients My earlier summaries called server/discover mandatory, and that’s true from the server’s side: every server MUST implement server/discover https://modelcontextprotocol.io/specification/2026-07-28/server/discover , which advertises its versions, capabilities and identity. Calling it is optional for clients, which is why the diagram marks it optional. A client may skip it and send its first request straight away. What it means for a server in the cloud The specification describes the protocol, not how to host it, so this part is my advice. I see statelessness as mostly good news for cloud servers. Any request can land on any instance, so serverless hosting, autoscaling and blue/green deployments become simpler. The cost moves to two places: what really is long-lived subscriptions/listen https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions streams and Tasks and what really is stateful the handles a server mints . Those need deliberate design and a shared store, and later parts of this series show how. The full list of changes Nine major changes Each change came in through a Specification Enhancement Proposal SEP , MCP’s change process. The first three rows and row 7 are the headline again, with their SEP numbers and the exact meta keys. | | Change | SEP | |---|---|---| | 1 | Sessions and the Mcp-Session-Id header are removed; cross-call state moves to server-minted handles. | SEP-2567 | | 2 | The initialize handshake is removed. Each request carries io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities in meta , and a version mismatch returns UnsupportedProtocolVersionError . | SEP-2575 | | 3 | server/discover is added, and every server MUST implement it. | SEP-2575 | | 4 | subscriptions/listen replaces the HTTP GET endpoint and resources/subscribe with one opt-in, long-lived notification stream. | SEP-2575 | | 5 | ping , logging/setLevel and notifications/roots/list changed are removed. The log level is now set per request in meta . | SEP-2575 | | 6 | Tasks move out of the core into the official io.modelcontextprotocol/tasks extension, redesigned around polling. | SEP-2663 https://modelcontextprotocol.io/seps/2663-tasks-extension | | 7 | MRTR replaces the server-initiated roots/list , sampling/createMessage and elicitation/create . | SEP-2322 | | 8 | Every result carries a required resultType : "complete" or "input required" . | SEP-2322 | | 9 | SSE resumability is removed. A broken stream loses the request in flight, and the client re-issues it with a new ID. | SEP-2575 | Smaller changes worth knowing | Area | What changed | |---|---| | Capabilities | An extensions field in client and server capabilities. | | Tracing | OpenTelemetry trace-context keys in meta : traceparent , tracestate and baggage SEP-414 https://modelcontextprotocol.io/seps/414-request-meta . | | Tool lists | Servers SHOULD return tools/list in a deterministic order, to improve prompt-cache hit rates for clients and models. | | HTTP headers | On Streamable HTTP, Mcp-Method is required on every request, and Mcp-Name on tools/call , prompts/get and resources/read . Tool parameters can be mirrored to headers with x-mcp-header SEP-2243 . | | Caching | Caching hints https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching become required: complete results of server/discover , the list methods and resources/read MUST carry ttlMs and cacheScope , and an input required result carries none SEP-2549 . | | Errors | Resource not found changes from -32002 to -32602 Invalid Params , and the range -32020 to -32099 is reserved for the MCP specification. | | Authorization | Authorization servers SHOULD include iss in authorization responses, and clients MUST validate it SEP-2468 . Dynamic Client Registration requires an appropriate application type SEP-837 . Credentials are bound to the authorization server that issued them SEP-2352 . | | Schemas | inputSchema and outputSchema accept any JSON Schema 2020-12 keyword, and structuredContent can be any JSON value SEP-2106 . | | Elicitation | The URL-elicitation completion notification and elicitationId are removed. | Deprecated, not yet removed These six are deprecated: they still work, but new implementations shouldn’t adopt them. Each has a replacement: - Roots: pass directories or files as tool parameters, resource URIs or server configuration. - Sampling: call your own model provider’s API from the server. - Logging notifications/message : log to stderr on stdio, or use OpenTelemetry. - The HTTP+SSE transport: use Streamable HTTP. - The includeContext values thisServer and allServers in sampling requests: omit the field, or use "none" . - Dynamic Client Registration: use Client ID Metadata Documents. Registration remains for older authorization servers. How long do they keep working? The feature-lifecycle policy SEP-2596 sets a floor of twelve months. The specification’s deprecated registry https://modelcontextprotocol.io/specification/2026-07-28/deprecated makes roots, sampling, logging and Dynamic Client Registration eligible for removal no earlier than the first revision released on or after 2027-07-28. The includeContext values follow sampling’s schedule. The floor has two exceptions: - a feature that presents an active security risk can be removed sooner, after at least 90 days; - the HTTP+SSE transport, deprecated since 2025-03-26, has only a three-month grace period, counted from SEP-2596 reaching Final. Even when its window has passed, a feature only becomes eligible for removal. Taking it out is a decision for the core maintainers. Method and caveats - Built from chapter 2 of my guide to MCP servers in 2026, and written against the 2026-07-28 specification and its changelog as I read them in October 2026. - Where the specification is more precise than my notes how long a deprecated feature keeps working, which requests need the Mcp-Name header, which results carry caching hints , this article follows the specification’s own pages, as checked on 8 October 2026. - The smaller changes are given in brief. Later parts of this series cover caching and the HTTP headers in detail, and the deprecations in full, with each old pattern and what replaces it. Series What an MCP server actually does in 2026 Part 2 of 35 1. What an MCP server does in 2026: much more than a list of tools https://pournasserian.com/writing/mcp-2026-what-a-server-does 2. MCP goes stateless: what changed in the 2026-07-28 specification 3. server/discover: the one method every MCP server must implement https://pournasserian.com/writing/mcp-2026-server-discover 4. Server instructions: the paragraph every model reads first https://pournasserian.com/writing/mcp-2026-server-instructions 5. Stateless MCP requests: meta, resultType and explicit handles https://pournasserian.com/writing/mcp-2026-stateless-requests 6. Caching hints and pagination in MCP https://pournasserian.com/writing/mcp-2026-caching-and-pagination 7. MCP transports in 2026: stdio and Streamable HTTP https://pournasserian.com/writing/mcp-2026-transports