MCP 2.0 removes the session layer in the protocol's biggest revision yet

The 2026-07-28 specification of the Model Context Protocol (MCP) is the largest revision of the standard since its November 2024 launch, and it removes the protocol's session layer entirely. According to a migration guide published on dev.to, the initialize handshake and the Mcp-Session-Id header are gone, every request now carries its own protocol version and client capabilities, and any server instance can answer any call — meaning an MCP server can now be scaled like any other web service.

A stateless protocol

MCP, introduced by Anthropic in November 2024 and now hosted by the Agentic AI Foundation under the Linux Foundation, lets AI applications connect to tools and data through one protocol. The stateless redesign (tracked as SEP-2567 and SEP-2575) exists because the old model assumed long-lived connections: a client opened with an initialize handshake, received a session ID, and pinned every call to that session — over HTTP, typically to one specific server process. That suits stdio pipes on a laptop, but not a fleet of servers behind a cloud load balancer.

In the new design, each request carries its context in _meta under namespaced keys such as io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities, and a new server/discover method lets a client fetch a server's capabilities on demand. Microsoft's App Service guidance, cited in the dev.to article, makes the same point from the operations side: the stateless setup that teams once had to build themselves is now built into the protocol itself.

The trade-off is where security lives. With no session, there is no shortcut of authenticating once and trusting the connection — authorization must run on every request. OAuth issuer (iss) validation is now mandatory on servers, which the guide says closes a class of authorization mix-up attacks in which a client is tricked into tying an authorization response to the wrong identity server.

What breaks on upgrade

The guide lists changes that surface as errors after a careless upgrade:

• Sessions, ping and logging/setLevel are removed, and SSE resumability is gone. In the C# SDK, HttpServerTransportOptions.Stateless now defaults to true, and legacy SSE endpoints and stateful-only options trigger compiler warnings MCP9004 and MCP9006.
• HTTP requests must send Mcp-Method and Mcp-Name routing headers, so gateways can route without opening the request body.
• Results carry a required resultType field.
• Error codes moved: resource-not-found is now JSON-RPC's standard -32602 instead of MCP's -32002, and protocol-specific codes were renumbered into the -32020 to -32099 range.
• The Python SDK renamed McpError to MCPError, so except clauses need updating.
• Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents, and clients must validate the authorization server's iss.

The specification also gained a formal deprecation policy: at least twelve months' notice before anything is removed, with a 90-day floor reserved for active security issues. Nothing deprecated in the 2026-07-28 cohort can be removed before July 2027. Python teams not migrating yet can pin mcp>=1.28,<2, a branch that stays on security fixes only.

Callbacks become round trips

The biggest conceptual rewrite concerns sampling, elicitation and roots. A stateless server cannot hold a request open and wait, so the old pattern of a server calling back to the client mid-request had to go. Its replacement, Multi Round-Trip Requests (SEP-2322), has the server return a result whose resultType describes the outstanding need; the client then makes a follow-up call, with each round trip a complete, independent request. An elicitation flow that was previously one request with an embedded callback becomes two requests.

MCP Apps and Tasks graduate

Two experiments became official extensions with namespaced identities and independent release cycles. MCP Apps lets a server send interactive HTML that the host renders inside a sandboxed iframe, so a server can present real interfaces — a form or a dashboard, for instance — instead of returning everything as plain text. Tasks covers long-running jobs with a proper lifecycle instead of a held-open connection. The guide adds a caution: because the UI originates from the server, MCP Apps creates a new phishing surface of fake approval buttons and lookalike interfaces.

Why it matters

Every tool built on MCP now has migration work, and the ecosystem is fragmented — an October count cited in the guide found servers and clients still speaking five different spec revisions at once. The revision changes the deployment model, since stateless servers scale behind ordinary load balancers, but it also changes the security model, pushing authentication and authorization onto every request. Teams that delay face a defined clock: the 1.x branch receives security fixes only, and deprecated features cannot outlive July 2027. For anyone building or operating MCP tooling, the migration is now required work rather than optional housekeeping.