SEP-2577: Deprecate Roots, Sampling, and Logging

[kurtisvg]

Summary

• Proposes deprecating three core protocol features: Roots, Sampling, and Logging
• Features remain fully functional in all spec versions released within one year of the deprecating version
• No wire-level protocol changes — deprecation is advisory only, signaling the ecosystem to plan for eventual removal

Motivation

These features were identified during a core contributor meeting as having low adoption relative to their implementation complexity:

• Roots: Vague semantics, overlaps with tool parameters and server configuration
• Sampling: Complex to implement (human-in-the-loop, model selection, security), low client adoption
• Logging: Overlaps with stderr and OpenTelemetry

[SamMorrowDrums]

I agree in principle with all of this, I see two challenges:

• servers can no longer use inference without either paying for it or finding a way to charge the user, doesn't change the decision but it matters.
• roots were one of the only concepts of server configuration in the protocol itself, I think it was not quite the right implementation but more broadly we need to seriously consider if there is some way of providing mutually understood configuration via MCP conceptually or not, related problems are configurations that change tool surface etc. if clients/gateways can't know a configuration impacts the server, then lots of things cannot be effectively monitored like "why are tools suddenly different", so just throwing it out there this is a step away from configuration being part of the protocol, and my open question is whether that's a directional choice or not. @tadasant @dsp-ant and I recently discussed this and @cliffhall and @chughtapan also considering it a lot, I think it also materially impacts whether primitive grouping would ever be an in-protocol concept or not.

No action needed, just wanted to state some possible consequences of merging this.

[PederHP]

I think doing some work to explore alternatives to sampling would be useful. As I've mentioned in relation to the interceptors proposal - the introduction of an llm/completion virtual method (as this is a very relevant context middleware target), indicates that model inference is still a relevant capability, even if sampling didn't turn out to have adoption.

It is possible that model invocation is out of scope of MCP, as there are other efforts to standardize LLM APIs, but even if so, then it might be worth exploring if there are ways to integrate with a standard that is seeing high adoption rates and using that to re-introduce the feature lost by removing sampling, and hopefully in a more symmetric way, where it is not necessarily only a client feature.

But I agree that sampling as it exists now adds a lot of complexity for a feature that has almost no adoption. It should be said that almost all of this complexity still exists in order to support elicitation which is not being deprecated. I am still in favor of deprecating sampling as it simply has too many gaps towards LLM APIs to be genuinely useful as "bring your own model" in practice. It is my hope it will eventually return in a more flexible and usable format - perhaps as a compatibility feature with an emerging model invocation standard.

[PederHP]

Why not include Prompts in this? The adoption of Prompts is also very limited and they have a lot of the same awkwardness as Sampling by not fully supporting LLM APIs: no system role, limited content type support, no way to specify tools/skills needed for a Prompt.

Skills are organically superseding Prompts as a mechanism to provide guidance on how to use an MCP Server - which in practice almost never happened anyway. I really haven't seen many servers ship with Prompts. To put it a little bluntly, the Prompts capability mostly serves as a source of confusion for models when they work with MCP right now.

[kziemski]

Why not include Prompts in this? The adoption of Prompts is also very limited and they have a lot of the same awkwardness as Sampling by not fully supporting LLM APIs: no system role, limited content type support, no way to specify tools/skills needed for a Prompt.

Skills are organically superseding Prompts as a mechanism to provide guidance on how to use an MCP Server - which in practice almost never happened anyway. I really haven't seen many servers ship with Prompts. To put it a little bluntly, the Prompts capability mostly serves as a source of confusion for models when they work with MCP right now.

So just tools, resources and mcp apps?
resources next to go?

[sep-automation-bot]

Maintainer Activity Check

Hi @kurtisvg!

You're assigned to this SEP but there hasn't been any activity from you in 19 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

---

This is an automated message from the SEP lifecycle bot.