MCP sampling and roots are both deprecated now
MCP sampling let a server ask the client to run an LLM completion on its behalf, so a server could use a model without holding an API key of its own. MCP roots let a client tell a server which directories and files it considered relevant.
Both were deprecated in the 2026-07-28 revision by SEP-2577, along with server-side Logging. The deprecated features registry records the migration for each: integrate directly with LLM provider APIs instead of sampling, and pass directories through tool parameters, resource URIs or server configuration instead of roots.
Nothing breaks today. Under MCP’s feature lifecycle policy a deprecated feature stays in the spec for at least twelve months, so the earliest either becomes eligible for removal is the first revision released on or after 2027-07-28. New implementations should not adopt them.
What did MCP sampling do?
It inverted the usual direction. Normally the client owns the model and the server owns the tools. Sampling let the server ask the client to perform a completion, so a server could summarise, classify or reason without shipping its own model credentials. The client stayed in control, applying its own approval and its own model choice.
The appeal was real: one API key, held by the host, serving every server the user connects. In practice it meant every client had to implement a completion proxy with approval UI, sampling parameters, model preferences and later tool calling within sampling, and each addition widened a surface that only some clients ever implemented. A server that depended on sampling worked beautifully against one client and not at all against another.
The migration path is to integrate directly with an LLM provider API: if your server needs a model, it holds its own credentials for one.
What did MCP roots do?
Roots let a client hand a server a list of file:// URIs marking the directories the user considers in scope, typically from a workspace or project picker.
The critical detail, and the reason the feature reads as safer than it was: roots were informational guidance, never access control. The spec is explicit that the protocol does not enforce that servers stay within roots. A server was asked to respect the boundary, and nothing stopped it doing otherwise.
That is an awkward shape for a security-adjacent feature, because a mechanism that resembles a boundary can be read as one. Passing paths explicitly through tool parameters, resource URIs or server configuration does not restrict the server either, and it is not meant to. What it does is state the intended scope at the call site, where it is visible and can be validated, instead of leaving it implied by a list the server may or may not consult.
Are they gone from the spec today?
No, and this is where the lifecycle policy matters. Both remain fully specified and functional in 2026-07-28. What changed is their status:
| Feature | Deprecated in | Migration | Earliest removal |
|---|---|---|---|
| Sampling | 2026-07-28 (SEP-2577) | Integrate directly with LLM provider APIs | First revision on or after 2027-07-28 |
| Roots | 2026-07-28 (SEP-2577) | Tool parameters, resource URIs, or server configuration | First revision on or after 2027-07-28 |
| Logging | 2026-07-28 (SEP-2577) | stderr for stdio, OpenTelemetry for observability | First revision on or after 2027-07-28 |
“Earliest removal” is exactly that. It marks when a feature becomes eligible; the actual removal is a maintainer decision at release time and may come later. No feature has yet been removed under this policy.
Both features also changed shape in 2026-07-28 even while being deprecated, because the revision made the protocol stateless. A server no longer sends its own roots/list or sampling/createMessage request. It returns an InputRequiredResult carrying that request, and the client retries the original call with the answer attached. If you are maintaining an implementation of either, it needs that rework to keep functioning on the current revision, which is a reasonable moment to ask whether to migrate off instead.
What does this leave?
Elicitation, and only elicitation. Of the three client features MCP has carried, two are now deprecated, which makes elicitation the entire remaining surface through which a server can ask a client for something.
The direction is consistent. Both deprecated features ran from server to client, asking the client to do work on the server’s behalf, and both have a replacement outside the protocol: a server can hold its own model credentials and read its own files. Elicitation is the case with no equivalent, since a server cannot ask the user a question without going through the client.
What should you do now?
- Building something new? Do not adopt sampling or roots. The spec says so directly, and you would be writing code against a feature that becomes eligible for removal on a known date.
- Maintaining a server that uses sampling? Plan a direct provider integration. You gain reliability, since you stop depending on whether each client implemented the feature, and you take on a credential to manage.
- Maintaining one that uses roots? Move the paths into explicit tool parameters or configuration. Usually a small change, and it makes the real scope legible to whoever installs your server.
- Following a guide that uses either? Check which spec revision it targets. Both features were current before
2026-07-28.
Where to go next
- What replaced the request direction: MCP elicitation, the last client feature standing.
- The logging half of the same SEP: log to
stderrfor stdio transports and use OpenTelemetry for observability, which the revision notes set out alongside the rest. - The whole revision: MCP 2026-07-28 support and the spec version history.
The timeline is long. Nothing becomes eligible for removal before mid-2027, actual removal is a separate maintainer decision taken at release time, and no feature has been removed under this policy yet. What the status does tell you is which parts of MCP the maintainers have said not to build on.