What does a protocol need to know about the previous request? For most HTTP services, nothing: statelessness is the default, sessions are an application-level concern, and anything requiring continuity is layered on top deliberately. MCP's Streamable HTTP transport, introduced in the 2025-11-25 revision, made a different choice. It retained the initialize handshake from the SSE transport that preceded it: client and server exchanged protocol version and capabilities once at the start of a connection, and subsequent requests carried an Mcp-Session-Id header that bound them to the established context. The rationale was practical. Capability negotiation happens once; repeating it on every call adds round-trip cost; the session gives the server a stable identifier to associate with any context it accumulates.
The revision published on 28 July 2026, documented in the official changelog at modelcontextprotocol.io/specification/2026-07-28/changelog, removes both. The initialize RPC is gone. The Mcp-Session-Id header is gone from the Streamable HTTP transport. Every request now carries protocol version, client information, and capabilities in its _meta field, making each call self-describing without a prior handshake. A new server/discover RPC, mandatory for every server declaring the 2026-07-28 specification version, replaces the handshake's capability exchange with a query the client can issue on demand. What the protocol previously established once at connection time now travels with every request, and the protocol no longer distinguishes which server instance handled the previous call.
#02What the stateless core changes for deployment
The scaling benefit is concrete. Under the 2025-11-25 specification, an MCP server running on more than one instance needed session affinity at the load balancer: every request from a given session had to reach the same instance, because only that instance had completed the handshake and only that instance held any session-level state the server might have accumulated. Sticky sessions are familiar infrastructure but imperfect; they defeat even traffic distribution, require drain logic when instances leave rotation, and make autoscaling groups harder to operate cleanly. A pod restart during an active session loses the session. Horizontal scaling under sudden load cannot distribute freely across all available instances without risking session interruptions.
A 2026-07-28 server deployment needs none of this. Each request arrives self-contained; any instance can handle it; the load balancer routes round-robin. The MCP specification changelog describes the result as making MCP a first-class HTTP workload, which is precise: the previous specification required infrastructure complexity that ordinary stateless HTTP services do not.
A server that stored no application state in the session required session affinity infrastructure without actually needing it: the protocol imposed the dependency whether or not the implementation used it.
“A server that stored no application state in the session required session affinity infrastructure without actually needing it: the protocol imposed the dependency whether or not the implementation used it.”
#03The question the session was answering
The upgrade path the revision asks of existing server implementations is not technically demanding. Implement server/discover. Stop issuing Mcp-Session-Id. Remove routing logic that depends on the session header. The backward compatibility mechanism is well specified: a 2026-07-28 client that receives a 2025-11-25 server's initialize response completes the handshake and proceeds correctly. Migration can be one-sided and gradual.
What the upgrade surfaces is a question many MCP server implementations will not have examined closely: what was in the session? If the server was stateless by design, the session identifier a routing token in the load balancer's configuration and nothing in the server code ever read it, then the revision changes nothing of substance. If the session held something real, that something now needs to live elsewhere. Authorisation context established at handshake time, tool state accumulated across a multi-step agent run, conversation history maintained in memory and keyed by session identifier: these are now the application's problem to place, not the protocol's.
The revision does not specify where. This is correct: the protocol should not be defining application state management. It does mean that teams relying on the session implicitly for continuity in long-running agent interactions will need to make an explicit choice. The options are familiar: client-side state threaded through each request, shared external storage, or a stateful server implementation keyed on something other than the protocol session identifier. The revision moves the decision into the open rather than allowing it to remain implicit in the handshake.
#04Mid-call confirmations without a persistent connection
The addition that deserves more attention than the stateless headline is Multi-Round-Trip Requests, specified in SEP-2322. MRTR gives a tool a mechanism to pause mid-execution and request additional input from the client before completing. The server returns a result with resultType: 'input_required', a set of structured input requests describing what is needed, and an opaque requestState blob. The client surfaces the prompts, collects responses, and re-issues the original tools/call with inputResponses and the echoed requestState. No persistent connection is required between the initial call and the retry; the exchange is stateless at the transport layer while the server's mid-computation state travels in the requestState blob.
The problem this solves is real. Destructive tool operations require confirmation before execution. The patterns available before MRTR were each imperfect in a different way: prompt the user before the tool call and hope the context has not changed, implement a two-phase protocol inside the tool itself and manage the state externally, or maintain a persistent connection and interrupt execution through a side channel. None of these compose cleanly with a stateless HTTP transport. MRTR gives the protocol a first-class mechanism for the pattern rather than leaving each tool implementation to solve it independently.
The requestState blob is the design choice worth examining. It is opaque to the client, which echoes it without interpreting it. The server encodes whatever it needs to resume the interrupted computation: partial results, execution position, references to resources already accessed, or a discriminator pointing to state in external storage. The protocol places no constraint on what goes in it. This flexibility is appropriate because the cost of serialising mid-computation state varies enormously depending on what the tool is doing, and a protocol-level format would have been either too prescriptive or too vague to be useful.
Whether MRTR holds up in practice for complex agent flows is something I am genuinely uncertain about. The mechanism is coherent; the primitive is correct. How it reads when an agent is twelve steps into a twenty-step plan and a confirmation prompt surfaces to a user who has moved on to something else depends on the host application's handling of the input requests and the latency between the pause and the retry. The spec defines the structure. How the structure reads as user experience is still being determined.
#05Routable headers and what they give infrastructure
SEP-2243 adds two required headers to Streamable HTTP POST requests: Mcp-Method, carrying the JSON-RPC method name, and Mcp-Name, carrying the name of the specific tool, resource, or prompt being invoked where applicable. The W3C traceparent header is added as a recommended third. The purpose is routing and observability: a gateway, rate limiter, or WAF can distinguish a tools/call invocation from a resources/read without inspecting the request body, and can identify which specific tool is being invoked without deserialising JSON.
This matters less in a single-server deployment running behind a dedicated load balancer, and more in any environment where MCP traffic passes through shared API infrastructure. A rate limit policy that applies differently to expensive tool calls than to lightweight capability queries can be expressed against these headers rather than requiring body inspection at the gateway. An audit log that wants to record which tools were invoked reads the header rather than parsing the payload. These are operational capabilities infrastructure teams eventually reach for, and having the transport-level signal available from the specification rather than as a retrofit is one of those things that reads as minor in a changelog and saves a meaningful amount of engineering work later.
#06Authorisation in the single-client-many-server pattern
The authorisation hardening in the revision addresses a class of attack specific to how MCP is deployed. MCP host applications connect to multiple servers, often across different trust boundaries, and the OAuth flows that authorise tool access involve the host acting as an OAuth client against multiple authorisation servers. RFC 9207 describes mix-up attacks: situations where a malicious server causes the client to use credentials intended for a different server. In a deployment with a single authorisation server this is a niche concern. In a multi-server MCP environment it is a realistic part of the threat model.
The 2026-07-28 revision requires iss validation per RFC 9207 (SEP-2468), adds application_type to Dynamic Client Registration requirements (SEP-837), and introduces credential binding to the issuing authorisation server (SEP-2352). These are normative requirements now rather than optional practices. For teams that have been treating MCP server authorisation as secondary infrastructure, the revision provides a clearer specification to implement against. The revision names the threat model explicitly, which is useful regardless of where an implementation currently sits: the single-client-many-server pattern is not the pattern that most OAuth guidance was written for, and the spec acknowledging that is a step toward the ecosystem taking it seriously.
Three revisions in eighteen months is a fast pace for a protocol with production deployments. The 2025-03-26 revision introduced Streamable HTTP; 2025-11-25 stabilised it; 2026-07-28 now removes the session layer the first Streamable HTTP implementation retained. Each revision has introduced migration cost and each has provided backward compatibility mechanisms that make migration manageable rather than urgent. The beta SDKs for Python and TypeScript published alongside the release candidate suggest the specification has reached a stability point the ecosystem is committing to.
What I am watching for is how the major host implementations handle the application state that used to live in the session. The revision makes a correct architectural call: session semantics belong to the application, not to the protocol. Protocols that absorb application concerns they do not need to carry become harder to scale and harder to extend. The question of what the session was carrying, and whether what it carried ends up somewhere coherent in the new arrangement, is the part of the 2026-07-28 story that is still being written, across tool implementations that currently range from simple read-only resource servers to complex multi-step orchestrators with their own conversation models. The specification is settled. How the ecosystem builds on it is not.