MCP is going stateless: what the 2026-07-28 revision breaks in your web data integration

The Model Context Protocol's 2026-07-28 revision is due to be published tomorrow. The release candidate has been locked since 21 May 2026, and the announcement that shipped with it opens without hedging: this release contains breaking changes. It is, in the maintainers' own framing, the largest revision of the protocol since launch.

That matters to anyone buying web data, because "we have an MCP server" has become a standard line on vendor feature pages over the last eighteen months. From tomorrow it stops being a sufficient answer. A hosted MCP server is now a versioned protocol surface with a deprecation clock attached, and the useful question moves from whether a vendor has one to which revision it speaks, when it will move, and what breaks on your side when it does.

This is a different question from which servers exist, which we covered in the web data MCP server landscape. This one is about protocol risk.

What "stateless" actually removes

Two proposals do most of the damage. SEP-2575 removes the initialize/initialized handshake: the protocol version, client info, and client capabilities that used to be exchanged once at connection time now travel in _meta on every request, with a new server/discover call for clients that want server capabilities. SEP-2567 removes the Mcp-Session-Id header and the protocol-level session it carried.

With both gone, any request can land on any server instance. Sticky routing and a shared session store stop being requirements at the protocol layer. For a vendor operating a hosted server at scale, that is straightforwardly good news, and it is why the change was made.

The cost lands on interoperability. Stacklok's enterprise readiness guide for the update, as summarized by The Register on 23 July 2026, warns that the twelve-month deprecation window is not a blanket guarantee of compatibility: servers on the 2026-07-28 revision may not work with older clients, and older servers may not work with new ones. In its words, compatibility "requires both sides to share a supported protocol era, or for one side to implement deliberate fallback or translation." Anthropic's David Soria Parra, speaking on a livestream reported in the same piece, called these the most substantial changes to the specification since authorization was added, and said that a lot of what made MCP is gone.

Two-sided compatibility is the part buyers underrate. You do not control both ends: your client is Claude, or Cursor, or your own agent runtime, and your server is your vendor's. If they move on different schedules, the gap is yours to absorb.

What the session id was quietly doing to your bill

The coverage has focused on transport. The second-order effect is commercial. Session identifiers are load-bearing in billing systems, not only in technical ones: per-session rate limits, concurrency caps, and quota accounting are all natural things to anchor to a session id, because the protocol handed you one for free.

The protocol stops handing one out. Whatever a vendor was counting per session now has to be re-based on something it controls directly: the API key, the OAuth access token, the account, or an application-level handle the vendor invents and asks you to pass. Any of those is workable. They are not equivalent for you.

The practical difference shows up in how your usage is grouped. If rate limiting moves from per-session to per-key, then ten concurrent agent runs sharing one key stop being ten independent budgets and become one contended budget. If quota attribution moves to the account level, per-tenant cost allocation that you were deriving from session ids stops working. Neither of these is a protocol bug. They are consequences of removing the identifier that both sides had quietly agreed to bill against.

Ask your vendor what replaces the session id for metering, and ask for the unit in writing. A vendor that cannot name the new counter has not finished designing its own migration.

The deprecation table

The revision also introduces MCP's first formal feature lifecycle policy (SEP-2577), which is the more durable news. Features move from active to deprecated to removed, with at least twelve months between deprecation and the earliest possible removal. Four things are deprecated on day one.

These are annotation-only deprecations. Nothing you built on Roots or Sampling stops working tomorrow. But the removal date is no longer indefinite, and a year is short relative to how long enterprise integrations live. Parra's stated reasoning, per The Register, was that Sampling was rarely used and its semantics were confusing to implement, Roots was niche, and Logging was excessively chatty.

Why Sampling's deprecation moves money

Sampling let a server ask the client's model to generate a completion on its behalf. In a web data context that is an attractive pattern: an extraction server can ask your model to interpret a page or decide which link to follow next, without the vendor operating or paying for any inference. The inference ran on your side, on your model, at your cost.

The stated replacement is direct integration with LLM provider APIs. That pushes model choice and inference cost back onto whoever is doing the extraction. For a vendor that built agentic behavior on borrowed inference, this is a product change, not a config change: either it starts paying for its own model calls and prices that in, or it asks you to supply an API key and configure a model, or it restructures the feature so the model call happens in your code around the tool rather than inside it.

If you are relying on an agentic extraction feature that today runs on your model through Sampling, that feature is on a clock. It is worth finding out now which of those three paths your vendor intends to take, because two of them change your unit economics and one of them changes your integration code.

Extensions mean "MCP support" no longer means one thing

The revision formalizes an Extensions framework: extensions get reverse-DNS identifiers, negotiate through capability maps, and version independently with their own maintainers and repositories. Two extensions graduate with it. MCP Apps delivers server-rendered user interfaces in sandboxed iframes, and Tasks, previously experimental, moves out of the core into an official extension with a redesigned lifecycle.

This is good protocol design and it is a procurement complication. Under a monolithic spec, "supports revision X" implied a known feature set. Under an extensions model, two vendors can both truthfully claim 2026-07-28 support and expose different capability sets, because extensions are optional and independently versioned. Long-running crawls are exactly the kind of workload that wants the Tasks extension. Whether a given server implements it is now a separate question from which revision it speaks, and you have to ask both.

Five questions for your vendor

Short enough to paste into an email, and all five are answerable today.

1. Which protocol revision does your hosted MCP server speak right now, and which will it speak on 28 July? A specific date-versioned answer, not "the latest."
2. What is your migration plan, and will you run both revisions in parallel? Deliberate fallback or translation is the only thing that makes a two-sided version gap survivable.
3. Do we currently depend on Roots, Sampling, Logging, or Dynamic Client Registration? If yes, what replaces each, and on what schedule.
4. What replaces the session id for rate limits, quota, and usage attribution? See above. This is the question most likely to produce a surprising answer.
5. Is this a first-party hosted server, and does it support remote OAuth 2.1? The authorization hardening in this revision includes iss validation per RFC 9207, OpenID Connect application_type declaration at registration, and credential binding to the issuing authorization server. A community-maintained wrapper is unlikely to track that on the vendor's timeline. Cloudflare's Agents Week releases in April 2026 included Shadow MCP detection for exactly this problem, unsanctioned servers sitting inside otherwise governed environments.

Applying it to the servers you are actually choosing between

For a team sourcing web data, the shortlist of vendors shipping their own MCP server is small enough to work through directly. Firecrawl and Exa sit on the extraction and search side, Tavily is a search API with agent integration as its stated design center, Apify exposes a marketplace of actors through one surface, Brave Search API fronts an independent index, and Browserbase is browser infrastructure where sessions are the billing unit.

Browserbase is the awkward case. Removing protocol-level sessions does not remove browser sessions, which stay stateful and remain the thing being billed. A browser infrastructure vendor now has to carry session identity in the application layer, through explicit handles passed in and out of tool calls, rather than inheriting it from the transport. That is a more invasive change than it is for a stateless search endpoint, and it is the category where question four matters most.

For the search and extraction vendors, the sharper question is three. Any agentic feature described as reasoning over pages or deciding what to fetch next is a candidate for having been built on Sampling.

What this means if you build on web data

Treat the MCP revision as a vendor attribute you record, not a checkbox. It belongs next to pricing and SLA in your evaluation, with a date attached. "Has an MCP server" was a useful signal in 2025 and is close to meaningless now.

Audit for Sampling before your renewal, not after. It is the only deprecation in the table that can move inference cost from a vendor's balance sheet onto yours, or the reverse, and the twelve-month window makes deferral tempting.

Expect a window where client and server revisions disagree. Aggregator figures reported by Digital Applied in April 2026, which are not audited, put the ecosystem at roughly 97 million combined monthly Python and TypeScript SDK downloads and more than 10,000 active public servers. WorkOS counted ten agent clients supporting custom remote servers with native OAuth 2.1 that same month. An installed base that size does not migrate in lockstep, and the mismatches will surface as failures that look like vendor outages.

Keep a non-MCP path to the same data. Every vendor on the list above sells a plain HTTP API alongside its MCP server, and that API is not changing tomorrow. If you are weighing how much integration surface to own yourself, this is a concrete argument for keeping the direct call available even when the MCP path is the one you use day to day. The same logic applies to choosing an access channel: protocol risk is one more reason not to single-source. Our guide to MCP and tool use and the MCP glossary entry cover the mechanics; running these servers in production covers what breaks after they are wired up.

The specification is not the risk here. A stateless core is the right call, and the maintainers were explicit that a clean break now is what lets future revisions land without rewriting transport and lifecycle code. The risk is the migration window, and it opens tomorrow.