MCP’s 2026 Release Candidate Is a Breaking Change in Service of Boring Production HTTP

MCP just did the thing every young protocol eventually has to do if it wants to survive contact with production: it broke compatibility on purpose.

The Model Context Protocol team has published the release candidate for the 2026-07-28 specification, and the headline is not a new toy for agents. It is a cleanup of the transport assumptions that made early MCP easy to demo and increasingly awkward to operate. Sessions are out. Sticky routing is out. The old initialize handshake is gone. Ordinary HTTP infrastructure is back in charge.

That sounds like plumbing because it is. It is also exactly where agent infrastructure either becomes governable or turns into a pile of bespoke tunnels and optimistic JSON.

Stateless MCP is the adult supervision layer

The biggest change is the removal of protocol-level sessions, including the Mcp-Session-Id header. Under the release candidate, any request can land on any server instance. Protocol version, client identity, and client capabilities move into _meta on every request, while a new server/discover endpoint lets clients learn supported protocol versions, capabilities, and identity up front.

That is a serious architectural shift. Early MCP made sense as local-agent glue: a desktop agent, a nearby tool server, maybe a long-lived process with enough implicit state to keep everyone happy. But once MCP servers sit behind gateways, load balancers, enterprise proxies, SaaS connectors, and multi-tenant agent runtimes, hidden session affinity becomes tax. Sticky routing complicates scaling. Shared session stores become another operational dependency. Gateways cannot reason about traffic without parsing bodies or maintaining special knowledge of every server’s lifecycle.

The release candidate’s answer is blunt: make MCP behave more like boring HTTP. If an application needs continuity, the server should mint an explicit handle — a browser_id, task_id, basket_id, or whatever the domain requires — and pass it as an ordinary tool argument. That makes state visible to the model, portable across server instances, and auditable in normal request logs.

It also moves risk up the stack, where it belongs. Explicit handles need scopes, expiry, logging, and revocation. They must not quietly become bearer tokens with better branding. Stateless transport simplifies infrastructure; it does not absolve tool authors from designing state safely.

Gateways finally get something useful to inspect

The new Streamable HTTP requirements are also operator-friendly. POST requests now carry Mcp-Method and Mcp-Name headers, so gateways, rate limiters, and load balancers can route policy without opening the JSON body. Servers are expected to reject requests where those headers disagree with the body.

That is a small detail with large consequences. A gateway should be able to distinguish tools/call against a deployment tool from tools/list against a docs server. Security teams should be able to rate-limit dangerous operations differently from harmless discovery. Platform teams should be able to observe which tools are actually being called without writing an MCP body parser into every proxy rule. If MCP is going to sit between coding agents and GitHub, databases, CI, incident systems, observability backends, and internal APIs, headers that expose intent are not a nicety. They are the control plane.

The same applies to caching. List and read results can now include ttlMs and cacheScope, giving servers a way to say how fresh a result is and whether it is public or private. That matters because agents are noisy consumers of capability metadata. Re-listing the same tools, prompts, and resources on every turn is wasteful, slow, and harder to govern. Explicit cache hints let clients and gateways reduce repeated discovery without guessing.

Trace context is the difference between a transcript and an audit trail

The release candidate documents W3C Trace Context propagation through traceparent, tracestate, and baggage keys in _meta. This is the sort of feature that will get fewer screenshots than an agent UI and matter more in the first real incident.

When an agent calls an MCP tool, which calls an internal service, which calls a database, the transcript is not enough. Operators need to correlate the model turn, the tool call, the downstream request, the authorization decision, and the resulting mutation. OpenTelemetry-compatible trace propagation gives MCP a path into the observability stack engineers already use instead of inventing a parallel audit universe for agents.

This also changes the evaluation bar for Claude Code, Copilot-style agents, and every tool claiming MCP support. “Can it connect to an MCP server?” is now the wrong question. The useful questions are whether the runtime exposes MCP cost and usage, whether admins can govern which servers load, whether tool calls carry trace context, whether version negotiation is sane, and whether enterprise gateways can enforce policy without heroic packet archaeology.

Extensions keep the core from becoming a junk drawer

The release candidate introduces a formal extension framework with reverse-DNS IDs, negotiated capability maps, separate ext-* repositories, delegated maintainers, and independent versioning. Two official extensions arrive with it: MCP Apps and Tasks.

MCP Apps lets servers provide sandboxed UI templates. Tasks handles long-running work with tasks/get, tasks/update, and tasks/cancel. Both are useful. More importantly, both demonstrate restraint. The core protocol should not absorb every plausible agent feature just because somebody can imagine a demo. Sandboxed UI and long-running task lifecycle deserve experimentation, versioning, and opt-in negotiation. Extensions give MCP a way to evolve without forcing every client and server to implement every new primitive on the same clock.

The deprecations tell the same story. Roots, Sampling, and Logging are deprecated, not immediately removed, with at least a 12-month runway before earliest removal. Logging moves toward the obvious split: stderr for stdio and OpenTelemetry for structured observability. Sampling and Roots were early attempts to let servers ask hosts for model calls or workspace boundaries. In a more enterprise-shaped agent world, those flows need tighter semantics than “the server asked nicely.”

Security hardening is no longer optional garnish

The authorization changes are practical rather than theatrical: issuer validation under RFC 9207, OIDC application_type during Dynamic Client Registration, credential binding to issuer, refresh-token guidance, scope accumulation clarification, and updated .well-known discovery behavior. Tool schemas also move to full JSON Schema 2020-12 support, including composition, conditionals, $ref, and $defs, with warnings not to auto-dereference external references and to bound schema depth and validation time.

That last warning is doing work. Agent tool schemas are executable expectations. If validation can be tricked into unbounded depth, external reference fetching, or ambiguous shapes, the schema layer becomes another attack surface. MCP’s production problem is not only prompt injection. It is all the old API security problems wearing an agent badge: auth confusion, over-broad handles, cache leaks, unsafe redirects, parser differentials, and observability gaps.

The project’s own roadmap names the enterprise gaps plainly: audit trails, observability, SSO-integrated auth, gateway behavior, authorization propagation, session semantics, gateway visibility, and configuration portability. The release candidate is not a full solution to all of that. It is a credible move toward making those problems addressable with normal infrastructure.

What practitioners should do before July

If you maintain an MCP server, read the draft changelog now rather than discovering it through broken clients later. Check whether you depend on initialize, notifications/initialized, Mcp-Session-Id, SSE-style server callbacks, experimental Tasks, Roots, Sampling, Logging, old resource-not-found errors, or partial JSON Schema behavior. Add conformance tests. Decide how explicit state handles will be minted, scoped, expired, and logged.

If you operate MCP infrastructure, start planning policy around Mcp-Method, Mcp-Name, cache scope, issuer validation, and trace propagation. If you run coding agents in an enterprise environment, ask vendors how they will handle discovery, version mismatch, extensions, OTel correlation, and stateless operation. MCP support is no longer a sticker. It is an operational contract.

The release candidate is a breaking change, but this is the right kind of break. MCP is trying to become stateless, routable, cacheable, traceable, and governable. Those are not glamorous adjectives. They are the adjectives that decide whether agent tool access can leave the laptop and survive in production.

Sources: Model Context Protocol blog, MCP draft changelog, MCP roadmap, MCP specification repository