What changed in the 2026-07 MCP specification.

Update, 28 July 2026: the specification shipped as final on schedule. This post now describes the published text rather than the release candidate.

A version, not a publish date

The first thing to get right is the date itself. MCP uses string-based version identifiers in the format YYYY-MM-DD to indicate the last date backwards-incompatible changes were made. So 2026-07-28 is a version label, not the day a blog post went up.

It is shipped now. The release candidate was locked on May 21, 2026, the roughly ten-week gap was a validation window for SDK maintainers and client implementers to test the changes against real workloads, and the final specification published on July 28, 2026, as scheduled. 2026-07-28 replaces 2025-11-25 as the current version. Everything below describes the published specification. One addition landed between the release candidate and this description: every result now carries a required resultType field, "complete" for ordinary results and "input_required" for Multi Round-Trip interim results, with results from earlier-protocol servers treated as complete (SEP-2322).

What breaks and what stays compatible

At a glance: what the 2026-07-28 specification breaks, what it only deprecates (so it stays in the spec for a year or more), and what stays compatible with a new field or two. Each row is explained in detail in the sections below.

The stateless core

The headline change is that MCP becomes stateless at the protocol layer. The maintainers frame this as six Specification Enhancement Proposals (SEPs) working together to complete the plan laid out in late 2025.

Two SEPs carry most of the weight:

• Sessions removed (SEP-2567). Protocol-level sessions and the Mcp-Session-Id header are gone from the Streamable HTTP transport. The list endpoints (tools/list, resources/list, prompts/list) no longer vary per connection. Servers that need cross-call state now mint explicit, server-issued handles passed as ordinary tool arguments. The practical payoff: no more sticky routing or shared session stores for horizontal deployments.
• Handshake removed (SEP-2575). The initialize and notifications/initialized exchange is gone. Every request now carries its protocol version, client identity, and client capabilities in _meta (under keys such as io.modelcontextprotocol/protocolVersion, /clientInfo, and /clientCapabilities). Version mismatches return an UnsupportedProtocolVersionError. A new server/discover RPC, which servers MUST implement, advertises supported protocol versions, capabilities, and identity. Clients MAY call it for up-front version selection or as a STDIO backwards-compatibility probe.

Transport headers and routing

Stateless servers still have to live behind load balancers, gateways, and rate-limiters. SEP-2243 makes that work cleanly by requiring two standard headers on Streamable HTTP POST requests: Mcp-Method and Mcp-Name. With the operation named in the headers, infrastructure can route and rate-limit on the operation without inspecting the request body. A server can run behind a plain round-robin load balancer instead of deep packet inspection. The same SEP adds support for custom headers from tool parameters via x-mcp-header.

Response caching

SEP-2549 introduces a new CacheableResult interface and requires two fields on the results of tools/list, prompts/list, resources/list, resources/read, and resources/templates/list:

• ttlMs is a freshness hint in milliseconds. Clients can cache the response and reduce polling.
• cacheScope is either "public" or "private" and controls whether shared intermediaries may cache the response.

The model is borrowed from HTTP Cache-Control, and it complements the existing listChanged notifications rather than replacing them. For a stateless protocol where list endpoints are now connection-independent, caching is how clients avoid re-fetching the same tool catalogue on every call.

Extensions, MCP Apps, and Tasks

Extensions become a first-class capability. An extensions field is added to both ClientCapabilities and ServerCapabilities, and the two sides negotiate optional extensions beyond the core protocol through that map. Two notable features ship as extensions under this framework.

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. UI-initiated actions go through the same JSON-RPC audit and consent path as a direct tool call, which keeps the security model intact. MCP Apps has been Final since January 26, 2026, when it shipped as the first official extension; we cover what it standardizes, and where the HTML lives, separately. The published specification names Enterprise Managed Authorization (EMA) as a further extension in the same framework, alongside MCP Apps and Tasks.

Tasks (io.modelcontextprotocol/tasks, SEP-2663) handles long-running work. Tasks first shipped as an experimental core feature in 2025-11-25, but production use led to moving it out of the core protocol and into an official extension. The redesign:

• replaces the blocking tasks/result method with polling via tasks/get,
• adds tasks/update for client-to-server input,
• removes tasks/list, and
• lets servers return task handles unsolicited, without per-request opt-in.

Elicitation, sampling, and Multi Round-Trip

In the released 2025-11-25 spec, a server can pause mid-operation to ask for input. Elicitation (elicitation/create) requests structured input from the user; its result carries an action of accept, decline, or cancel, plus a content object on accept. Elicitation supports a form mode and a url mode, with hard safety rules: servers MUST NOT use form mode for sensitive credentials such as passwords or API keys, and MUST use URL mode for those instead.

Sampling (sampling/createMessage) lets a server request an LLM completion from the client, nesting LLM calls inside other server features to enable agentic behavior. Sampling is human-in-the-loop by design: the client controls model selection (the server never sees API keys), can review and edit the prompt, and can deny the request. Model selection uses an advisory preference system (modelPreferences with hints and costPriority, speedPriority, intelligencePriority).

The 2026-07-28 specification changes how these server-initiated requests are delivered. Rather than the server opening a request channel back to the client (and holding a connection open), SEP-2322 introduces the Multi Round-Trip Requests (MRTR) pattern. The field names below come from the published 2026-07-28 schema:

• A call to tools/call, prompts/get, or resources/read can return an InputRequiredResult (a new resultType of input_required) instead of completing.
• That result carries inputRequests, a map of server-initiated requests the client must fulfill (each one a full elicitation or sampling request), plus an opaque requestState the client must echo back unmodified.
• The client gathers the answers and re-issues the original call with inputResponses, keyed identically, and the echoed requestState.

Because all the state rides in the payload, any stateless server instance can resume the work. One InputRequiredResult can batch an elicitation and a sampling request together in a single round-trip. This is the same load-shedding motivation behind the stateless core: nothing depends on a held connection.

Authorization alignment

The 2026-07-28 specification also hardens authorization, aligning it more closely with how OAuth 2.0 and OpenID Connect are deployed in practice, motivated by MCP's single-client, many-server deployment shape. The changes that landed in the published changelog: authorization servers SHOULD include the iss parameter in authorization responses, and clients MUST validate a present iss against the recorded issuer before redeeming the authorization code (SEP-2468); clients MUST specify an appropriate application_type during registration to avoid OpenID Connect redirect URI conflicts (SEP-837); and client credentials are bound to the authorization server that issued them, so clients MUST key persisted credentials by issuer and re-register when the authorization server changes (SEP-2352). Separately, OAuth 2.0 Dynamic Client Registration is formally deprecated as a registration mechanism in favour of Client ID Metadata Documents; it continues to work for backwards compatibility but is slated for removal in a future version.

The deprecation policy

For the first time, MCP adopts a formal feature lifecycle and deprecation policy (SEP-2596). It defines three states (Active, Deprecated, Removed) and a registry of deprecated features. The key guarantee is a minimum deprecation window: a feature must remain Deprecated for at least twelve months, measured from the release of the revision that first marks it Deprecated, before it is eligible for removal.

There is one exception. An expedited removal (for example, a published security advisory or in-the-wild exploitation with no in-place mitigation) can shorten the window, but it must still provide at least ninety days between a feature becoming Deprecated and its earliest removal.

Under this policy, the 2026-07-28 specification deprecates the Roots, Sampling, and Logging features (SEP-2577) and reclassifies the older HTTP+SSE transport as Deprecated (SEP-2596). Deprecated does not mean gone: these features remain in the specification for at least the twelve-month window.

What this means for builders

If you maintain an MCP server, including a publish primitive like Stacktree's MCP publish tool, the stateless core is the change to plan for. A server that previously relied on the session header or the initialize handshake will need to read protocol version and capabilities from _meta, implement server/discover, and attach ttlMs and cacheScope to its list and read results. Clients now send the Mcp-Method and Mcp-Name headers on their Streamable HTTP POST requests, so make sure your gateway routes on those headers rather than on session affinity. If you used the experimental Tasks feature, you will move to the extension and switch from blocking tasks/result to polling.

The specification is final, but July 28 is a publish date, not a switch-off: publication does not turn anything off for implementers on 2025-11-25, and the deprecation policy buys at least twelve months for anything being phased out. All four Tier 1 SDKs (TypeScript, Python, Go, and C#) speak 2026-07-28 as of publication day, with migration notes for the breaking parts, the session-identifier removal chief among them. The right move now is to read the final changelog, upgrade in a branch, and avoid new dependencies on anything the specification deprecates.

Client adoption started the same day: Anthropic announced that support for 2026-07-28 is rolling out across Claude products, with MCP Apps and Tasks shipping under the versioned extensions framework and authorization aligning with enterprise identity systems such as Entra and Okta. Anthropic's connectors directory now counts over 950 connectors, so for server authors the upgrade path is concrete rather than theoretical.