SEP-2577: Deprecate Roots, Sampling, and Logging - #2577
Conversation
8f1868b to
38825e8
Compare
There was a problem hiding this comment.
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.
|
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 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? |
68ff6cf to
48e34ab
Compare
48e34ab to
988df7b
Compare

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