SEP-2577: Deprecate Roots, Sampling, and Logging

Documentation Index

Fetch the complete documentation index at: https://modelcontextprotocol.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Abstract

• Roots (roots/list, notifications/roots/list_changed)
• Sampling (sampling/createMessage, ClientCapabilities.tasks.requests.sampling)
• Logging (logging/setLevel, notifications/message)

​

Motivation

​

Roots

• Low adoption: Few clients implement roots support, and few servers rely on it. The feature support matrix shows limited client coverage.
• Vague semantics: The specification describes roots as informational — servers are not required to respect them, which reduces their utility.
• Overlapping alternatives: Working directory context can be provided through tool parameters, resource URIs, server configuration, or environment variables — all of which are more explicit.

​

Sampling

• Complex to implement: Correct sampling implementation requires human-in-the-loop approval, model selection logic, security considerations, and (since SEP-1577) tool loop support. This complexity has contributed to low client adoption.
• Low adoption: The feature support matrix shows that few clients support sampling, despite the feature being available since the November 2024 specification.
• Direct alternatives: Servers that need LLM capabilities can integrate directly with LLM provider APIs, giving them full control over model selection, parameters, and streaming.

​

Logging

• Overlapping infrastructure: Standard logging mechanisms (stderr for stdio transports, OpenTelemetry for structured observability) are mature, widely adopted, and better suited to logging than an application-protocol channel.
• Low value relative to complexity: Adding log message types, severity levels, and the logging/setLevel request to the core specification increases the implementation surface for all clients and servers.

​

Specification

​

Overview of changes

1. Mark deprecated features with @deprecated annotations in the schema
2. Add deprecation notices to feature documentation pages
3. No wire-level protocol changes during the deprecation period

​

Schema changes

​

Deprecated capabilities

​

Deprecated types — Roots

​

Deprecated types — Sampling

​

Deprecated types — Logging

​

Annotation format

/**
 * Present if the client supports listing roots.
 *
 * @deprecated Deprecated as of this specification version. Will be included
 * in all versions released within one year, then may be removed.
 */
roots?: {
  listChanged?: boolean;
};

​

Union types

• ClientNotification (includes RootsListChangedNotification)
• ClientResult (includes CreateMessageResult, ListRootsResult)
• ServerRequest (includes CreateMessageRequest, ListRootsRequest)
• ServerNotification (includes LoggingMessageNotification)

​

Documentation changes

<Warning>
**Deprecated**: The Roots feature is deprecated as of this specification
version. It will remain fully functional in all specification versions released
within one year of the <YYYY-MM-DD> release. Each of those versions will
continue to support it for one year after its own release.
</Warning>

<Warning>
**Deprecated**: The Sampling feature is deprecated as of this specification
version. It will remain fully functional in all specification versions released
within one year of the <YYYY-MM-DD> release. Each of those versions will
continue to support it for one year after its own release.
</Warning>

<Warning>
**Deprecated**: The Logging feature is deprecated as of this specification
version. It will remain fully functional in all specification versions released
within one year of the <YYYY-MM-DD> release. Each of those versions will
continue to support it for one year after its own release.
</Warning>

​

Capability negotiation

• Clients and servers that support deprecated features SHOULD continue to declare the corresponding capabilities.
• Implementations that encounter deprecated capabilities MUST still handle them correctly.
• Implementations SHOULD emit a warning (e.g., in logs or developer tooling) when deprecated capabilities are negotiated.
• New implementations SHOULD NOT add support for deprecated features unless needed for backward compatibility with existing counterparts.

​

Timeline

• Deprecated: In the next specification release (currently planned for June 2026).
• Included in subsequent releases: All specification versions released within one year of this version’s release MUST continue to include these features as deprecated.
• Per-version support: Each version that includes these features will support them for one year after that version’s release, per the one-year-per-version support policy proposed in a separate SEP.
• Removal: Specification versions released more than one year after this version’s release MAY remove these features entirely.

​

Rationale

​

Why deprecate rather than move to extensions?

​

Why deprecate rather than remove immediately?

​

Why these three features specifically?

​

Backward Compatibility

• Implementations negotiating an older protocol version that includes these features will still have access to them through that version’s schema.
• Implementations negotiating a version that has removed these features will no longer have access to them.

​

Security Implications

• Sampling is the most security-sensitive of the three. It allows servers to request LLM completions through the client, which creates attack surface for prompt injection and data exfiltration. Removing it reduces this risk.
• Roots exposes information about the client’s filesystem to servers. Removing it reduces the risk of servers using root information to attempt directory traversal or access files outside intended boundaries.
• Logging has minimal security implications, but removing it simplifies the protocol surface area.

​

Reference Implementation