DevNews

MCP 2026-07-28: what the stateless core removes

On this page
  1. Removed and deprecated are doing different jobs
  2. The migration nobody has a deadline for
  3. What to grep for this week
  4. The number depends on who you ask
  5. Sources

Read any writeup of the new MCP spec and you get the same reassurance, roughly: deprecated features stick around for at least twelve months, so there's no rush. That's true. It's also answering a question nobody asked. The 2026-07-28 revision, published Tuesday, has a Major changes section and a Deprecated section, and they are not the same list. Roots, Sampling and Logging are deprecated, and yes, they get the year. Sessions, the initialize handshake, ping, and SSE resumability are removed. Different word, different section, no window. We spent this morning in the changelog rather than the announcement, and the gap between those two sections is the whole migration.

The short answer

MCP 2026-07-28 landed on Tuesday and makes the protocol stateless. Sessions, the initialize handshake, ping and SSE resumability are gone from the revision. Roots, Sampling and Logging are merely deprecated, with a twelve month floor before removal. Almost every summary we read blurred those two into one reassuring sentence. Nothing switches off on your server today, though, because MCP is versioned and the old revision still negotiates.

9major changes, mostly removals
0of them covered by the year
12 mowindow, for the other list
Answer card: the MCP 2026-07-28 specification removes protocol sessions, the initialize handshake, ping and SSE resumability outright, while separately deprecating Roots, Sampling and Logging under a new twelve month lifecycle policy.
Two lists, two very different meanings, one release. PNG

Removed and deprecated are doing different jobs

The changelog runs nine numbered entries under Major changes. Count the verbs and seven of them start with remove or replace.

Gone: protocol sessions and the Mcp-Session-Id header. Gone: the initialize and notifications/initialized handshake, with every request now carrying its protocol version and client capabilities in _meta instead. Gone: ping, logging/setLevel, notifications/roots/list_changed. Gone: SSE stream resumability, meaning the Last-Event-ID header and event IDs, so a broken response stream loses the in-flight request and the client has to re-issue it under a fresh request ID. The HTTP GET endpoint along with resources/subscribe and resources/unsubscribe gets folded into one subscriptions/listen stream that clients opt into by notification type.

Then there’s a separate section headed Deprecated. Roots, Sampling and Logging sit there, fully functional, scheduled for removal no sooner than a year out. So does the old HTTP+SSE transport, which has been unloved since March 2025 and only now gets a formal lifecycle state. So does OAuth Dynamic Client Registration, pushed aside in favour of Client ID Metadata Documents but kept for authorization servers that don’t speak CIMD yet.

Both sections shipped in the same document. Only one of them gets the year.

Comparison of the two lists in the MCP 2026-07-28 changelog: features removed in this revision with no deprecation window against features placed in the Deprecated state with a minimum twelve month runway.
The lifecycle policy was adopted in this release. It applies going forward, not backward. PNG

Here’s the bit that makes it defensible rather than sloppy. The twelve month floor comes from a feature lifecycle policy that this very release adopts, with Active, Deprecated and Removed states plus a registry. A policy written on Tuesday can’t have governed decisions made before it. The Major changes list is what the protocol looked like when that policy came into force, not something the policy failed to protect.

Still worth knowing which list your code is on.

The migration nobody has a deadline for

Now the honest counterweight, because a lot of the Tuesday coverage read like an emergency and it isn’t one.

MCP is versioned. A server speaking 2025-11-25 keeps talking to clients that negotiate 2025-11-25, and removal means those methods are absent from the new revision, not that they stopped working on the wire overnight. The spec even builds in tolerance in the other direction: clients MUST treat results from earlier-protocol servers that omit the new required resultType field as complete, and server/discover doubles as a backward compatibility probe on STDIO.

So the real deadline is whenever hosts stop offering the old revision. We went looking for that date. Anthropic’s post says support is being rolled out across Claude products soon and attaches no timeline to it, and we couldn’t find a published cutover date from any major host. That’s the number that actually governs your migration schedule, and as of this morning it doesn’t exist publicly.

I’d treat that as good news with an asterisk. You have time. You just can’t plan against a date nobody has printed.

What to grep for this week

If you run an MCP server behind anything, two changes are worth ten minutes today.

The first is headers. Streamable HTTP POSTs must now carry Mcp-Method and Mcp-Name, which exists so load balancers and rate limiters can route on the operation without parsing the body. Genuinely useful. The sharp edge is that servers reject requests where the headers and the body disagree, so any proxy that rewrites one and not the other becomes a bug generator.

The second is error codes. Resource not found moved from -32002 to -32602, and the spec flags it directly: if your client matches on the literal value, update it. Three draft-era codes got renumbered too, under a new policy that reserves -32020 through -32099 for the specification and grandfathers existing SDK usage in the -32000 to -32019 range.

Checklist of what to verify before upgrading to MCP 2026-07-28, covering session state, the server discover RPC, required headers, error code matching, cacheable list results and the deprecated feature set.
Ten minutes of grep beats a week of intermittent failures. PNG

One more that’s easy to miss. tools/list, prompts/list, resources/list and resources/read now require ttlMs and cacheScope on their results, and servers SHOULD return tools in a deterministic order so clients cache well and prompt caches hit. If your list handler builds its response from a map iteration, that ordering is not stable and you’re quietly costing yourself cache hits.

The number depends on who you ask

Small thing, and we noticed it because both posts went up the same day.

The official Model Context Protocol wordmark, a white looping ribbon logo beside the words Model Context Protocol, on a near black background.

Image: Model Context Protocol

The protocol blog says the Tier 1 SDKs are pulling close to half a billion downloads a month, with the TypeScript and Python SDKs past a billion total. Anthropic’s post says MCP recently surpassed 400M monthly SDK downloads, a 4x increase this year, and that Claude now lists over 950 MCP servers in its connectors directory. Those two monthly figures are roughly a hundred million apart on the same Tuesday.

Neither is wrong, probably. Different cutoffs, or a different set of SDKs counted. Just pick one and say which when you quote it.

Tasks moved out of the experimental core into a proper extension at io.modelcontextprotocol/tasks, joining MCP Apps and Enterprise Managed Authorization under the new extensions framework. Anyone who shipped against the 2025-11-25 experimental Tasks API has real migration work: the blocking tasks/result is replaced by polling through tasks/get, there’s a new tasks/update for client-to-server input, and tasks/list is gone. Tier 1 SDK updates cover TypeScript, Python, Go and C#, with Rust in beta.

The agent tooling we’ve been writing about all month, from Cursor’s swarm experiment to OpenAI’s enterprise agent push, sits on top of this plumbing. Worth reading the changelog rather than the announcement, is all.

Sources

Primary text and the numbers above come from the official 2026-07-28 changelog, the Model Context Protocol release post and its release candidate writeup. Anthropic’s rollout note and the connectors figure are from its own announcement. We also read Stacktree’s summary, which is the one that prompted us to check the two lists against each other.

Frequently asked questions

What is the MCP 2026-07-28 specification?

It is the Model Context Protocol revision published on 28 July 2026, replacing 2025-11-25. The headline change is that MCP becomes stateless: the initialize and notifications/initialized handshake is gone, the Mcp-Session-Id header is gone, and every request now carries its own protocol version and client capabilities in _meta. Servers no longer need shared storage behind a load balancer, which is what makes serverless and edge deployment practical. The release candidate was locked on 21 May 2026, giving SDK maintainers a ten week validation window before publication.

What actually breaks in MCP 2026-07-28?

Sessions and the Mcp-Session-Id header are removed, so cross-call state has to move to server-minted handles passed as ordinary tool arguments. The initialize handshake is removed and servers MUST implement a new server/discover RPC instead. ping, logging/setLevel and notifications/roots/list_changed are removed. SSE stream resumability goes, including the Last-Event-ID header and event IDs, so a broken stream means the client re-issues the request with a new ID. The HTTP GET endpoint plus resources/subscribe and resources/unsubscribe are replaced by a single subscriptions/listen stream. Streamable HTTP POSTs must now carry Mcp-Method and Mcp-Name headers, and servers reject requests where the headers and the body disagree.

Does the twelve-month deprecation window protect my server?

Only for the features placed in the Deprecated state, which are Roots, Sampling, Logging, the old HTTP+SSE transport, the includeContext values thisServer and allServers, and OAuth Dynamic Client Registration. Those keep working and are scheduled for removal no earlier than twelve months out. The lifecycle policy defining that window was adopted in this same release, so it never applied to the items under Major changes. Those were removed in this revision rather than deprecated in it.

Do I have to migrate my MCP server right now?

No, and this is the part the coverage skips. MCP is versioned, so a server speaking 2025-11-25 keeps working with clients that still negotiate 2025-11-25. What removal means is that the methods are absent from the new revision, not that they stop functioning on the wire today. The real deadline is whenever hosts stop offering the older revision, and as far as we can find, no major host has published that date. Anthropic says support is being rolled out across Claude products soon, with no timeline attached.

What replaces Sampling and Roots in MCP?

The spec suggests integrating directly with LLM provider APIs instead of Sampling, and passing directories or files through tool parameters, resource URIs or server configuration instead of Roots. For Logging, it points at stderr on stdio transports and OpenTelemetry for structured observability. Server-initiated requests in general are handled by the new Multi Round-Trip Requests pattern, where a server returns a result with resultType input_required and the client retries the original request carrying inputResponses.

Which error codes changed in MCP 2026-07-28?

Resource not found moves from -32002 to -32602 to line up with JSON-RPC Invalid Params, and the spec explicitly warns that clients matching on the literal -32002 need updating. Three codes introduced during the draft were renumbered under a new allocation policy: HeaderMismatch from -32001 to -32020, MissingRequiredClientCapability from -32003 to -32021, and UnsupportedProtocolVersion from -32004 to -32022. The range -32000 to -32019 stays implementation-defined with existing SDK usage grandfathered, and -32020 to -32099 is now reserved for the specification.