The MCP 2026-07-28 Spec: What Changes and What Breaks

The MCP 2026-07-28 spec is the largest rewrite the Model Context Protocol has had since it launched, and it will reach any business running AI agents against its own systems. At the time of writing it is a release candidate rather than a final standard: the official MCP blog locked the candidate on 21 May 2026, published beta SDKs on 29 June 2026, and scheduled the final specification for publication on 28 July 2026. The changes described here are already public in the draft changelog, but the publication date is the moment they become the standard.

If you have an MCP server sitting in front of your CRM, your inventory system, or your internal knowledge base, this is the revision that decides how much rework the next twelve months contain. It is worth an hour of your attention now rather than a surprise outage later.

What the MCP 2026-07-28 spec actually changes

The core idea is that MCP stops being stateful.

According to the official specification changelog, protocol-level sessions and the session-ID header are removed from the Streamable HTTP transport under SEP-2567. The list endpoints for tools, resources and prompts no longer vary per connection. Servers that genuinely need state across calls are expected to mint explicit handles and pass them as ordinary tool arguments instead.

The initialize handshake goes too, under SEP-2575. Every request now carries its own protocol version and client capabilities in the request metadata field, and a version mismatch returns an unsupported-protocol-version error rather than failing at connection setup. A new `server/discover` method takes over the advertising job. Servers must implement it, and clients may call it before anything else to select a version up front.

Three further removals matter operationally. The HTTP GET endpoint and the resource subscribe and unsubscribe methods are replaced by a single long-lived listen stream that clients opt into by notification type. Ping, the log-level setter, and the roots-list-changed notification are removed. Stream resumability is removed as well: without event IDs and the resume header, a broken response stream loses the in-flight request, and the client has to re-issue it as a fresh request.

Why statelessness is the whole point

The old design assumed a developer running a server on a laptop. That assumption stopped being true the moment companies put MCP servers behind load balancers.

TechCrunch, covering the update on 20 July 2026, quoted Arcade founding engineer Nate Barbettini describing the practical problem plainly: with sessions, every machine in a fleet has to know about a session ID that some other machine issued. That forces sticky sessions, a shared session store, or both, and it is the reason so many MCP deployments never left the pilot stage.

Removing sessions means a request can be answered by any instance behind an ordinary round-robin load balancer. In infrastructure terms this is unglamorous and enormously valuable. It converts an MCP server from a special-case stateful service into something your existing web hosting already knows how to run, scale, and restart.

The Register, reporting on 23 July 2026, quoted Anthropic's David Soria Parra calling these "the most substantial changes we have made to the specification". The same article carried a warning from Stacklok's enterprise readiness guidance that servers on the new revision may not interoperate with older clients, and vice versa, unless one side implements deliberate fallback or translation.

The change most likely to break your integration

Beyond sessions, the change with the widest blast radius is the Multi Round-Trip Requests pattern introduced under SEP-2322.

Previously a server could initiate a request back to the client, which is how sampling, roots listing and elicitation worked. That is no longer possible in a stateless world. Instead, a server returns an interim result marked as requiring input, carrying the questions it needs answered. The client gathers the answers and retries the original call with those responses attached.

Every result now also carries a required result-type field, set either to complete or to input-required. Clients must treat a missing field from an older server as complete, which is the one deliberate backward-compatibility affordance in the design.

If you built a custom MCP server rather than generating one from an SDK, this is where the work lands. Any flow where your server asked the client a question mid-execution has to be restructured around retries rather than callbacks.

What is deprecated, and the twelve-month clock

The revision also introduces something the protocol has been missing: a formal feature lifecycle. Under SEP-2596 the specification now defines active, deprecated and removed states, with a minimum twelve-month deprecation window and a public registry of deprecated features.

Three features enter that window under SEP-2577. Roots, sampling and logging are all deprecated. They keep working, but new implementations should not adopt them. The changelog suggests concrete replacements: pass directories and files as tool parameters, resource URIs or server configuration instead of roots; call your LLM provider's API directly instead of using sampling; and write to standard error or emit OpenTelemetry traces instead of using protocol logging.

The older HTTP with server-sent-events transport, already soft-deprecated since early 2025, is now formally deprecated. So is OAuth dynamic client registration as a registration mechanism, in favour of client ID metadata documents, though it stays available for authorization servers that need it.

For anyone planning a build, the practical reading is simple. A twelve-month minimum window means you are not facing an emergency, but you are facing a deadline that now has a published shape.

Tasks and MCP Apps become extensions

Long-running work moves out of the core protocol into an official tasks extension under SEP-2663. The redesign suits the stateless model: a server can hand back a task handle, and the client polls for status rather than holding a blocking call open. There is also a method for feeding input to a task mid-flight.

Alongside it, MCP Apps lets a server ship interactive HTML that the host renders in a sandboxed iframe, so a tool can return a chart, a form, or a picker instead of a wall of text. For business workflows this is the more interesting of the two. An approval step that renders as an actual form is a materially better experience than one negotiated through chat.

Both are extensions rather than core, which is a deliberate governance choice. Anthropic's Den Delimarsky, quoted in The Register, framed extensions as a way to test ideas before baking them into the protocol. Extensions are disabled by default and require explicit opt-in, and the specification asks implementers to document graceful degradation when the other side does not support them.

Authorization gets stricter

The authorization changes are smaller but not optional. Clients must now validate the issuer parameter on authorization responses against the recorded issuer before redeeming an authorization code, per RFC 9207 and SEP-2468. Clients must declare an appropriate application type during dynamic client registration to avoid redirect URI conflicts. And credentials are now explicitly bound to the authorization server that issued them, so they must be keyed by issuer, never reused elsewhere, and re-registered when the authorization server changes.

If your MCP server touches customer data, these are the clauses to hand your security reviewer.

A migration plan that fits a small team

Work through it in this order.

First, inventory what you actually run. Separate servers you built from servers you consume, and mark which are internal-only and which are exposed to third-party clients. Internal servers where you control both ends are the easy case, because you can upgrade both sides together.

Second, upgrade on SDKs wherever you can. Beta SDKs for the new revision have been available since 29 June 2026, and SDK-generated servers absorb most of the transport-level changes for you. Custom implementations do not.

Third, find every server-initiated request in your code. Sampling, roots and elicitation calls all have to become retry-driven round trips. Budget real engineering time for this rather than treating it as a version bump.

Fourth, check your client side. If your agents call third-party MCP servers, ask each vendor which revision they will support and when. Mixed-era fleets are the likeliest source of quiet failures.

Fifth, delete the infrastructure you no longer need. Sticky-session rules, shared session stores and session-affinity load balancer configuration can come out once you are fully on the new revision, which is where the cost saving actually shows up.

If you buy rather than build

Not every business needs to track a protocol revision. If your agents run inside a platform that someone else maintains, most of this is your vendor's problem, and the right move is to ask two questions: which revision they target, and what their fallback story is for older clients.

The reason to care anyway is that this revision is what makes MCP boring enough to run in production. The ecosystem is already substantial, with The Register citing figures of roughly 97 million monthly downloads and more than ten thousand servers. What was missing was the ability to scale a server the way you scale any other web service. That is what changed.

At AbhijeetBuilts we build MCP servers and agent integrations for small and mid-size businesses, usually as the connective layer between an agent and systems like Zoho CRM, inventory platforms, or an internal document store. In practice the work is less about the protocol and more about deciding which operations an agent is allowed to perform, how failures surface to a human, and how the whole thing is monitored once it is live. A stateless protocol makes that architecture considerably cleaner.

If you are planning an MCP server, or you already have one that predates this revision and you want a clear-eyed view of the migration effort, get in touch through the website and we can walk through your setup.