MCP 2026-07-28: What Changed in the Stateless Spec Rewrite

What Is the MCP 2026-07-28 Specification?

The 2026-07-28 Model Context Protocol specification, published on July 28, 2026, converts MCP from a bidirectional stateful protocol into a stateless request/response protocol. It retires the initialize handshake and the Mcp-Session-Id header, replaces server-initiated requests with a retry-based pattern, requires routing headers on HTTP transport, and places every feature under a formal deprecation policy. It is now the current protocol revision, superseding 2025-11-25. Model Context Protocol Blog, MCP Versioning Guide

The maintainers describe it as the largest revision of the protocol since launch. It was locked as a release candidate on May 21, 2026, which opened a ten-week window for SDK maintainers and client implementers to validate the changes against real workloads before publication. Model Context Protocol Blog

Statelessness was among the most highly requested features from developers who wanted better reliability and scalability for their MCP servers, and the scale of the ecosystem is what makes a change this structural notable. Across its Tier 1 SDKs, MCP now sees close to half a billion downloads a month, and both the TypeScript and Python SDKs have crossed one billion total downloads. Model Context Protocol Blog

Why Did MCP Drop Sessions and the Initialize Handshake?

MCP removed protocol-level sessions so that any request can land on any server instance, eliminating the need for sticky routing or a shared session store. Under 2025-11-25, a client opened a connection with an initialize call, received an Mcp-Session-Id, and had to return to the same logical session for the life of the conversation. That model forced every remote MCP deployment into either sticky load balancing or a shared state backend. MCP Specification Changelog

In 2026-07-28, the initialize and notifications/initialized exchange is gone entirely. Every request now carries its own protocol version and client capabilities inside _meta, using the keys io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities. Clients should identify themselves per request via io.modelcontextprotocol/clientInfo, and servers should identify themselves in each result. MCP Specification Changelog

What the stateless core removes and replaces:

• The handshake: initialize and notifications/initialized are replaced by a new server/discover RPC, which servers must implement to advertise supported protocol versions, capabilities, and identity. Clients may call it before any other request, or skip it entirely.
• The session header: Mcp-Session-Id is gone, and list endpoints no longer vary per connection. Servers that genuinely need cross-call state now mint explicit handles and pass them as ordinary tool arguments.
• Three utility methods: ping, logging/setLevel, and notifications/roots/list_changed are removed. Log level moves to a per-request io.modelcontextprotocol/logLevel field in _meta.
• Version negotiation: mismatches now return an explicit UnsupportedProtocolVersionError rather than failing at handshake time.

The operational payoff is concrete. A remote MCP server that previously required sticky sessions and a shared session store can now sit behind a plain round-robin load balancer with no shared storage at all, and a request that fails can simply be retried against a different instance. Model Context Protocol Blog

How Do Servers Ask for Input Now That Server-Initiated Requests Are Gone?

Servers now return an interim result asking for what they need, and the client retries the original request with the answers attached, a pattern the specification calls Multi Round-Trip Requests (MRTR). This replaces elicitation/create, sampling/createMessage, and roots/list, all of which previously required the server to call back to the client over a held-open stream. MCP Specification Changelog

How an MRTR exchange works:

• Every result declares its type: a required resultType field reads "complete" for ordinary results and "input_required" when the server cannot finish without more information.
• The server states what it needs: the interim result carries an inputRequests map describing what it wants from the client. Every InputRequiredResult must include either this field or requestState.
• The client answers on a retry: it re-sends the original request with an inputResponses field attached, instead of replying over a held-open stream.
• Correlation is explicit: servers that need to track work across retries encode their own identifier in requestState, since there is no session left to hold it.

Because the retry can be handled by any instance, a mid-flight elicitation no longer pins a conversation to one process. Clients reading results from an earlier-protocol server that omits resultType must treat those results as "complete". MCP Specification Changelog

Server-to-client notifications did not disappear, but they were consolidated. The HTTP GET endpoint and the resources/subscribe and resources/unsubscribe methods are replaced by a single subscriptions/listen stream that clients opt into by notification type, covering toolsListChanged, promptsListChanged, resourcesListChanged, and resourceSubscriptions. Request-scoped notifications such as progress and log messages continue to flow on the response stream of the request they belong to. MCP Specification Changelog

One capability was removed outright rather than replaced. SSE stream resumability and message redelivery are gone, including the Last-Event-ID header and SSE event IDs, so a broken response stream loses the in-flight request and the client must re-issue it with a new request ID. Anything long-running that previously leaned on stream resumption should move to the Tasks extension instead. MCP Specification Changelog

What Changed for Gateways, Caching, and Observability?

MCP requests over Streamable HTTP must now include Mcp-Method and Mcp-Name headers, which lets gateways route, rate-limit, and meter traffic without parsing JSON bodies. Until this revision, an intermediary that wanted to treat a tools/call differently from a tools/list had to inspect the request body, which is expensive at the edge and awkward for off-the-shelf infrastructure. The same change adds support for custom headers derived from tool parameters via x-mcp-header. MCP Specification Changelog

Caching arrives alongside it. A new CacheableResult interface requires ttlMs and cacheScope fields on results from tools/list, prompts/list, resources/list, resources/read, and resources/templates/list. The ttlMs value is a freshness hint in milliseconds, while cacheScope is either "public" or "private" and controls whether shared intermediaries may cache the response at all. MCP Specification Changelog

The table below shows what changed for the infrastructure sitting in front of an MCP server:

Capability	Under 2025-11-25	Under 2026-07-28	Enabled by
Load balancing	Sticky sessions or shared session store	Plain round-robin, no shared storage	Stateless core
Gateway routing	Required JSON body inspection	Header-based on Mcp-Method and Mcp-Name	Required request headers
Listing responses	Re-fetched or polled per connection	Cacheable with an explicit freshness hint	ttlMs and cacheScope
Distributed tracing	No documented convention	OpenTelemetry context in _meta	traceparent, tracestate, baggage
Interrupted streams	Resumable via Last-Event-ID	Re-issue as a new request	Resumability removed

Two smaller changes round out the operational story. Servers should now return tools from tools/list in a deterministic order, which improves both client-side caching and LLM prompt cache hit rates, and the error code for a missing resource moves from the MCP-custom -32002 to the standard JSON-RPC -32602. The revision also partitions the JSON-RPC server-error range, reserving -32020 through -32099 for the specification and grandfathering existing SDK usage below it. MCP Specification Changelog

Which MCP Features Are Deprecated, and When Do They Actually Disappear?

Four features are deprecated as of 2026-07-28, and the earliest any of them can be removed is the first specification revision released on or after July 28, 2027. This is the first release governed by a formal feature lifecycle policy, which defines three states (Active, Deprecated, Removed) and sets a minimum twelve-month window between deprecation and eligibility for removal. MCP Feature Lifecycle Policy

Deprecation is not a soft signal here. It requires an accepted SEP that names the feature, states the rationale, documents a migration path, and specifies the deprecation window in months. The window is measured from the release of the revision in which the feature is first marked Deprecated, not from the date the SEP reaches Final. MCP Feature Lifecycle Policy

The table below lists every feature currently in the Deprecated state and its documented migration path:

Feature	Deprecated in	Migration path	Earliest removal
Roots	2026-07-28	Tool parameters, resource URIs, or server configuration	On or after 2027-07-28
Sampling	2026-07-28	Integrate directly with LLM provider APIs	On or after 2027-07-28
Logging	2026-07-28	stderr for stdio; OpenTelemetry for observability	On or after 2027-07-28
Dynamic Client Registration	2026-07-28	Client ID Metadata Documents	On or after 2027-07-28
HTTP+SSE transport	2025-03-26	Streamable HTTP	Three months after SEP-2596 reaches Final

The twelve-month floor can be shortened, but only under narrow conditions: an active security risk with a published advisory or documented in-the-wild exploitation and no in-place mitigation, plus Core Maintainer approval. Even then, the shortened window must leave at least ninety days between deprecation and earliest removal. MCP Feature Lifecycle Policy

Implementers get a warning system rather than a surprise. Once a revision marking a feature Deprecated ships, Tier 1 SDKs must flag the corresponding API using the language's native mechanism in their next release, and should emit a runtime warning when the feature is exercised. Eligibility for removal is also not the same as removal, since the actual decision falls to Core Maintainers during release preparation and features may stay deprecated for much longer than the minimum. MCP Deprecated Features Registry

What Changed in MCP Authorization?

The biggest authorization change is that OAuth 2.0 Dynamic Client Registration is now deprecated in favour of Client ID Metadata Documents, which let a client use a hosted HTTPS URL as its client_id. Under the CIMD approach, a client publishes a JSON document at a URL it controls, and the authorization server fetches that document on demand instead of minting per-server credentials. MCP Client Registration Specification

The requirements are specific. The client_id URL must use the HTTPS scheme and contain a path component, the document must include at least client_id, client_name, and redirect_uris, and the client_id value inside the document must match the document URL exactly. Authorization servers advertise support with a client_id_metadata_document_supported flag in their OAuth metadata, and must validate both the match and the redirect URIs before issuing anything. IETF OAuth Client ID Metadata Document Draft

The practical gain is portability. A client ID based on a metadata document is a self-hosted URL resolved by whichever authorization server encounters it, so no re-registration is needed when the authorization server changes. Credentials obtained the old way do not have that property. MCP Client Registration Specification

Three additional hardening changes landed alongside it:

• Issuer validation: authorization servers should include the iss parameter in authorization responses per RFC 9207, and MCP clients must validate a present iss against the recorded issuer before redeeming the authorization code.
• Application type declaration: clients must specify an appropriate application_type during Dynamic Client Registration, because omitting it defaults to "web" under OpenID Connect and conflicts with native-style redirect URIs.
• Credential binding: clients must key persisted credentials by the authorization server's issuer identifier, must not reuse them with a different authorization server, and must re-register when the authorization server changes.

The specification also sets an explicit priority order for clients that support multiple mechanisms: use pre-registered credentials if available, then Client ID Metadata Documents if the authorization server advertises support, then Dynamic Client Registration as a fallback, and only then prompt the user to enter client information manually. MCP Client Registration Specification, IETF RFC 9207

Why Do Tasks and MCP Apps Now Live in Extensions?

MCP now has a formal extensions framework, and optional capabilities live in independently versioned repositories under reverse-DNS identifiers rather than accumulating inside the core specification. Extensions are identified in the form {vendor-prefix}/{extension-name}, with official extensions using the io.modelcontextprotocol prefix and third parties expected to use a reversed domain they own. They are always disabled by default and require explicit developer opt-in. MCP Extensions Documentation

Negotiation happens per request rather than at handshake time, which is what makes extensions compatible with the stateless core. Clients advertise support inside _meta["io.modelcontextprotocol/clientCapabilities"], servers advertise it in the server/discover response, and each side is expected to degrade gracefully or reject the request explicitly when support is one-sided. MCP Extensions Documentation

Tasks is the clearest example of the framework in action. It moved out of the experimental core into the io.modelcontextprotocol/tasks extension and was redesigned around statelessness.

What changed in the Tasks redesign:

• Polling replaces blocking: the blocking tasks/result method gives way to tasks/get, which the client drives on its own schedule.
• A new tasks/update method: carries client-to-server input mid-task, so a long-running job can still take direction.
• tasks/list is gone: it was removed because it cannot be scoped safely once sessions no longer exist.
• Handles can arrive unsolicited: servers may return task handles without the client opting in per request.

Anyone who shipped against the 2025-11-25 experimental Tasks API will need to migrate to the new lifecycle. MCP Specification Changelog, Model Context Protocol Blog

MCP Apps is the other headline extension, and it changes what a tool result can be. A tool declares a UI reference in its description via _meta.ui.resourceUri pointing at a ui:// resource, the host preloads and fetches that resource, and the returned HTML renders inside a sandboxed iframe that cannot reach the parent DOM, cookies, or local storage. Communication between the app and the host runs over postMessage using a JSON-RPC dialect with ui/ prefixed methods. MCP Apps Documentation

Getting an extension to official status is deliberately harder than adding a core feature used to be. It requires a SEP on the Extensions Track plus at least one reference implementation in an official SDK before the SEP can even be reviewed, with Core Maintainers holding final authority over inclusion. MCP Extensions Documentation

Does Anything Break on July 28, and What Changes If You Already Run an MCP Server?

Nothing breaks on July 28. In the maintainers' own words, "for existing clients and servers nothing breaks today, and nothing breaks on July 28 either." The date marks normative publication of the specification, not a switch-off for earlier revisions, and implementations running 2025-11-25 continue operating unchanged. A client speaking 2026-07-28 also falls back automatically to the initialize handshake against an older server, so upgrading a client does not strand the servers it talks to. Model Context Protocol Blog

Four Tier 1 SDKs support 2026-07-28 at release: TypeScript, Python, Go, and C#, with the Rust SDK in beta. Tier 1 is a maintenance commitment rather than a label. Model Context Protocol Blog, MCP SDK Tiering System

What Tier 1 status obliges an SDK to do:

• 100% conformance: a full pass rate against the automated conformance suite, versus 80% for Tier 2.
• Two business days: the maximum window to triage an incoming issue, meaning label it and judge whether it is valid.
• Seven days: the maximum window to resolve a critical P0 bug, covering core functionality failures and high-severity security issues.
• Ahead of the spec: support for new protocol features before a new specification version ships, on a timeline agreed per release.

The migration runway is explicit too. TypeScript v1.x receives bug fixes and security updates for at least six months after v2 reaches stable, and Python v1.x continues receiving critical bug fixes and security patches. Model Context Protocol Blog

The SDK leads' advice for testing against the new versions:

• Use real traffic: run the new SDK version in a branch of your server against production-shaped load, not just the happy path.
• Pin exact versions: public APIs may still shift between prerelease and stable releases.
• Add an upper bound: any library depending on the MCP package should cap its range so a stable v2 does not surprise downstream users.

The strategic read is that a stateless MCP lowers the cost of being callable by an agent that has never contacted you before, which is exactly the interaction pattern agentic commerce depends on. A protocol requiring a handshake, a session, and a held-open stream implicitly assumed a durable relationship between one client and one server process.

Agent traffic does not look like that. It is bursty, one-shot, and fanned across many providers at once, and published cache directives compound the benefit by letting an agent platform hold a capability listing instead of re-fetching it every conversation. Model Context Protocol Blog

None of this changes the discovery problem. MCP defines how an agent talks to your server once it knows the server exists, not how it learns you are worth calling, which remains a function of entity clarity, structured content, and the corroborating sources an AI system reads. For how MCP sits alongside the browser-side and payment-side protocols, see our explainer on WebMCP and agentic commerce and the live state of agentic commerce tracker.

The governance shift may end up mattering more than any single feature. A protocol with a published lifecycle policy, a twelve-month deprecation floor, a deprecated-features registry, and conformance-scored SDK tiers is a protocol you can plan a two-year integration roadmap against. That is a different proposition from the moving target MCP was eighteen months ago. MCP Feature Lifecycle Policy