The headline change in MCP's 2026-07-28 release is that the protocol is now stateless at the protocol layer.
That sounds abstract. What it means in practice:
the Mcp-Session-Id header and the protocol-level session that came with it are removed. With both gone, any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer.
The final specification publishes today, July 28, 2026.
Before you open the changelog, there is one change most coverage is underplaying: the Tasks API you may have shipped against in November is not just redesigned - it is gone from the core spec entirely, replaced by a formally different extension with a different lifecycle. If you built on the 2025-11-25 experimental Tasks feature, you have a real migration, not a version bump.
What the stateless core actually changes on the wire
The stateless redesign is the right call, but it helps to see the before and after concretely.
In 2025-11-25, calling a tool over Streamable HTTP meant establishing a session first with an initialize request. The server responded with an Mcp-Session-Id that every subsequent request had to carry, pinning the client to whichever instance issued it. In 2026-07-28, the same call is a single self-contained request that any server instance can handle.
The MCP roadmap called the problem out directly: "Stateful sessions fight with load balancers, horizontal scaling requires workarounds." When you put a load balancer in front of stateful MCP servers, you had three bad options: sticky sessions, which fail open whenever an instance restarts or scales down; or shared session state in Redis, which adds a network hop and a single point of failure to every tool call.
Routable transport headers are a related addition: Mcp-Method rides on every request, and Mcp-Name on requests that name a tool, resource, or prompt, so gateways and rate limiters can route without parsing bodies.
If your gateway currently extracts the JSON-RPC method from the request body to make routing decisions, the new headers make that unnecessary - and the headers are now mandatory, not optional.
Removing the protocol-level session does not mean your application has to be stateless. Servers that need to carry state across calls can mint an explicit handle from a tool and have the model pass it back as an ordinary argument on later calls. In practice, this pattern is often more powerful than hidden session state: the model can compose handles across tools, reason about them, and hand them off between steps.
This is the non-obvious upside. Externalizing state into tool-passed handles is not a workaround - it makes the state visible to the model's reasoning loop, which opens composition patterns that session-scoped state never could.
The Tasks breaking change is not a minor one
Tasks shipped as an experimental core feature in 2025-11-25. Production use surfaced enough redesign needs that the right home for it is an extension rather than the specification.
The experimental tasks feature in the 2025-11-25 specification served as a stopgap until the protocol's extension mechanism was available. Now that extensions have been formalized, moving tasks to an official extension gives the feature time to incubate and evolve based on additional real-world implementation feedback, without being constrained by the core specification's release cadence.
The lifecycle itself changed shape:
| 2025-11-25 experimental | 2026-07-28 extension | |
|---|---|---|
| Long-running result | blocking tasks/result |
polling via tasks/get |
| Client input mid-task | not supported | tasks/update |
| Cancel task | - | tasks/cancel |
| List all tasks | tasks/list |
removed - can't be scoped safely without sessions |
| Task creation | client-initiated | server-directed; server decides when a call becomes a task |
The tasks/list endpoint is removed because it cannot be scoped safely without sessions. Anyone who shipped against the 2025-11-25 experimental Tasks API will need to migrate to the new lifecycle.
If you built on the experimental 2025-11-25 tasks API, plan a real port - the lifecycle changed, it was not just relocated. If you have not built on it yet, do not start now; build on the extension version once it is final.
Beagle in action#platform-eng, morning of July 28What is deprecated versus what is gone
Three first-class MCP primitives are deprecated in the 2026-07-28 RC: Roots, Sampling, and Logging. Nothing is removed yet - the deprecations are annotation-only. All three methods and their capability flags continue to work in this release and in every spec version published within twelve months of the final July 28 spec. You have at least until mid-2027 before they stop working.
Roots is replaced by tool parameters or config; Sampling is replaced by calling the LLM provider API directly; Logging is replaced by stderr or OpenTelemetry.
The practical read: do not rush to rip out Roots or Sampling today. Migrate at the SDK's pace. That said, read the auth SEPs this week regardless - SEP-2468 (iss validation per RFC 9207) is the one most likely to be exploited in the wild between now and when the spec finalizes.
The Extensions framework changes how MCP will evolve
Extensions existed in the 2025-11-25 release but had no formal process behind them. SEP-2133 adds that: 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. A new Extensions Track in the SEP process gives them a path from experimental to official.
This is the governance change that matters long-term. Before this RC, an experimental feature landing in the core spec had no defined path to graduation or removal. Now it does. Tasks went from "experimental in core" to "official extension with its own repo and version," and once the extension has stabilized and achieved broad adoption, it is intended to be promoted back into the core protocol.
MCP Apps (SEP-1865) 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.
That last detail is worth sitting with. MCP Apps does not open a second channel that bypasses tool-call logging or consent flows - every click in the rendered interface is a JSON-RPC call through the existing path. For teams using Beagle's draft-and-approve model, this means UI-triggered actions carry the same approval surface as text-triggered ones.
Mcp-Method and Mcp-Name headers route at the gateway, state lives in explicit tool-passed handles the model can reason aboutMigration checklist for July 28
Most servers need a focused checklist: 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.
Concrete steps, in priority order:
Tasks first - if you shipped against the 2025-11-25 experimental Tasks API, migrate the lifecycle:
tasks/result→tasks/get, addtasks/updateandtasks/cancel, remove anytasks/listcalls. This is a real port, not a rename.Session state - grep your server for
Mcp-Session-Id. Anywhere you read or store it, replace with explicit handles returned from tools. The model threads them forward.Headers - confirm
Mcp-MethodandMcp-Nameare present on all Streamable HTTP requests. The routing headers are required, not optional. Gateways that validate Streamable HTTP traffic will reject requests missingMcp-MethodorMcp-Name.Auth - authorization hardening includes iss validation per RFC 9207 (SEP-2468),
application_typein Dynamic Client Registration (SEP-837), scope accumulation on step-up (SEP-2350), and credential binding to the issuing authorization server (SEP-2352).Error codes - the "resource not found" error code moves from
-32002to the standard-32602. Grep your error handling.Caching - list and resource-read results now carry
ttlMsandcacheScopefields. Add them so clients know how long responses stay fresh without re-fetching.Deprecations - flag Roots, Sampling, and Logging for removal within the 12-month window. Do not break things now; just stop adding new dependencies on them.
Clients that speak 2026-07-28 fall back to the initialize handshake when they reach a server on 2025-11-25 or earlier, so old servers and new clients keep interoperating. You do not need to cut over all at once - validate the new spec on a staging branch first.
MCP 2026 spec: common questions
What is the biggest breaking change in the MCP 2026-07-28 spec?
Most MCP server failures in production stem from assumptions about session state that the protocol never guaranteed. The 2026-07-28 specification eliminates this entire class of problems by making the protocol stateless at the core. No handshake, no session identifiers, no connection lifecycle to manage. Any request can hit any server instance. For teams already running stateless HTTP servers, the migration is small. For teams with session-based remote servers, it is real work.
Do I have to migrate my Tasks implementation right now?
Yes, if you used the experimental Tasks API from 2025-11-25.
This proposal removes the version of tasks specified in the 2025-11-25 release.
The new extension lifecycle - tasks/get, tasks/update, tasks/cancel - is not backward-compatible. If you have not shipped against the experimental API yet, skip it and build directly on the extension.
Are Roots, Sampling, and Logging removed in MCP 2026-07-28?
No. No feature is removed in 2026-07-28. Three are deprecated with replacements documented. Per the new lifecycle policy, Active → Deprecated → Removed transitions take a minimum of 12 months. Methods, types, and capability flags keep functioning in this release and in every spec version published inside the 12-month window.
What is the MCP Extensions framework?
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.
This gives capabilities like Tasks a way to evolve without waiting for the core spec's release cadence, and a defined path from experimental to official.
When does the 2026-07-28 spec ship?
The release candidate is available today and the final specification ships on July 28, 2026. The release candidate was locked on May 21, giving SDK maintainers a ten-week validation window. All four Tier 1 SDKs - led by Python v2 and TypeScript v2, with Go and C# betas also available - can be tested now.