Skip to content

SEP-2577: Deprecate Roots, Sampling, and Logging #2577

Open
kurtisvg wants to merge 3 commits intomodelcontextprotocol:mainfrom
kurtisvg:sep-deprecate-roots-sampling-logging
Open

SEP-2577: Deprecate Roots, Sampling, and Logging #2577
kurtisvg wants to merge 3 commits intomodelcontextprotocol:mainfrom
kurtisvg:sep-deprecate-roots-sampling-logging

Conversation

@kurtisvg
Copy link
Copy Markdown
Contributor

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

Proposes deprecating three core protocol features (Roots, Sampling, and
Logging) with a migration window tied to the one-year-per-version support
policy. Features remain functional in all spec versions released within
one year of the deprecating version.
@kurtisvg kurtisvg force-pushed the sep-deprecate-roots-sampling-logging branch from 8f1868b to 38825e8 Compare April 15, 2026 02:18
@kurtisvg kurtisvg changed the title SEP-XXXX: Deprecate Roots, Sampling, and Logging SEP-2577: Deprecate Roots, Sampling, and Logging Apr 15, 2026
@kurtisvg kurtisvg self-assigned this Apr 15, 2026
Copy link
Copy Markdown
Contributor

@SamMorrowDrums SamMorrowDrums left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@localden localden added the SEP label Apr 15, 2026
@localden localden added the draft SEP proposal with a sponsor. label Apr 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

draft SEP proposal with a sponsor. SEP

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

3 participants