In a spec revision scheduled for publication on July 28, 2026, the Model Context Protocol (MCP) removes the initialization handshake and session from the protocol layer. MCP began in 2024 as a mechanism connecting locally running AI tools with data sources, but it has now entered a phase where remote servers are offered to many users, and per-connection state had become a burden on cloud operations. Under the new spec, each request carries the information it needs, so it can be handled by any server instance. That said, application state itself doesn't disappear—it becomes the implementer's responsibility to decide where that state moves and who verifies access to it.
The Departure of initialize and Mcp-Session-Id
On May 21, the MCP project locked in the 2026-07-28 release candidate, and the final spec is scheduled for publication on July 28. In the previous version, 2025-11-25, the client first sent initialize, exchanging the protocol version, capabilities, and client information with the server. Once a Streamable HTTP server issued an Mcp-Session-Id, the client had to attach that same ID to all subsequent requests.
The new spec removes both initialize and notifications/initialized. The protocol version and client capabilities now go into the _meta field of each request, and over HTTP the version number is also carried in the MCP-Protocol-Version header. Clients that want to know the server's supported version, capabilities, and identifying information up front can call the newly introduced server/discover.
| Item | 2025-11-25 |
2026-07-28 |
|---|---|---|
| Connection start | Negotiate version and capabilities via initialize |
No handshake |
| Protocol info | Exchanged at initialization and held for the connection | Sent via _meta and HTTP headers on each request |
| HTTP session | Resend Mcp-Session-Id once issued |
Session ID removed from the spec |
| Server capabilities | Obtained from the initialize response |
Obtained via server/discover if needed |
| Routing | Requires parsing the JSON-RPC body | Also distinguishable via Mcp-Method and Mcp-Name |
This difference amounts to more than just shaving one round trip off the initial connection. In conventional remote configurations, you might need sticky sessions that route the same connection back to the same server, or a session store shared across multiple instances. Because the new requests are self-contained, they can be sent to any available instance via ordinary round-robin. This reduces the burden of treating MCP as dedicated connection infrastructure, making it easier to layer onto existing load balancers and gateways.
Where Does the State Go?
Even with the session removed, state such as shopping carts, browsers, or database transactions still needs to exist somewhere. The new spec recommends a design in which a creation tool returns a basket_id or browser_id, and subsequent tool calls pass that same value as an argument. State is no longer hidden behind the connection—it's surfaced as data the model handles directly.
However, this doesn't mean MCP gains a new type called a "state handle." There's no RPC like handles/*; on the wire, it's simply an ordinary string embedded in tool results and arguments. The tool's description and input/output schema tell the model which values to pass into the next call. Implementers must design the issuance, storage, and revocation of handles themselves, on the application side.
Explicit handles have the advantage of making resumption easier. For a client that persists chat history, the handle is also stored in the conversation log, so the model can reference the same state even after a page reload or resuming on a different device. There's no need for a separate mechanism to re-save an Mcp-Session-Id outside the connection.
On the flip side, handles end up appearing in chat logs, sub-agent inputs, and copied text. An authenticated server must check the combination of the handle and the authenticated principal on every single call. On servers without authentication, the handle itself effectively grants access rights, which is why SEP-2567 recommends using cryptographically secure random values of at least 128 bits and setting expiration times. Going stateless is not a mechanism for skipping authorization—if anything, it shifts responsibility back onto correctly authorizing every single call.
HTTP Routing and MRTR Round-Trip Handling
For Streamable HTTP POST requests, the Mcp-Method header, which mirrors the JSON-RPC method, becomes mandatory. Operations that name a specific tool, resource, or prompt also carry an Mcp-Name header. This lets gateways perform per-tool routing, rate limiting, and policy enforcement without opening the request body—though servers must reject requests where the header and body disagree, to keep the routing-facing labels consistent with the actual processing.
List and resource responses gain a ttlMs field indicating freshness in milliseconds, and a cacheScope field indicating whether shared caching is permitted. Because results like those from tools/list no longer vary per connection, clients can cache them within a safe range instead of waiting indefinitely for notifications. In addition, the traceparent, tracestate, and baggage keys are standardized within _meta, tying together a single OpenTelemetry trace spanning the host, the MCP server, and everything downstream.
The flow by which a server asks the user for confirmation mid-processing has also been reworked. In Multi Round-Trip Requests (MRTR), the server returns an InputRequiredResult along with requestState, and the client puts the answer into inputResponses and resends the original request. Because the state is sealed inside the response itself, the resend doesn't need to go to the same instance as the original request. A server-to-client request is only made while the server is executing processing that the client itself initiated.
For use cases requiring continuous notifications, subscriptions/listen is introduced, replacing the previous HTTP GET along with resources/subscribe and resources/unsubscribe. Long-lived connections themselves aren't disappearing—rather, only clients that explicitly opt in to receive change notifications open a dedicated stream. Notifications belonging to an individual request, such as progress updates, flow through that request's own response stream. The reasons for—and scope of—keeping a connection open are now defined more narrowly than before.
Tasks Moves to an Extension, Three Features Head Toward Retirement
While reducing features from the core, 2026-07-28 formally establishes the extension mechanism as the official development path. Extensions are identified by reverse-domain-name-style IDs, and clients and servers agree on them through a capability map. Because extensions can have their own versioning, release schedule, and maintainers separate from the core spec, features with limited applicability can be tried out without burdening every implementer.
Tasks, which handle long-running operations, was experimentally added to the core in 2025-11-25, but this time it moves to the io.modelcontextprotocol/tasks extension. It is not wire-compatible with the old API, and tasks/result and tasks/list are removed. In the new flow, the server decides whether to turn something into a task, and the client tracks it using tasks/get, tasks/update, and tasks/cancel. Because there's no session to safely partition per-caller lists, tasks/list was not retained.
Roots, Sampling, and Logging move to Deprecated status. Roots let the server know which directories to work on, Sampling let a server request generation from a model on the client side, and Logging sent structured logs within the protocol. Their replacements are tool arguments or resource URIs, the LLM provider's own API, and stderr or OpenTelemetry, respectively.
Deprecated does not mean already removed. All three features will remain in the spec for at least a 12-month transition period, and removal requires a separate Specification Enhancement Proposal (SEP). It's a signal that new implementations should not adopt them, while existing implementations should begin migrating. By defining states—Active, Deprecated, Removed—along with minimum durations, future core features can now proceed through a retirement process without having to wait for a sweeping overhaul like this one.
July 28 Is Not a Shutdown Date
The new spec contains breaking changes, but that doesn't mean existing servers will stop working on July 28. That date marks the scheduled publication of the normative spec text—it is not a day on which users are forcibly switched off the old protocol. New clients can try server/discover first and fall back to initialize for implementations that turn out to be older servers.
On June 29, beta support began across four Tier 1 SDKs: Python, TypeScript, Go, and C#. However, the migration approaches aren't uniform. Python v2 responds to both old and new protocols on a single endpoint, while TypeScript v2 and Go require explicitly enabling the new protocol. The C# preview starts HTTP in stateless mode. For TypeScript, migrating the SDK to v2 and actually speaking 2026-07-28 on the wire are also separate steps.
Although the spec's changes are concentrated around the session, peripheral differences matter during migration testing too. Tool input/output schemas are expanding to JSON Schema 2020-12, and the error code for a resource-not-found case changes from -32002 to -32602. For authorization, implementers must verify that the iss included in the response matches the recorded issuer, and must explicitly declare the OpenID Connect application_type at registration time. Stored client credentials are bound to a specific issuer and cannot be reused with a different authorization server.
The more custom a client or server implementation is, the less it can get away with simply updating the SDK. It's necessary to test old-new version negotiation against real traffic, migrate implicit session state into handles, and verify per-call authorization. Tasks and the server-client round-trip flow should also be validated against the new state transitions, rather than by checking whether old-version method names still work. What's worth confirming in the final spec scheduled for publication on July 28 is what has changed since the release candidate, and the state of stable support across the Tier 1 SDKs. That's what will determine the timing for migrating MCP onto ordinary HTTP infrastructure.