The Model Context Protocol's 2026-07-28 specification is the final, ratified revision — not the release candidate that circulated in May — and it is the largest change to MCP since the protocol launched. The headline shift is architectural: MCP moves from a stateful, session-based protocol to a stateless request/response core. Alongside that, the spec ships Multi Round-Trip Requests (MRTR), header-based routing, cacheable list results, a hardened authorization model built on Client ID Metadata Documents (CIMD), and a formal extensions framework covering Tasks, MCP Apps, and Enterprise Managed Authorization (EMA).
For the authorization flow itself, read MCP OAuth 2.1 and PKCE, explained step by step, now updated for this revision. For a failing connection, use the MCP OAuth troubleshooting guide and local lab.
Ratified, not a release candidate
Two blog posts exist on the MCP project's own site for this date, and it is worth being precise about which one you are reading. On May 21, 2026, the maintainers published "The 2026-07-28 MCP Specification Release Candidate," describing the same stateless-core, MRTR, and authorization changes and stating explicitly that "the final specification ships on July 28, 2026." On July 28, 2026, the maintainers published the final post, opening with "today, we're officially pushing the release button on the next version of the MCP specification." The RC period ran roughly nine weeks and was used, in the maintainers' words, to test and validate the spec with ecosystem partners before general availability.
The released 2026-07-28 specification is the baseline discussed here. Pin the protocol and SDK versions you deploy; the formal deprecation policy below describes how features can be phased out over time.
The core change: from stateful sessions to a stateless core
The 2025-11-25 lifecycle begins with initialize, but its Streamable HTTP transport makes assignment of an Mcp-Session-Id optional. If the server assigns one, the client carries it on subsequent requests. Deployments that depend on that session state need a routing or storage strategy when running multiple instances. 2025-11-25 session management.
2026-07-28 retires the initialize/initialized exchange and the Mcp-Session-Id header entirely. Instead, every request is self-describing: it carries its protocol version, client identity, and client capabilities in a _meta field, and any request can land on any server instance behind a plain round-robin load balancer with no shared storage. Clients that want a server's capabilities up front can call a new, optional server/discover RPC — but nothing requires it.
Dropping protocol-level session state does not force applications themselves to be stateless. If a server needs to carry state across calls, it mints an explicit handle from a tool and has the model pass that handle back as an argument on the next call — state the model can see and reason about, rather than state hidden invisibly in the transport layer.
Multi Round-Trip Requests: confirmations without a held-open stream
The stateless core creates one obvious problem: what happens when a tool call needs something mid-execution, like a user confirmation or a missing parameter — something the 2025-11-25 spec handled via server-initiated elicitation/create or sampling/createMessage requests over a held-open bidirectional stream?
Multi Round-Trip Requests (MRTR) solve this without reintroducing a persistent connection. When a server needs input mid-call, it returns a response with resultType: "input_required" along with the specific requests it needs answered. The client collects the answers and retries the original call, this time with inputResponses attached. The exchange completes in ordinary request/response pairs — no stream stays open between the initial call and the follow-up. This is a protocol-level mechanism worth distinguishing from application-level human-in-the-loop design, which is covered generally in human-in-the-loop approvals for agents.
Header-based routing and cacheable list results
Two smaller but operationally significant changes ship alongside the stateless core:
- Header-based routing. Streamable HTTP requests must now include
Mcp-MethodandMcp-Nameheaders naming the RPC method and the target tool or resource. A gateway, rate limiter, or WAF can route and meter traffic on those headers directly, without parsing the JSON-RPC body. - Cacheable list results. Responses from
tools/list,prompts/list,resources/list, andresources/readnow carryttlMsandcacheScopefields, letting clients cache tool catalogs for a defined lifetime instead of re-fetching them on every reconnect — useful for keeping upstream prompt caches stable.
Both changes push MCP closer to behaving like an ordinary HTTP workload that existing infrastructure — load balancers, CDNs, API gateways — already knows how to operate.
Authorization hardening: CIMD formally replaces DCR
The authorization model built on OAuth 2.1, described in MCP OAuth 2.1 and PKCE, explained, continues to apply — this revision hardens it rather than replacing it. Two changes matter most:
- RFC 9207 issuer validation. An authorization server SHOULD include
iss. A client validates any present value against the issuer recorded from validated metadata, before sending the code to a token endpoint. If metadata advertisesauthorization_response_iss_parameter_supported: true, a missing value requires rejection. With no advertised support and no value, that check permits proceeding. Authorization response validation. - Client ID Metadata Documents (CIMD) and registration state. A CIMD client ID is a self-hosted HTTPS metadata URL and can be used across authorization servers that support it. Pre-registered and DCR-issued credentials remain tied to the issuer that issued them. Clients prefer an available pre-registration, then advertised CIMD support, then the deprecated DCR fallback. Client registration and issuer binding.
Extensions become first-class: Tasks, MCP Apps, and EMA
2026-07-28 formalizes an extensions framework and moves several previously experimental or ad hoc capabilities into it:
| Extension | What it covers | Status in 2026-07-28 |
|---|---|---|
| Tasks | Long-running, poll-based work via tasks/get and tasks/update, plus a subscriptions/listen stream for change notifications |
Moved out of the core into the io.modelcontextprotocol/tasks extension |
| MCP Apps | Server-rendered user interfaces inside MCP clients | Formalized as an official extension |
| Enterprise Managed Authorization (EMA) | Centralized enterprise control over which MCP apps and tools are authorized | Formalized as an official extension |
Formalizing these as extensions — rather than leaving them as core-protocol experiments — means implementers can adopt each independently, and the maintainers can version and deprecate them on their own schedules without destabilizing the request/response core every other MCP feature depends on.
What's deprecated, and the migration timeline
The spec also introduces a formal deprecation policy: any deprecated feature keeps working for a minimum of twelve months before removal, so teams can plan upgrades instead of reacting to a breaking release. Two deprecations land with this revision:
- Roots, Sampling, and Logging are deprecated as core-protocol primitives. They continue to function, but new implementations should not adopt them going forward.
- The legacy HTTP+SSE transport is deprecated with a year-long offramp in favor of Streamable HTTP.
Tier 1 SDKs — TypeScript, Python, Go, and C# — speak 2026-07-28 as of the release date; the Rust SDK supports it in beta. The maintainers' own 2026-07-28 release announcement puts Tier 1 SDK downloads at close to half a billion a month, with the TypeScript and Python SDKs each having crossed one billion cumulative downloads — a migration surface that is not small, and part of why the deprecation window matters.
What this means for MCP governance
The stateless core changes operational correlation. Record authenticated caller identity and application-level run or request references; client-supplied _meta is not proof of an authenticated identity. Routing headers can help an edge classify traffic, while the server must still authorize the action actually requested. CIMD also changes client onboarding without making a metadata URL, by itself, proof that a client may execute a particular tool. For the deployment review beyond authentication, use the MCP server security checklist and MCP server governance guide. Praesidia combines agent identity and access, guardrails, audit evidence, and cost controls for teams managing these boundaries.
If your organization is also evaluating Anthropic's separate Agent Skills standard, note that Skills and MCP solve different problems with different trust models — see the Agent Skills security vetting checklist for that surface specifically.
Common questions
Is MCP 2026-07-28 the final spec, or is it still a release candidate? It is final. The release candidate shipped May 21, 2026; the ratified specification followed on schedule July 28, 2026, and the maintainers' own announcement describes it as generally available, not a preview.
Does 2026-07-28 replace the OAuth 2.1 authorization flow from the November 2025 spec? No. OAuth 2.1 remains the authorization foundation. This revision hardens it — adding RFC 9207 issuer validation and shifting client registration from Dynamic Client Registration to Client ID Metadata Documents — rather than replacing the flow described in the November 2025 spec.
What happens to MCP servers still using session IDs? Keep clients and servers on a mutually supported protocol revision during migration. The new stateless lifecycle does not make a client using the older initialization exchange automatically compatible with every new server. Deprecation windows for other features are not a substitute for testing that version boundary.
What is CIMD, in plain terms? A Client ID Metadata Document is a self-hosted HTTPS document describing the client, with its URL used as the client ID. That identifier is portable across supporting authorization servers. Pre-registered and DCR-issued credentials, by contrast, remain bound to their issuing authorization server.
Do I need to rewrite my MCP integration today? Not urgently. DCR, Roots, Sampling, Logging, and the legacy transport all continue to function during their deprecation windows. Tier 1 SDKs already support 2026-07-28, so new integrations should target it directly, while existing deployments have a defined runway to migrate rather than a hard cutover date.