Most of the coverage of the 2026-07-28 MCP release candidate has been about the protocol going stateless — the initialize handshake gone, Mcp-Session-Id gone, servers running behind a plain round-robin load balancer. That's the change with the biggest blast radius, and it's worth its own post. But underneath it is a smaller edit that tells you more about where the Model Context Protocol thinks it's going: three of its original primitives — Roots, Sampling, and Logging — are being deprecated.

Two SEPs do the work. SEP-2577 marks the three features deprecated. SEP-2596 is the more durable contribution: MCP's first formal feature-lifecycle policy, defining three states — Active → Deprecated → Removed — with a guaranteed floor of twelve months between a feature being marked deprecated and its earliest possible removal. Deprecation and removal are separate proposals, so nothing vanishes when a timer expires; someone has to write the removal SEP.

So the practical news is: nothing breaks today. These are annotation-only deprecations — no wire-level change, the methods keep answering identically, and anything deprecated in this revision is guaranteed to work through at least July 2027. If your server uses these features, you have a year of runway and a clear migration target. That's the responsible half of the story.

The reason they were chosen#

Per SEP-2577, contributors flagged these three as the features with the weakest adoption-to-complexity ratio: low real-world uptake, a viable alternative outside the protocol for each, and an implementation burden that every compliant client and server had to carry regardless. None is load-bearing for MCP's core loop of resources, tools, and prompts. The migration paths are unglamorous by design — Roots becomes an explicit tool parameter, resource URI, or server-config value; Logging moves to stderr for stdio transports and OpenTelemetry for structured observability; Sampling is told to integrate an LLM provider API directly.

That last one is the load-bearing deletion, and it's worth sitting with.

What actually got cut#

Here's the pattern nobody put in the changelog. Look at the direction of each deprecated feature.

MCP's core is the client reaching into the server: call a tool, read a resource, fetch a prompt. The server is a passive surface. But Roots, Sampling, and Logging all run the other way — they are the channels where the server reached back into the client's runtime. Sampling borrows the client's model. Roots reads the client's filesystem map. Logging pipes into the client's log stream. Every one of the three deprecated primitives is a place where the server got to touch something that belongs to the environment running it.

The three features being cut aren't random low-adoption stragglers. They're the exact three where the server reached back into your runtime — its model, its filesystem, its logs.

Deprecating them draws a line MCP had left blurry since the start: the client owns the LLM and the environment; the server owns tools, resources, and prompts. A server that wants model reasoning brings its own model. A server that wants to know your working directory has to be told, explicitly, as an argument. A server that wants to emit telemetry uses the observability stack you already run, not a bespoke protocol channel into your UI.

Why Sampling is the tell#

Sampling was the most seductive feature in the protocol. It let a server add AI reasoning without shipping an API key or paying for inference — hand the messages to the client, let the client's model do the work, get the completion back. Free intelligence, from the server author's point of view. It was also, per the SEP, the most security-sensitive of the three: the server is spending your model and your budget on a prompt you may never see, through a capability many clients implemented with thin review. (I wrote earlier about how Sampling and Elicitation turned MCP into a two-way protocol; this is the spec walking half of that back.)

And note what survives: Elicitation — the server's channel to ask the human for structured input — is not deprecated. So the cut is surgical. MCP is keeping the reach-back to the person and severing the reach-back to the model. That's not an accident of adoption numbers. Model choice, cost, and the privacy boundary are precisely the things a tool-provider should never get to reach into silently. Asking a human "do you approve this?" is a healthy interaction. Quietly running a completion on the human's dime is not.

What to do with the year#

Concretely: if you depend on Sampling, wire in a direct provider API now and own the cost you were externalizing. If you depend on Roots, pass the boundary as an explicit argument. If you emit MCP log notifications, move to stderr or OpenTelemetry — where your production telemetry already is. None of it is urgent. All of it is the direction of travel.

The stateless rewrite is what makes MCP cheaper to run. The deprecations are what make it honest about what it is: not an agent runtime that lends servers your model and your machine, but a tool-access protocol with a firm wall down the middle. Growing up, mostly, looks like subtraction.