MCP Is Deprecating Sampling, Roots, and Logging: What It Means for the Ecosystem
SEP-2577 proposes removing three core MCP features simultaneously. The protocol is scope-reducing to become a lean stateless tool-calling layer. Here is what builders need to know.
On April 15, 2026, MCP core maintainer Kurtis Van Gent filed SEP-2577, proposing to deprecate three protocol features simultaneously: Sampling, Roots, and Logging. Filed the same day, SEP-2575 proposes making MCP fully stateless by removing the initialization handshake and capability negotiation.
Together, these represent the most significant scope change since MCP launched. The protocol is not adding features. It is removing them — deliberately, and with clear reasoning. Understanding what is being cut, why, and what it means for anyone building on MCP is essential for making good architectural decisions in the months ahead.
What Sampling Was — And Why It Mattered
Sampling was MCP’s most ambitious feature and its most controversial. It was the only mechanism in the protocol that let a server request an LLM completion back through the client. In practice, this meant a tool server could say: “I need the model to reason about this intermediate result before I continue.”
This made Sampling the protocol’s closest thing to a coordination primitive. It enabled patterns that no other MCP feature could support:
- Multi-turn server-side reasoning. A server could process data, ask the model to evaluate it, and use the model’s response to determine its next step — all within a single tool invocation.
- Server-initiated callbacks. Instead of returning a final result, a server could request additional context or clarification through the model.
- Chained agent interaction. In theory, Sampling opened the door to server-mediated agent-to-agent communication, where one agent’s tool server could invoke reasoning from the client’s model.
These capabilities positioned Sampling as the feature that would elevate MCP from a tool-calling protocol to something closer to an agent coordination layer. That vision is now being explicitly abandoned.
Why Sampling Is Being Removed
The pragmatic case for removing Sampling is straightforward: almost nobody used it.
Implementing Sampling correctly required human-in-the-loop approval at the client level. The specification mandated that clients maintain user control over what the model generates in response to server requests. This meant every Sampling invocation needed a consent mechanism — a dialog, an approval flow, a policy engine. For most client implementations, this complexity was not worth the engineering investment for a feature that few servers actually called.
The result was predictable. Major MCP clients either did not implement Sampling at all or implemented it behind experimental flags that users rarely enabled. Server developers, seeing no reliable client support, did not build features that depended on it. The feedback loop never achieved critical mass.
Beyond adoption, there was a security dimension. Palo Alto Networks’ Unit42 research team documented multiple attack vectors enabled by Sampling. Because Sampling let servers inject content back into the model’s context through the client, it created surfaces for token inflation attacks, context poisoning, and capability escalation. A malicious server could use Sampling to inflate token consumption, inject misleading context into the model’s reasoning, or attempt to escalate its own permissions by manipulating what the model believed about the server’s capabilities.
The SEP authors argue that Sampling’s functionality is better handled outside the protocol entirely. If a server needs LLM completions, it can call an LLM API directly. If agents need to coordinate, they can use purpose-built coordination layers. MCP does not need to be the mechanism for either.
What Logging Removal Means
MCP’s built-in logging feature allowed servers to emit structured log messages back to clients through the protocol. The specification included log levels, structured metadata, and a defined message format. The intent was to provide a standardized way for servers to communicate operational information — errors, warnings, performance data — through the same channel used for tool calls.
SEP-2577 proposes deprecating this feature as “redundant with stderr and OpenTelemetry.” The reasoning is that every serious production deployment already has logging infrastructure, and duplicating it inside the protocol creates more complexity than value. Servers that need to log can write to stderr. Systems that need structured observability can use OpenTelemetry. MCP does not need its own logging primitive.
This is technically sound but carries a practical implication that teams should think through carefully. Protocol-level logging meant that audit information traveled through the same authenticated, structured channel as tool calls. For compliance-oriented deployments, this was convenient — a single protocol stream contained both the operational data and its audit trail.
With logging moving outside the protocol, teams that need audit trails will have to implement them at another layer. This is not a crisis — it is the standard practice in every other RPC protocol — but it is a migration that needs planning. The timing matters: the EU AI Act’s Article 12 record-keeping requirements take effect on August 2, 2026. Organizations deploying MCP-based agent systems in the EU will need to demonstrate that they maintain adequate records of AI system operation, including tool invocations and their outcomes. That audit infrastructure now needs to be built independently of MCP.
What Roots Removal Means
Roots was a mechanism for clients to inform servers about filesystem context. A client could declare a set of root directories — project folders, workspace paths, repository roots — and the server could use that information to scope its operations. A code analysis server, for example, could use Roots to know which directories to scan without requiring the user to pass paths explicitly in every tool call.
The feature is being deprecated in favor of simpler alternatives. The SEP suggests that filesystem context can be passed through tool parameters, environment variables, or server configuration. Roots added protocol-level complexity for a problem that most implementations solved at the application layer anyway.
For teams that relied on Roots, the migration is the most straightforward of the three deprecations. Most Roots usage can be replaced by adding a path parameter to relevant tool definitions or by configuring the server with workspace information at startup.
The Architectural Direction
Taken individually, each deprecation has a clear rationale. Sampling was underadopted and insecure. Logging was redundant with existing infrastructure. Roots was solvable at the application layer. But taken together, the three deprecations — combined with SEP-2575’s proposal to make MCP fully stateless — reveal a deliberate architectural direction.
MCP is scope-reducing.
The protocol is being narrowed to do one thing well: stateless tool invocation. A client sends a tool call. A server executes it and returns a result. No session state. No coordination primitives. No built-in observability. No filesystem context negotiation.
This is not regression. It is protocol maturation. The history of successful infrastructure protocols follows this pattern. HTTP did not try to include session management in the protocol — cookies and session tokens were added at the application layer. DNS does not include caching policy in the protocol — TTLs and resolver behavior are implementation concerns. The protocols that endure are the ones that define a narrow, stable contract and let the ecosystem build everything else around them.
The message from the MCP maintainers is clear: MCP does tool invocation. Coordination, logging, state management, and governance belong in other layers of the stack. The protocol is explicitly choosing not to be a platform.
What This Means for Builders
If you are building on MCP today, here is the practical impact.
If you built on Sampling, you need an alternative coordination mechanism. The options depend on your use case. For server-side LLM reasoning, direct API calls to model providers are the most straightforward replacement. For agent-to-agent coordination, you need a purpose-built messaging or orchestration layer. The key architectural lesson is that coordination should not be coupled to your tool-calling protocol.
If you relied on MCP Logging for audit trails, you need external observability infrastructure. OpenTelemetry is the obvious choice for structured telemetry. For compliance-specific audit logging, consider a dedicated audit service that captures tool invocations at the gateway or client layer. Start this migration now if you have EU AI Act obligations — August 2 is less than four months away.
If you used Roots for filesystem context, the migration is relatively simple. Move workspace path information into tool parameters, server configuration, or environment variables. This is a one-time refactor with minimal architectural impact.
The broader lesson is the most important one. The protocol is explicitly choosing not to be a platform. Build your governance, coordination, and observability layers independently of MCP. Do not assume that any protocol feature beyond core tool invocation will remain stable. Design your architecture so that MCP is the tool-calling layer and nothing more — everything else should be pluggable and replaceable.
The deprecations in SEP-2577 will not break most existing deployments immediately. The SEP proposes a deprecation period before removal. But the direction is set, and building new systems that depend on features marked for deprecation is a choice that will cost time later.
MCP is getting smaller on purpose. The ecosystem needs to build the layers that the protocol is choosing not to be.