What changed in the 2026-07 MCP specification.

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 also not shipped yet. The release candidate was locked on May 21, 2026, and the final specification is scheduled to publish on July 28, 2026. That roughly ten-week gap is a validation window for SDK maintainers and client implementers to test the changes against real workloads. The current finalized version is still 2025-11-25. Everything below describes the release candidate; treat specifics as subject to change until the July 28 final.

What breaks and what stays compatible

At a glance: what the release candidate 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 release-candidate blog frames 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.

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 release candidate 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. Note that the field names below come from the draft schema and are accurate as of the release candidate:

• 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 release candidate also hardens authorization. Per the release-candidate blog, six SEPs align the authorization specification 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 exact set of authorization SEPs is still settling in the release candidate, so treat specific numbers as provisional until the final specification ships.

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 release candidate 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.

None of this is urgent yet. The release candidate is a target, the deprecation policy buys at least twelve months for anything being phased out, and the current finalized version is 2025-11-25. The right move today is to read the draft changelog, follow the SDK validation work, and avoid building hard dependencies on anything the release candidate deprecates.