A developer at Uber's platform team described running "tens of thousands of agent executions a week" through their internal MCP gateway - and their loudest complaint wasn't model quality or latency. It was the session handshake. Every connection required an initialize round-trip, returned an Mcp-Session-Id, and pinned the client to one server instance. Their load balancers had to inspect JSON-RPC bodies to route correctly. Autoscaling was painful. One server restart and every in-flight session was gone.
The MCP 2026-07-28 release candidate, locked May 21 and final on July 28, deletes the handshake entirely. The headline change is that MCP is now stateless at the protocol layer. That is the Uber team's argument winning in the spec. But going stateless is only one of five load-bearing changes in what lead maintainers David Soria Parra and Den Delimarsky are calling "the biggest MCP revision since launch."
Why Sessions Were the Wrong Default
The problem was architectural from the start.
Until now, every MCP connection started with a handshake: the client sent initialize, the server responded with its capabilities and handed back an Mcp-Session-Id, and every subsequent request carried that header so the server could find the conversation again. On paper that's tidy. On real infrastructure it's a tax.
If your server runs as serverless functions, there is no "the server" to remember the session. You either pin clients to instances with sticky routing, or you push session state into shared storage and pay the latency on every single request. Both options are solvable, but neither is what teams signed up for when they chose a protocol that was supposed to simplify integrations.
The 2026-07-28 release candidate removes the initialize/initialized handshake and the Mcp-Session-Id header that pinned a client to one server instance. Protocol version, client info, and capabilities now travel inline in a _meta field on each request. Any server instance can serve any request, so a remote MCP server can run behind a plain round-robin load balancer without sticky sessions or a shared session store.
One trade-off is worth naming honestly: this stateless model increases request payload sizes because client capabilities and session parameters must be transmitted with each call. If you were running sessions precisely to avoid that overhead, measure before you migrate.
Tasks and MCP Apps: What the Extensions Framework Actually Gives You
Going stateless required rethinking the two features that most depended on persistent connections: long-running work and server-initiated UIs.
Tasks had shipped as an experimental core feature in the November 2025 spec.
Production use surfaced enough redesign that the right home for it is an extension rather than the specification.
The new shape is cleaner:
the Tasks extension reshapes the lifecycle around the stateless model - a server can answer tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed: the client advertises the extension and the server decides when a call should run as a task.
The Tasks API addresses a long-standing gap in MCP: operations that take longer than a request timeout. Before 2026-07-28, teams implemented custom polling or webhook patterns. The Tasks extension standardizes this with a three-endpoint pattern: create task, query status, cancel task. Tasks return a task identifier immediately and clients poll for completion. This works naturally with the stateless core because task state lives in a backing store, not in server memory.
One thing that disappeared from the November API: tasks/list.
It's gone because without sessions there is no safe way to scope "whose tasks?"
If you built against the experimental 2025-11-25 Tasks surface, you will need to migrate.
MCP Apps is the other first-class extension. MCP Apps lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs. The rendered UI talks back to the host over the same JSON-RPC base protocol used everywhere else in MCP, so every UI-initiated action goes through the same audit and consent path as a direct tool call.
The extension system itself is new infrastructure.
Extensions are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the specification.
That last point matters: a capability like Tasks can now iterate without touching the core spec.
What Is Actually Deprecated - and What That Means
Three features that have been in MCP since early days now enter formal deprecation: Roots, Sampling, and Logging. Roots is replaced by tool parameters or config; Sampling by calling the LLM provider API directly; Logging by stderr or OpenTelemetry.
This is not removal. Under the new lifecycle policy, a feature must stay Deprecated for at least twelve months from its deprecating revision before it is eligible for removal, so these features remain in the spec for now. The deprecation policy is itself new: implementing a predictable release cadence, formal deprecation timelines, and conformance testing establishes MCP as a reliable infrastructure standard rather than an unstable library.
The Sampling deprecation deserves a separate note. Sampling let MCP servers request LLM completions from the client - essentially turning a server into an orchestrator. The November 2025 spec leaned into this,
allowing MCP servers to request LLM completions from the client, including tool calls within those completions. A server was no longer a passive tool provider - it could orchestrate multi-step reasoning flows. This turns MCP bidirectional in a meaningful way.
That capability is being replaced in the RC by Multi Round-Trip Requests (SEP-2322),
where a server returns an InputRequiredResult carrying inputRequests plus an opaque requestState; the client gathers answers and re-issues the original call with inputResponses. This fits the stateless model because all state lives in the payload, not a held connection.
Beagle in action#platform-eng, 10:22amThe Honest Take: What This Release Fixes and What It Doesn't
The sessions deletion, the formalized deprecation lifecycle, and the extensions governance track all point the same direction: away from protocol cleverness, toward boring, scalable HTTP - stateless requests, header-based routing, standard error codes, standard schema, standard tracing. Each of those choices makes an MCP server cheaper to run and easier to put behind infrastructure you already have.
The enterprise authorization story also tightens. The standard per-user OAuth flow forces every employee to authorize each MCP server individually, which complicates onboarding, lacks centralized audit logs, and mixes personal and corporate access. To address this, the enterprise-managed authorization extension implements the Identity Assertion JWT Authorization Grant.
What this release does not fix is server trust. The question of which MCP servers are safe to connect to an agent - supply-chain accountability, attestation, who published what - remains open. Organizations building MCP servers now should prepare for supply-chain accountability and attestation. The 2026 RC gives you better tracing and cleaner auth, but it does not tell you whether the server on the other end is trustworthy. That is still a human decision, and a teammate like Beagle can help surface the question in the right channel before a connection gets approved.
For teams operating MCP servers today, the migration checklist is concrete:
upgrade the SDK, drop Mcp-Session-Id assumptions and use explicit handles for state, emit the new Mcp-Method and Mcp-Name headers, migrate experimental Tasks to the new lifecycle, add ttlMs to list responses, and harden auth.
The spec finalizes July 28. The RC is available now. Under the SDK tier system, Tier 1 SDKs are expected to ship support within the ten-week validation window. If you run a production MCP server, this is the window to test - not a release note to bookmark for later.