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.
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.
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.
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.
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.