The release candidate for MCP 2026-07-28 is now available. It is the largest\nrevision of the protocol since launch and delivers on the\n2026 roadmap:
- a stateless core that scales on ordinary HTTP infrastructure
- extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension
- authorization that aligns more closely with OAuth and OpenID Connect deployments
- a formal deprecation policy so the protocol can evolve without breaking what you’ve\nbuilt,
and many other changes.
The practical effect on a production deployment is immediate. A remote MCP\nserver that previously needed sticky sessions, a shared session store, and\ndeep packet inspection at the gateway can now run behind a plain round-robin\nload balancer, route traffic on an Mcp-Method header, and let clients cache\ntools/list responses for as long as the server’s ttlMs permits.
The release candidate is available today and the final specification ships on\nJuly 28, 2026. This release contains breaking changes; see\nRelease Timeline and Validation for the\ndetails.
A Stateless Protocol
The headline change is that MCP is now stateless at the protocol layer. Six\nSpecification Enhancement Proposals\n(SEPs) work together to get there, completing the plan we laid out in\nThe Future of MCP Transports in\nDecember.
Before and after
In 2025-11-25, calling a tool over\nStreamable HTTP means establishing a session first:
POST /mcp HTTP/1.1\nContent-Type: application/json\n\n{"jsonrpc":"2.0","id":1,"method":"initialize",\n "params":{"protocolVersion":"2025-11-25","capabilities":{},\n "clientInfo":{"name":"my-app","version":"1.0"}}}\nThe server responds with an Mcp-Session-Id that every subsequent request must\ncarry, pinning the client to whichever instance issued it:
POST /mcp HTTP/1.1\nMcp-Session-Id: 1868a90c-3a3f-4f5b\nContent-Type: application/json\n\n{"jsonrpc":"2.0","id":2,"method":"tools/call",\n "params":{"name":"search","arguments":{"q":"otters"}}}\nIn 2026-07-28, the same call is a single self-contained request that any\nserver instance can handle:
POST /mcp HTTP/1.1\nMCP-Protocol-Version: 2026-07-28\nMcp-Method: tools/call\nMcp-Name: search\nContent-Type: application/json\n\n{"jsonrpc":"2.0","id":1,"method":"tools/call",\n "params":{"name":"search","arguments":{"q":"otters"},\n "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}\nThe handshake and session are gone
The initialize/initialized handshake is removed\n(SEP-2575).\nThe protocol version, client info, and client capabilities that used to be\nexchanged once at connection time now travel in _meta on every request, and a\nnew server/discover method lets clients fetch server capabilities when they\nneed them up front.
The Mcp-Session-Id header and the protocol-level session that came with it are\nalso removed\n(SEP-2567).\nWith both gone, any MCP request can land on any server instance, and the sticky\nrouting and shared session stores that horizontal deployments needed before are\nno longer required at the protocol layer.
Stateless protocol, stateful applications
Removing the protocol-level session does not mean your application has to be\nstateless. Servers that need to carry state across calls can do what HTTP APIs\nhave always done: mint an explicit handle (a basket_id, a browser_id) from\na tool and have the model pass it back as an ordinary argument on later calls.
In practice, we’ve found this pattern (the model threading an identifier from\none tool call to the next) to be more than just a workable substitute for\nsession state. It’s often a more powerful one. The model can compose handles\nacross tools, reason about them, and hand them off between steps in ways that\nexternally managed session state, hidden in transport metadata, never really\nallowed.
The protocol no longer manages that state for you, but it doesn’t prevent you\nfrom managing it yourself. The explicit-handle pattern simply makes the state\nvisible to the model rather than hidden away.
Server-to-client requests, restructured
A stateless protocol still needs a way for servers to ask the client for\nsomething mid-call, such as an elicitation prompt. Two SEPs rebuild that flow so\nit works without a persistent connection.
Server-initiated requests may now only be issued while the server is actively\nprocessing a client request\n(SEP-2260).\nEarlier spec versions recommended this; it’s now required. A user is never\nprompted out of nowhere, and every elicitation traces back to something they (or\ntheir agent) started.
Multi Round-Trip Requests\n(SEP-2322)\nchange how those prompts are delivered. Instead of holding a Server-Sent Events\n(SSE) stream open, the server returns an InputRequiredResult:
{\n "resultType": "input_required",\n "inputRequests": {\n "confirm": {\n "type": "elicitation",\n "message": "Delete 3 files?",\n "schema": { "type": "boolean" }\n }\n },\n "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="\n}\nThe client gathers the answers and re-issues the original call with\ninputResponses and the echoed requestState. Any server instance can pick\nthat retry up because everything it needs is in the payload.
Routable, cacheable, traceable
Three smaller changes make the resulting traffic easier to operate.
The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers\n(SEP-2243)\nso load balancers, gateways, and rate-limiters can route on the operation\nwithout inspecting the body. Servers reject requests where the headers and body\ndisagree.
List and resource read results now carry ttlMs and cacheScope\n(SEP-2549),\nmodeled on HTTP Cache-Control. Clients know exactly how long a tools/list\nresponse is fresh and whether it’s safe to share across users, and a long-lived\nSSE stream is no longer the only way to learn that a list changed.
W3C Trace Context propagation in _meta is now documented\n(SEP-414),\nlocking down the traceparent, tracestate, and baggage key names so\ndistributed traces correlate across SDKs and gateways. Several SDKs and tools\nwere already doing this; with the key names fixed in the spec, a trace that\nstarts in a host application can follow a tool call through the client SDK, the\nMCP server, and whatever the server calls downstream, and show up as a single\nspan tree in an OpenTelemetry-compatible backend.
Extensions Become First-Class
Extensions existed in the 2025-11-25 release but had no formal process behind\nthem.\nSEP-2133\nadds that: extensions are identified by reverse-DNS IDs, negotiated through an extensions\nmap on client and server capabilities, live in their own ext-* repositories\nwith delegated maintainers, and version independently of the specification. A new\nExtensions Track in the SEP process gives them a path from experimental to\nofficial.
This release includes two official extensions.
MCP Apps: server-rendered user interfaces
MCP Apps\n(SEP-1865)\nlets servers ship interactive HTML interfaces that hosts render in a sandboxed\niframe. Tools declare their UI templates ahead of time so hosts can prefetch,\ncache, and security-review them before anything runs. The rendered UI talks back\nto the host over the same JSON-RPC base protocol used everywhere else in MCP, so\nevery UI-initiated action goes through the same audit and consent path as a\ndirect tool call.
Tasks graduates to an extension
Tasks shipped as an experimental core feature in\n2025-11-25.\nProduction use surfaced enough redesign that the right home for it is an\nextension rather than the specification.
The Tasks extension\nreshapes the lifecycle around the stateless model: a server can answer\ntools/call with a task handle, and the client drives it with tasks/get,\ntasks/update, and tasks/cancel. Task creation is server-directed: the client\nadvertises the extension and the server decides when a call should run as a\ntask. tasks/list is removed because it can’t be scoped safely without\nsessions.
Anyone who shipped against the 2025-11-25 experimental Tasks API will need to\nmigrate to the new lifecycle.
Authorization Hardening
Six SEPs harden the\nauthorization specification\nto align more closely with how OAuth 2.0 and OpenID Connect are deployed in\npractice.
Clients must now validate the iss parameter on authorization responses per\nRFC 9207\n(SEP-2468).\nThis is a low-cost mitigation for a class of mix-up attack that is more\nprevalent in MCP’s single-client, many-server deployment pattern. In a future\nversion, clients will be expected to reject responses that omit iss, so\nauthorization servers should begin supplying it now if they don’t already.
Clients now declare their OpenID Connect application_type during Dynamic\nClient Registration\n(SEP-837),\navoiding the common case where an authorization server defaults a desktop or CLI\nclient to \"web\" and rejects its localhost redirect URI. Clients bind\nregistered credentials to the issuing authorization server’s issuer and\nre-register when a resource migrates between authorization servers\n(SEP-2352).\nThe spec also documents how to request refresh tokens from OpenID Connect-style\nauthorization servers\n(SEP-2207),\nand clarifies scope accumulation during step-up\n(SEP-2350)\nand the .well-known discovery suffix\n(SEP-2351).
Roots, Sampling, and Logging Are Deprecated
Three core features are deprecated under the new\nfeature lifecycle policy\n(SEP-2577):
| Feature | Replacement |
|---|---|
| Roots | Tool parameters, resource URIs, or server configuration |
| Sampling | Direct integration with LLM provider APIs |
| Logging | stderr for stdio transports; OpenTelemetry for structured observability |
These are annotation-only deprecations. The methods, types, and capability flags\ncontinue to work in this release and in every specification version published\nwithin a year of it, and removing any of them will require a separate SEP under\nthe lifecycle policy.
Full JSON Schema 2020-12 for Tools
Tool inputSchema and outputSchema are lifted to full\nJSON Schema 2020-12\n(SEP-2106).\nInput schemas keep the type: \"object\" root constraint but now allow\ncomposition (oneOf, anyOf, allOf), conditionals, and references ($ref,\n$defs). Output schemas are unrestricted, and structuredContent can now be\nany JSON value rather than only an object. Implementations must not\nauto-dereference external $ref URIs and should bound schema depth and\nvalidation time.
Separately, the error code for a missing resource changes from the MCP-custom\n-32002 to the JSON-RPC standard -32602 Invalid Params\n(SEP-2164).\nIf your client matches on the literal -32002 value, update it.
How the Protocol Evolves From Here
This release contains breaking changes. We don’t intend for that to be the norm.
Three governance SEPs in this release are designed so that future revisions can\nevolve the protocol without breaking core capabilities. The\nfeature lifecycle policy\ngives every feature an Active, Deprecated, and Removed lifecycle with at least\ntwelve months between deprecation and the earliest possible removal. The\nExtensions framework means new capabilities\ncan ship as opt-in extensions and stabilize there before, if ever, moving into\nthe specification. And a Standards Track SEP can no longer reach Final status\nuntil a matching scenario lands in the conformance suite\n(SEP-2484),\nwhich is the same suite the new SDK tier system\nscores official SDKs against.
The stateless rework in this release is the kind of foundational change that\nneeded a clean break. With it landed, and with deprecation windows and\nextensions as the standard tools going forward, our expectation is that\nimplementers targeting 2026-07-28 will be able to adopt future revisions without\nrewriting their transport or lifecycle code.
Release Timeline and Validation
The release candidate is locked as of May 21, 2026. The final specification\nwill be published on July 28, 2026. The ten-week window is for SDK\nmaintainers and client implementers to validate the changes against real\nworkloads; under the SDK tier system,\nTier 1 SDKs are expected to ship support within this window.
The full release candidate is in the\ndraft specification, and\nthe changelog\nwill list every change against 2025-11-25.
If you find a problem, open an issue in the\nspecification repository.\nFor implementation questions, the relevant\nWorking Group\nchannel in the\ncontributor Discord\nis the fastest path to an answer.
Looking Ahead
This release gives MCP the foundation we expect it to grow on for a long time: a\nprotocol that runs statelessly on commodity HTTP infrastructure, an extensions\nframework where capabilities like Tasks and MCP Apps can ship on their own\ntimeline, and a lifecycle policy that lets implementers build on 2026-07-28\nknowing what they ship will keep working.
Thank you to everyone who shaped these proposals through the Working Groups and\na great deal of patient review. We’re looking forward to making this final with\nthe community on July 28.
![\"\"](\"https://cdn.prod.website-files.com/621f84dc15b5ed16dc85a18a/671f94f562311089fcaad4fb_66e854bdb169b1ca742715c4_Maria.webp\")
![\"Before](\"https://cdn.prod.website-files.com/621f84dc15b5ed16dc85a18a/6a33dbf747aa1f0c142ff8fb_diagram-mcp-stateless.webp\")