Skip to content

Back to the catalog

The 2026-07-28 MCP Specification Release Candidate
blog.modelcontextprotocol.ioarticle

The 2026-07-28 MCP Specification Release Candidate

The MCP (Model Context Protocol) team announces the 2026-07-28 spec release candidate, the largest revision since launch, which removes the protocol-level session/handshake in favor of a stateless request model and restructures server-to-client interactions. The security-relevant core is a set of authorization SEPs that harden OAuth 2.0/OIDC usage: clients must validate the `iss` parameter per RFC 9207 to mitigate authorization-response mix-up attacks, declare `application_type` during Dynamic Client Registration to avoid redirect-URI misclassification, bind credentials to the issuing authorization server, and clarify scope accumulation during step-up auth. A related change requires that server-initiated requests (e.g. elicitation prompts) only be issued while actively processing a client-originated call, closing a class of out-of-nowhere prompt/consent issue for agentic clients.

TL;DR MCP's 2026-07-28 spec RC goes stateless and hardens OAuth/OIDC authorization (mix-up attack mitigation via RFC 9207, DCR fixes) plus restricts server-initiated elicitation prompts to active request contexts.
Open original ↗
Document

What it is

The release candidate for MCP specification version 2026-07-28, the largest revision since launch. It is available now; the final spec ships July 28, 2026, and it contains breaking changes. Six SEPs make the protocol stateless at the transport layer, and the release also adds extensions (MCP Apps for server-rendered UIs, a Tasks extension for long-running work) and a formal deprecation policy.

How it works

The initialize/initialized handshake is removed (SEP-2575); protocol version, client info, and capabilities now travel in _meta on every request, with a new server/discover method for fetching server capabilities up front. The Mcp-Session-Id header and protocol-level session are removed (SEP-2567), so any request can land on any instance. Server-initiated requests (e.g. elicitation) may now only fire while the server is processing a client request (SEP-2260, previously a recommendation, now required). SSE-held prompts are replaced by Multi Round-Trip Requests (SEP-2322): the server returns an input_required result carrying an opaque requestState, the client gathers answers and re-issues the original call with inputResponses plus the echoed requestState, so any instance can resume it.

Preconditions / Affected

Anyone running or building a remote MCP server on Streamable HTTP. Deployments that relied on sticky sessions, a shared session store, or gateway deep-packet-inspection are the ones that change most. The new transport requires Mcp-Method and Mcp-Name headers (SEP-2243), and servers reject requests where headers and body disagree.

What to do

  • Plan a migration: this is a breaking change — consult the post's Release Timeline and Validation section before adopting.
  • For state that spanned calls, drop session reliance and adopt the explicit-handle pattern: mint an identifier (basket_id, browser_id) from a tool and have the model pass it back as an ordinary argument. State becomes visible to the model rather than hidden in transport metadata.
  • Route on the Mcp-Method header at load balancers/gateways instead of inspecting bodies; you can now run behind a plain round-robin balancer.
  • Honor ttlMs and cacheScope on list/resource-read results (SEP-2549, modeled on HTTP Cache-Control): clients cache tools/list for as long as ttlMs permits and use cacheScope to decide cross-user sharing — no long-lived SSE stream needed to detect list changes.
  • Standardize distributed tracing on the now-documented W3C Trace Context keys in _meta (SEP-414): traceparent, tracestate, baggage.

Caveats

This is a release candidate, not final. The stateless protocol does not force stateless applications — servers can still manage state, just explicitly rather than via transport metadata. The page text is truncated mid-sentence on SDK support for Trace Context.

Organisations named here

  • mix-up attack
  • RFC 9207

Technologies named here

  • Model Context Protocol specification
  • MCP Apps
  • Tasks extension
  • OpenTelemetry-compatible backend
  • Model Context Protocol
  • OAuth
  • OIDC

Techniques named here

  • OAuth/OIDC mix-up attack
  • Sandboxed iframe rendering

Related in Identity & Access