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).
This is a later, distinct revision from the spec covered in MCP OAuth 2.1 and PKCE, explained step by step, which walks the 2025-11-25 authorization flow. That post is not being rewritten here — this one covers what 2026-07-28 adds and changes on top of it.
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.
As of this writing (August 2026), 2026-07-28 is the current, ratified MCP specification. It is not experimental and not subject to further pre-release breaking changes — though the maintainers' new formal deprecation policy (below) means individual features can still be phased out on a defined timeline.
The core change: from stateful sessions to a stateless core
Every MCP deployment built against the 2025-11-25 spec establishes a session: a client calls initialize, the server responds with capabilities and an Mcp-Session-Id, and every subsequent request on that connection carries the session ID so the server can recall prior state. That model works, but it means an MCP server needs sticky routing or shared session storage to run behind more than one instance.
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. Authorization servers must return an
issparameter, and clients must validate it before redeeming an authorization code. This closes an authorization-server mix-up vulnerability where a client could be tricked into completing a flow against the wrong authorization server. - Client ID Metadata Documents (CIMD) formally replace Dynamic Client Registration (DCR). Under DCR, a client registers itself with an authorization server at connection time to obtain a
client_id. Under CIMD, the client instead publishes a metadata document that any authorization server can fetch, and client credentials are bound to the specific issuer that minted them — no reuse across authorization servers. DCR continues to work for backward compatibility but is formally deprecated and will be removed in a future spec version. Teams evaluating credential and access-token handling for MCP servers should read this alongside MCP server authentication: OAuth 2.1 vs API keys.
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 how you reason about MCP traffic operationally. With no session ID to correlate a run of calls, audit and forensic tooling has to correlate activity by client identity carried per-request in _meta rather than by a connection-scoped session token — a real change to how you'd reconstruct "what did this agent do" after the fact. Header-based routing means a gateway can enforce coarse policy (which methods, which tools) without deserializing every request body, which changes what belongs at the edge versus deeper in the stack. And CIMD changes the trust bootstrapping question for every new MCP client you connect: identity is now tied to the metadata-document issuer rather than an ad hoc per-server registration record. None of this replaces tool-level authorization or content inspection — see the MCP server security checklist — but it does change what your registry and gateway layer needs to track, a topic covered in registering and governing MCP servers and the MCP server governance guide. Praesidia is an AI agent security and governance control plane — agent identity and access, guardrails, audit evidence, and cost controls in one place — and teams running MCP fleets are the primary audience for exactly this kind of spec-version tracking.
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?
Nothing breaks immediately. The stateless core is the new default, and Mcp-Session-Id is retired at the protocol level, but the maintainers' formal deprecation policy gives implementers a minimum twelve-month window on related deprecated primitives (Roots, Sampling, Logging) and a year-long offramp for the legacy HTTP+SSE transport before removal.
What is CIMD, in plain terms? A Client ID Metadata Document is a metadata document a client publishes that any authorization server can fetch to learn who the client is, replacing the older pattern of registering the client directly with each authorization server via Dynamic Client Registration. Credentials issued this way are bound to the specific issuer that minted them.
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.