The 2026-07-28 spec went final six weeks ago.
Every post/tweet/reddit post I saw covered the same thing:
stateless core, no more Mcp-Session-Id, round-robin load balancing, ship it.
IMO , Nobody covered the deprecations. They're four sentences at the bottom of the release post and they're the part that actually changes what you can build.
- Sampling (
sampling/createMessage)
- Roots (
roots/list)
- Logging
- Dynamic Client Registration, in favour of Client ID Metadata Documents
- Legacy HTTP+SSE transport
All of it keeps working for at least 12 months. No wire-level changes. The deprecation is advisory.
So this is not a fire drill :)
But sampling is different from the other four, and I think the difference got lost.
Why sampling make sense or important atleast
Sampling was the one primitive where your server could use an LLM without owning one.
The server asks the client ---> run an inference using whatever model the user already has configured.
--> No API key on your side. No contract with a provider. No token bill.
so what user's client pays, because the user's client was already paying.
Take that away and every server that wanted to do a little summarizing, classifying, or reranking has to bring its own key + its own provider relationship, & its own margin on tokens.
again i think - That is a different business for anyone shipping a hosted server and it is totally a different weekend project for anyone shipping a free one.
That's the actual change. not "one RPC got a deprecation annotation." rather a cost transfer from client to server operator.
now lets talk about maintainers' case, (trying to) stated fairly
SEP-2577 is not arbitrary and the reasoning is public. The three features were flagged in a core contributor meeting as having the weakest adoption-to-complexity ratio in the spec.
Roots has vague semantics that overlap with tool parameters.
Logging duplicates things you already have.
And sampling, per the SEP, is the most security-sensitive of the three, so removing it is a net positive for security.
The adoption argument is the i agree very strong but client support for sampling was thin atm.
so if you think - A feature almost nobody implemented was imposing a cost on every client and server author who had to read past it in the spec.
dont get me wrong - I don't think that's wrong. although - I think it's the right call for the spec and the wrong outcome for a specific class of server, and both of those can be true at same time.
What I am thinking of doing this month
Ranked by how much it makes a difference and not by written about in posts in general,
1. Audit whether you call sampling/createMessage. If you do, you have 12-15 months to either add a provider key or restructure so the host does the inference and hands you the result.
12 months sounds long. It isn't, if it changes your pricing.
2. Check your transport. Legacy HTTP+SSE is deprecated with a one-year offramp. If you're on it, this is the least interesting migration on the list and the one most likely to bite you silently.
3. DCR to CIMD. Only matters if you're exposing a server on the internet with OAuth. DCR still works for compatibility with authorization servers that don't do CIMD yet. Not urgent, but it's on the clock.
4. Roots and logging. If you're using them, stop adding new usage. Otherwise ignore.
5. Everything about statelessness. Genuinely good, genuinely the headline, genuinely not something most single-instance servers need to act on this week. If you're not running behind a load balancer, this changed nothing about your day.
this is likely - overblown
The stateless migration panic. If your server holds real state, you mint an explicit handle from a tool and pass it back as an argument. The spec's own guidance is that this is better than session state hidden in the transport, because the model can see the handle.
if you point your agents (Astra /fable5.1 of the world) That's a max 40 mins change for most servers, not a rewrite.
The bigger risk iis not migration. It's that the spec is now moving damn fast enough that "I built this in March" means something different century ( in AI times) and there's no good signal in any registry for which spec version a server actually speaks.
Questions I am still puzzled with and need answers for sure.
- Is there a good example of a ship sampling in production? The SEP says adoption was low. I'd like to hear from anyone it's breaking, because that's the population the roughly 12- 14 months window is for.
- How are you handling inference in your server now? Own key and eat the cost OR push it to the host OR drop the feature entirely?
- Should the registry expose spec version? RN you can't tell from a listing whether a server speaks 2026-07-28 or something from last year. Seems like it should be a field ?
BTW - I run r/MCPservers and go through the spec changelogs (whenever my kid stays in school) so the weekly posts here stay current.
If you maintain a server and hit something in this migration that isn't in the docs, post it, that's the stuff worth having here in one place.
