From 61452b13aa00e786a7eda621014f98353fff4d59 Mon Sep 17 00:00:00 2001 From: kpvangent <31518063+kurtisvg@users.noreply.github.com> Date: Tue, 14 Apr 2026 19:44:18 -0600 Subject: [PATCH 1/6] feat: add SEP to deprecate Roots, Sampling, and Logging 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. --- ...00-deprecate-roots-sampling-and-logging.md | 305 ++++++++++++++++++ 1 file changed, 305 insertions(+) create mode 100644 seps/0000-deprecate-roots-sampling-and-logging.md diff --git a/seps/0000-deprecate-roots-sampling-and-logging.md b/seps/0000-deprecate-roots-sampling-and-logging.md new file mode 100644 index 000000000..dc82ed3bd --- /dev/null +++ b/seps/0000-deprecate-roots-sampling-and-logging.md @@ -0,0 +1,305 @@ +# SEP-0000: Deprecate Roots, Sampling, and Logging + +- **Status**: Draft +- **Type**: Standards Track +- **Created**: 2026-04-14 +- **Author(s)**: Kurtis Van Gent (@kurtisvg) +- **Sponsor**: @kurtisvg +- **PR**: #0000 + +> **Note**: This SEP is predicated on a hypothetical SEP where MCP considers a +> specification version supported for one year past its original release date. +> The deprecation timeline described here assumes that policy is in place. + +## Abstract + +This SEP deprecates the following core protocol features: + +- **Roots** (`roots/list`, `notifications/roots/list_changed`) +- **Sampling** (`sampling/createMessage`, + `ClientCapabilities.tasks.requests.sampling`) +- **Logging** (`logging/setLevel`, `notifications/message`) + +These features are deprecated starting in the specification version that +includes this SEP (expected June 2026). They will continue to be fully +functional in all specification versions released within one year of that +version's release. + +Each of those subsequent versions will in turn support the features for one year +after its own release, assuming the one-year-per-version support policy proposed +in a separate SEP. This provides implementations with an extended migration +window before the features are fully removed. + +During the deprecation period, wire-level behavior is unchanged. No types are +removed, no capability negotiation changes, and no existing implementations +break. The deprecation serves as a signal to the ecosystem to stop building on +these features and to plan for their eventual removal. + +## Motivation + +The MCP specification aims to remain minimal and focused. Features that see low +adoption, overlap with existing alternatives, or impose disproportionate +implementation burden relative to their value are candidates for removal. +Keeping such features in the core specification increases the burden for every +client and server, slows protocol evolution, and makes the specification harder +to learn. The following three features meet these criteria. + +Deprecating these features was proposed during a recent core contributor +meeting. This SEP formalizes that proposal with a concrete implementation plan. +See [discussion #2536][discussion-2536]. + +### Roots + +Roots provides "informational guidance" about which directories or files a +server should operate on. In practice: + +- **Low adoption**: Few clients implement roots support, and few servers rely on + it. The [feature support matrix][feature-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 + +Sampling allows servers to request LLM completions from the client. While +conceptually powerful, it has struggled with adoption: + +- **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][feature-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 + +Logging allows servers to send structured log messages to clients via the +protocol: + +- **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. + +[discussion-2536]: https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2536 +[feature-matrix]: https://modelcontextprotocol.io/clients#feature-support-matrix + +## 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 + +Add `@deprecated` JSDoc annotations to the following items in +`schema/draft/schema.ts`. No types, interfaces, or union members are removed. + +#### Deprecated capabilities + +| Capability | Location | +| ----------------------------------------- | ---------------------------------------- | +| `ClientCapabilities.roots` | Client capability for listing roots | +| `ClientCapabilities.sampling` | Client capability for LLM sampling | +| `ClientCapabilities.tasks.requests.sampling` | Task-augmented sampling sub-capability | +| `ServerCapabilities.logging` | Server capability for log messages | + +#### Deprecated types — Roots + +| Type | Description | +| -------------------------------- | ------------------------------------------ | +| `Root` | Represents a root directory or file | +| `ListRootsRequest` | Server-to-client request for `roots/list` | +| `ListRootsResult` | Result containing roots array | +| `ListRootsResultResponse` | JSON-RPC response wrapper | +| `RootsListChangedNotification` | Client notification when roots change | + +#### Deprecated types — Sampling + +| Type | Description | +| -------------------------------- | ---------------------------------------------- | +| `CreateMessageRequestParams` | Parameters for `sampling/createMessage` | +| `CreateMessageRequest` | Server-to-client request for sampling | +| `CreateMessageResult` | Result from a sampling request | +| `CreateMessageResultResponse` | JSON-RPC response wrapper | +| `SamplingMessage` | A message in a sampling conversation | +| `SamplingMessageContentBlock` | Content block union for sampling messages | +| `ToolChoice` | Controls model tool selection during sampling | +| `ToolUseContent` | Tool use content block in sampling messages | +| `ToolResultContent` | Tool result content block in sampling messages | +| `ModelPreferences` | Server preferences for model selection | +| `ModelHint` | Hints for model selection | + +#### Deprecated types — Logging + +| Type | Description | +| ----------------------------------- | -------------------------------------- | +| `LoggingLevel` | Syslog severity level enum | +| `SetLevelRequestParams` | Parameters for `logging/setLevel` | +| `SetLevelRequest` | Client-to-server request to set level | +| `SetLevelResultResponse` | JSON-RPC response wrapper | +| `LoggingMessageNotificationParams` | Parameters for log message notification | +| `LoggingMessageNotification` | Server-to-client log message | + +#### Annotation format + +Each deprecated item SHOULD receive a JSDoc `@deprecated` tag with a brief +explanation: + +```typescript +/** + * 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 + +The following union types reference deprecated types but MUST NOT be modified +during the deprecation period. They will be updated when the deprecated types +are removed: + +- `ClientNotification` (includes `RootsListChangedNotification`) +- `ClientResult` (includes `CreateMessageResult`, `ListRootsResult`) +- `ServerRequest` (includes `CreateMessageRequest`, `ListRootsRequest`) +- `ServerNotification` (includes `LoggingMessageNotification`) + +### Documentation changes + +Add a deprecation warning block at the top of each feature's documentation page, +after the title: + +**`docs/specification/draft/client/roots.mdx`:** + +```mdx + +**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 release. Each of those versions will +continue to support it for one year after its own release. + +``` + +**`docs/specification/draft/client/sampling.mdx`:** + +```mdx + +**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 release. Each of those versions will +continue to support it for one year after its own release. + +``` + +**`docs/specification/draft/server/utilities/logging.mdx`:** + +```mdx + +**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 release. Each of those versions will +continue to support it for one year after its own release. + +``` + +### Capability negotiation + +During the deprecation period, capability negotiation is **unchanged**: + +- 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? + +These features are already implemented in many clients and servers. The +extensions mechanism (SEP-2133) specifies that unless an extension is provided, +implementations must behave as if the extension is not present. Retrofitting +this logic into existing SDKs — especially across multiple protocol versions — +would be complex and error-prone. Deprecation followed by removal is less +disruptive: implementations can continue using the features as-is during the +transition period, then simply stop when the features are removed. + +### Why deprecate rather than remove immediately? + +While adoption of these features is low, they are still in use. Removing them +immediately would cause unnecessary churn and disruption for users, client and +server owners, and SDK builders. A deprecation window minimizes this impact by +giving the ecosystem time to migrate at its own pace. + +### Why these three features specifically? + +These were identified during a core contributor meeting as the features with the +weakest adoption-to-complexity ratio. Each has viable alternatives outside the +protocol, and none are critical to the core resource/tool/prompt interaction +model that defines MCP. See [discussion #2536][discussion-2536]. + +## Backward Compatibility + +During the deprecation period, there are **no backward compatibility issues**. +All deprecated features continue to work identically. No wire-level changes are +introduced. + +After removal (in specification versions released more than one year after this +version): + +- 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 + +Deprecating these features has a **net positive** effect on security: + +- **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. + +No new security concerns are introduced by deprecation. + +## Reference Implementation + +No reference implementation is required. This SEP only marks existing +functionality as deprecated — no new protocol behavior is introduced. From 4845011ca4d9d07953de6c179051af58e093c7bc Mon Sep 17 00:00:00 2001 From: kpvangent <31518063+kurtisvg@users.noreply.github.com> Date: Tue, 14 Apr 2026 20:19:51 -0600 Subject: [PATCH 2/6] chore: format SEP with prettier --- ...00-deprecate-roots-sampling-and-logging.md | 64 +++++++++---------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/seps/0000-deprecate-roots-sampling-and-logging.md b/seps/0000-deprecate-roots-sampling-and-logging.md index dc82ed3bd..c72f2f17c 100644 --- a/seps/0000-deprecate-roots-sampling-and-logging.md +++ b/seps/0000-deprecate-roots-sampling-and-logging.md @@ -23,7 +23,7 @@ This SEP deprecates the following core protocol features: These features are deprecated starting in the specification version that includes this SEP (expected June 2026). They will continue to be fully functional in all specification versions released within one year of that -version's release. +version's release. Each of those subsequent versions will in turn support the features for one year after its own release, assuming the one-year-per-version support policy proposed @@ -108,49 +108,49 @@ Add `@deprecated` JSDoc annotations to the following items in #### Deprecated capabilities -| Capability | Location | -| ----------------------------------------- | ---------------------------------------- | -| `ClientCapabilities.roots` | Client capability for listing roots | -| `ClientCapabilities.sampling` | Client capability for LLM sampling | +| Capability | Location | +| -------------------------------------------- | -------------------------------------- | +| `ClientCapabilities.roots` | Client capability for listing roots | +| `ClientCapabilities.sampling` | Client capability for LLM sampling | | `ClientCapabilities.tasks.requests.sampling` | Task-augmented sampling sub-capability | -| `ServerCapabilities.logging` | Server capability for log messages | +| `ServerCapabilities.logging` | Server capability for log messages | #### Deprecated types — Roots -| Type | Description | -| -------------------------------- | ------------------------------------------ | -| `Root` | Represents a root directory or file | -| `ListRootsRequest` | Server-to-client request for `roots/list` | -| `ListRootsResult` | Result containing roots array | -| `ListRootsResultResponse` | JSON-RPC response wrapper | -| `RootsListChangedNotification` | Client notification when roots change | +| Type | Description | +| ------------------------------ | ----------------------------------------- | +| `Root` | Represents a root directory or file | +| `ListRootsRequest` | Server-to-client request for `roots/list` | +| `ListRootsResult` | Result containing roots array | +| `ListRootsResultResponse` | JSON-RPC response wrapper | +| `RootsListChangedNotification` | Client notification when roots change | #### Deprecated types — Sampling -| Type | Description | -| -------------------------------- | ---------------------------------------------- | -| `CreateMessageRequestParams` | Parameters for `sampling/createMessage` | -| `CreateMessageRequest` | Server-to-client request for sampling | -| `CreateMessageResult` | Result from a sampling request | -| `CreateMessageResultResponse` | JSON-RPC response wrapper | -| `SamplingMessage` | A message in a sampling conversation | -| `SamplingMessageContentBlock` | Content block union for sampling messages | -| `ToolChoice` | Controls model tool selection during sampling | -| `ToolUseContent` | Tool use content block in sampling messages | -| `ToolResultContent` | Tool result content block in sampling messages | -| `ModelPreferences` | Server preferences for model selection | -| `ModelHint` | Hints for model selection | +| Type | Description | +| ----------------------------- | ---------------------------------------------- | +| `CreateMessageRequestParams` | Parameters for `sampling/createMessage` | +| `CreateMessageRequest` | Server-to-client request for sampling | +| `CreateMessageResult` | Result from a sampling request | +| `CreateMessageResultResponse` | JSON-RPC response wrapper | +| `SamplingMessage` | A message in a sampling conversation | +| `SamplingMessageContentBlock` | Content block union for sampling messages | +| `ToolChoice` | Controls model tool selection during sampling | +| `ToolUseContent` | Tool use content block in sampling messages | +| `ToolResultContent` | Tool result content block in sampling messages | +| `ModelPreferences` | Server preferences for model selection | +| `ModelHint` | Hints for model selection | #### Deprecated types — Logging -| Type | Description | -| ----------------------------------- | -------------------------------------- | -| `LoggingLevel` | Syslog severity level enum | -| `SetLevelRequestParams` | Parameters for `logging/setLevel` | +| Type | Description | +| ---------------------------------- | --------------------------------------- | +| `LoggingLevel` | Syslog severity level enum | +| `SetLevelRequestParams` | Parameters for `logging/setLevel` | | `SetLevelRequest` | Client-to-server request to set level | -| `SetLevelResultResponse` | JSON-RPC response wrapper | +| `SetLevelResultResponse` | JSON-RPC response wrapper | | `LoggingMessageNotificationParams` | Parameters for log message notification | -| `LoggingMessageNotification` | Server-to-client log message | +| `LoggingMessageNotification` | Server-to-client log message | #### Annotation format From 57001f67cecb9d1dd43e6670127c7a471d1d81e7 Mon Sep 17 00:00:00 2001 From: kpvangent <31518063+kurtisvg@users.noreply.github.com> Date: Tue, 14 Apr 2026 20:51:12 -0600 Subject: [PATCH 3/6] chore: rename SEP to #2577 and update references --- ...ogging.md => 2577-deprecate-roots-sampling-and-logging.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename seps/{0000-deprecate-roots-sampling-and-logging.md => 2577-deprecate-roots-sampling-and-logging.md} (99%) diff --git a/seps/0000-deprecate-roots-sampling-and-logging.md b/seps/2577-deprecate-roots-sampling-and-logging.md similarity index 99% rename from seps/0000-deprecate-roots-sampling-and-logging.md rename to seps/2577-deprecate-roots-sampling-and-logging.md index c72f2f17c..356f91850 100644 --- a/seps/0000-deprecate-roots-sampling-and-logging.md +++ b/seps/2577-deprecate-roots-sampling-and-logging.md @@ -1,11 +1,11 @@ -# SEP-0000: Deprecate Roots, Sampling, and Logging +# SEP-2577: Deprecate Roots, Sampling, and Logging - **Status**: Draft - **Type**: Standards Track - **Created**: 2026-04-14 - **Author(s)**: Kurtis Van Gent (@kurtisvg) - **Sponsor**: @kurtisvg -- **PR**: #0000 +- **PR**: #2577 > **Note**: This SEP is predicated on a hypothetical SEP where MCP considers a > specification version supported for one year past its original release date. From 90a794442448530e0b48bdfa0262ce5204fc2046 Mon Sep 17 00:00:00 2001 From: kurtisvg <31518063+kurtisvg@users.noreply.github.com> Date: Fri, 15 May 2026 11:47:10 -0600 Subject: [PATCH 4/6] docs(sep-2577): add deprecation notices to Roots, Sampling, and Logging spec pages --- docs/docs.json | 1 + ...7-deprecate-roots-sampling-and-logging.mdx | 320 ++++++++++++++++++ docs/seps/index.mdx | 13 +- docs/specification/draft/changelog.mdx | 5 + docs/specification/draft/client/roots.mdx | 8 + docs/specification/draft/client/sampling.mdx | 8 + .../draft/server/utilities/logging.mdx | 8 + 7 files changed, 357 insertions(+), 6 deletions(-) create mode 100644 docs/seps/2577-deprecate-roots-sampling-and-logging.mdx diff --git a/docs/docs.json b/docs/docs.json index 82d7a19e2..d099ec779 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -430,6 +430,7 @@ "seps/2243-http-standardization", "seps/2260-Require-Server-requests-to-be-associated-with-Client-requests", "seps/2567-sessionless-mcp", + "seps/2577-deprecate-roots-sampling-and-logging", "seps/2663-tasks-extension" ] }, diff --git a/docs/seps/2577-deprecate-roots-sampling-and-logging.mdx b/docs/seps/2577-deprecate-roots-sampling-and-logging.mdx new file mode 100644 index 000000000..7fd0db190 --- /dev/null +++ b/docs/seps/2577-deprecate-roots-sampling-and-logging.mdx @@ -0,0 +1,320 @@ +--- +title: "SEP-2577: Deprecate Roots, Sampling, and Logging" +sidebarTitle: "SEP-2577: Deprecate Roots, Sampling, and Logging" +description: "Deprecate Roots, Sampling, and Logging" +--- + +
+ + Draft + + + Standards Track + +
+ +| Field | Value | +| ------------- | ------------------------------------------------------------------------------- | +| **SEP** | 2577 | +| **Title** | Deprecate Roots, Sampling, and Logging | +| **Status** | Draft | +| **Type** | Standards Track | +| **Created** | 2026-04-14 | +| **Author(s)** | Kurtis Van Gent ([@kurtisvg](https://github.com/kurtisvg)) | +| **Sponsor** | [@kurtisvg](https://github.com/kurtisvg) | +| **PR** | [#2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) | + +--- + +## Abstract + +This SEP deprecates the following core protocol features: + +- **Roots** (`roots/list`, `notifications/roots/list_changed`) +- **Sampling** (`sampling/createMessage`, + `ClientCapabilities.tasks.requests.sampling`) +- **Logging** (`logging/setLevel`, `notifications/message`) + +These features are deprecated starting in the specification version that +includes this SEP (expected June 2026). They will continue to be fully +functional in all specification versions released within one year of that +version's release. + +Each of those subsequent versions will in turn support the features for one year +after its own release, assuming the one-year-per-version support policy proposed +in a separate SEP. This provides implementations with an extended migration +window before the features are fully removed. + +During the deprecation period, wire-level behavior is unchanged. No types are +removed, no capability negotiation changes, and no existing implementations +break. The deprecation serves as a signal to the ecosystem to stop building on +these features and to plan for their eventual removal. + +## Motivation + +The MCP specification aims to remain minimal and focused. Features that see low +adoption, overlap with existing alternatives, or impose disproportionate +implementation burden relative to their value are candidates for removal. +Keeping such features in the core specification increases the burden for every +client and server, slows protocol evolution, and makes the specification harder +to learn. The following three features meet these criteria. + +Deprecating these features was proposed during a recent core contributor +meeting. This SEP formalizes that proposal with a concrete implementation plan. +See [discussion #2536][discussion-2536]. + +### Roots + +Roots provides "informational guidance" about which directories or files a +server should operate on. In practice: + +- **Low adoption**: Few clients implement roots support, and few servers rely on + it. The [feature support matrix][feature-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 + +Sampling allows servers to request LLM completions from the client. While +conceptually powerful, it has struggled with adoption: + +- **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][feature-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 + +Logging allows servers to send structured log messages to clients via the +protocol: + +- **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. + +[discussion-2536]: https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2536 +[feature-matrix]: https://modelcontextprotocol.io/clients#feature-support-matrix + +## 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 + +Add `@deprecated` JSDoc annotations to the following items in +`schema/draft/schema.ts`. No types, interfaces, or union members are removed. + +#### Deprecated capabilities + +| Capability | Location | +| -------------------------------------------- | -------------------------------------- | +| `ClientCapabilities.roots` | Client capability for listing roots | +| `ClientCapabilities.sampling` | Client capability for LLM sampling | +| `ClientCapabilities.tasks.requests.sampling` | Task-augmented sampling sub-capability | +| `ServerCapabilities.logging` | Server capability for log messages | + +#### Deprecated types — Roots + +| Type | Description | +| ------------------------------ | ----------------------------------------- | +| `Root` | Represents a root directory or file | +| `ListRootsRequest` | Server-to-client request for `roots/list` | +| `ListRootsResult` | Result containing roots array | +| `ListRootsResultResponse` | JSON-RPC response wrapper | +| `RootsListChangedNotification` | Client notification when roots change | + +#### Deprecated types — Sampling + +| Type | Description | +| ----------------------------- | ---------------------------------------------- | +| `CreateMessageRequestParams` | Parameters for `sampling/createMessage` | +| `CreateMessageRequest` | Server-to-client request for sampling | +| `CreateMessageResult` | Result from a sampling request | +| `CreateMessageResultResponse` | JSON-RPC response wrapper | +| `SamplingMessage` | A message in a sampling conversation | +| `SamplingMessageContentBlock` | Content block union for sampling messages | +| `ToolChoice` | Controls model tool selection during sampling | +| `ToolUseContent` | Tool use content block in sampling messages | +| `ToolResultContent` | Tool result content block in sampling messages | +| `ModelPreferences` | Server preferences for model selection | +| `ModelHint` | Hints for model selection | + +#### Deprecated types — Logging + +| Type | Description | +| ---------------------------------- | --------------------------------------- | +| `LoggingLevel` | Syslog severity level enum | +| `SetLevelRequestParams` | Parameters for `logging/setLevel` | +| `SetLevelRequest` | Client-to-server request to set level | +| `SetLevelResultResponse` | JSON-RPC response wrapper | +| `LoggingMessageNotificationParams` | Parameters for log message notification | +| `LoggingMessageNotification` | Server-to-client log message | + +#### Annotation format + +Each deprecated item SHOULD receive a JSDoc `@deprecated` tag with a brief +explanation: + +```typescript +/** + * 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 + +The following union types reference deprecated types but MUST NOT be modified +during the deprecation period. They will be updated when the deprecated types +are removed: + +- `ClientNotification` (includes `RootsListChangedNotification`) +- `ClientResult` (includes `CreateMessageResult`, `ListRootsResult`) +- `ServerRequest` (includes `CreateMessageRequest`, `ListRootsRequest`) +- `ServerNotification` (includes `LoggingMessageNotification`) + +### Documentation changes + +Add a deprecation warning block at the top of each feature's documentation page, +after the title: + +**`docs/specification/draft/client/roots.mdx`:** + +```mdx + +**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 release. Each of those versions will +continue to support it for one year after its own release. + +``` + +**`docs/specification/draft/client/sampling.mdx`:** + +```mdx + +**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 release. Each of those versions will +continue to support it for one year after its own release. + +``` + +**`docs/specification/draft/server/utilities/logging.mdx`:** + +```mdx + +**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 release. Each of those versions will +continue to support it for one year after its own release. + +``` + +### Capability negotiation + +During the deprecation period, capability negotiation is **unchanged**: + +- 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? + +These features are already implemented in many clients and servers. The +extensions mechanism (SEP-2133) specifies that unless an extension is provided, +implementations must behave as if the extension is not present. Retrofitting +this logic into existing SDKs — especially across multiple protocol versions — +would be complex and error-prone. Deprecation followed by removal is less +disruptive: implementations can continue using the features as-is during the +transition period, then simply stop when the features are removed. + +### Why deprecate rather than remove immediately? + +While adoption of these features is low, they are still in use. Removing them +immediately would cause unnecessary churn and disruption for users, client and +server owners, and SDK builders. A deprecation window minimizes this impact by +giving the ecosystem time to migrate at its own pace. + +### Why these three features specifically? + +These were identified during a core contributor meeting as the features with the +weakest adoption-to-complexity ratio. Each has viable alternatives outside the +protocol, and none are critical to the core resource/tool/prompt interaction +model that defines MCP. See [discussion #2536][discussion-2536]. + +## Backward Compatibility + +During the deprecation period, there are **no backward compatibility issues**. +All deprecated features continue to work identically. No wire-level changes are +introduced. + +After removal (in specification versions released more than one year after this +version): + +- 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 + +Deprecating these features has a **net positive** effect on security: + +- **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. + +No new security concerns are introduced by deprecation. + +## Reference Implementation + +No reference implementation is required. This SEP only marks existing +functionality as deprecated — no new protocol behavior is introduced. diff --git a/docs/seps/index.mdx b/docs/seps/index.mdx index 47782bf67..9d0e736d6 100644 --- a/docs/seps/index.mdx +++ b/docs/seps/index.mdx @@ -12,19 +12,20 @@ Specification Enhancement Proposals (SEPs) are the primary mechanism for proposi ## Summary -- **Final**: 31 -- **Accepted**: 4 +- **Draft**: 1 +- **Accepted**: 3 +- **Final**: 29 +- **Approved**: 1 ## All SEPs | SEP | Title | Status | Type | Created | | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | ------------------------------------------------- | ---------------- | ---------- | -| [SEP-2663](/seps/2663-tasks-extension) | Tasks Extension | Final | Extensions Track | 2026-04-27 | +| [SEP-2577](/seps/2577-deprecate-roots-sampling-and-logging) | Deprecate Roots, Sampling, and Logging | Draft | Standards Track | 2026-04-14 | | [SEP-2575](/seps/2575-stateless-mcp) | Make MCP Stateless | Accepted | Standards Track | 2025-06-18 | | [SEP-2567](/seps/2567-sessionless-mcp) | Sessionless MCP via Explicit State Handles | Final | Standards Track | 2026-03-11 | -| [SEP-2549](/seps/2549-TTL-for-list-results) | TTL for List Results | Accepted | Standards Track | 2026-04-09 | -| [SEP-2322](/seps/2322-MRTR) | Multi Round-Trip Requests | Accepted | Standards Track | 2026-02-03 | -| [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests) | Require Server requests to be associated with a Client request. | Final | Standards Track | 2026-02-16 | +| [SEP-2322](/seps/2322-MRTR) | Multi Round-Trip Requests | Approved | Standards Track | 2026-02-03 | +| [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests) | Require Server requests to be associated with a Client request. | Accepted | Standards Track | 2026-02-16 | | [SEP-2243](/seps/2243-http-standardization) | HTTP Header Standardization for Streamable HTTP Transport | Final | Standards Track | 2026-02-04 | | [SEP-2207](/seps/2207-oidc-refresh-token-guidance) | OIDC-Flavored Refresh Token Guidance | Accepted | Standards Track | 2026-02-04 | | [SEP-2149](/seps/2149-working-group-charter-template) | MCP Group Governance and Charter Template | Final | Process | 2025-01-15 | diff --git a/docs/specification/draft/changelog.mdx b/docs/specification/draft/changelog.mdx index 5e468e755..91eeb3ddb 100644 --- a/docs/specification/draft/changelog.mdx +++ b/docs/specification/draft/changelog.mdx @@ -23,6 +23,11 @@ the previous revision, [2025-11-25](/specification/2025-11-25). 7. Multi Round-Trip Requests (MRTR) pattern introduced which replaces the previous approach of sending server-initiated requests, such as `roots/list`, `sampling/createMessage`, or `elicitation/create`. Servers return `inputRequests`, a new resultType containing the additional information needed to process the request. Clients respond with `inputResponses` on the next request providing the requested information. ([SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322)). +8. Deprecate the Roots, Sampling, and Logging features + ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)). + These features remain fully functional during the deprecation window but new + implementations should not add support for them. + ## Minor changes 1. Add `extensions` field to `ClientCapabilities` and `ServerCapabilities` to support optional [extensions](/docs/extensions/overview) beyond the core protocol. diff --git a/docs/specification/draft/client/roots.mdx b/docs/specification/draft/client/roots.mdx index bcf4b21a9..f96849205 100644 --- a/docs/specification/draft/client/roots.mdx +++ b/docs/specification/draft/client/roots.mdx @@ -4,6 +4,14 @@ title: Roots
+ + **Deprecated**: The Roots feature is deprecated as of protocol version + `DRAFT-2026-v1`. It will continue to be supported in any version of MCP + released within 1 year of `DRAFT-2026-v1`, according to the deprecation policy + outlined in + [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596). + + The Model Context Protocol (MCP) provides a standardized way for clients to expose filesystem "roots" to servers. Roots inform servers about the directories and files the client considers relevant, so that servers can focus their operations accordingly. They diff --git a/docs/specification/draft/client/sampling.mdx b/docs/specification/draft/client/sampling.mdx index f75383c7e..7eb4818d4 100644 --- a/docs/specification/draft/client/sampling.mdx +++ b/docs/specification/draft/client/sampling.mdx @@ -4,6 +4,14 @@ title: Sampling
+ + **Deprecated**: The Sampling feature is deprecated as of protocol version + `DRAFT-2026-v1`. It will continue to be supported in any version of MCP + released within 1 year of `DRAFT-2026-v1`, according to the deprecation policy + outlined in + [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596). + + The Model Context Protocol (MCP) provides a standardized way for servers to request LLM sampling ("completions" or "generations") from language models via clients. This flow allows clients to maintain control over model access, selection, and permissions while diff --git a/docs/specification/draft/server/utilities/logging.mdx b/docs/specification/draft/server/utilities/logging.mdx index 636953f4a..7b42ed916 100644 --- a/docs/specification/draft/server/utilities/logging.mdx +++ b/docs/specification/draft/server/utilities/logging.mdx @@ -4,6 +4,14 @@ title: Logging
+ + **Deprecated**: The Logging feature is deprecated as of protocol version + `DRAFT-2026-v1`. It will continue to be supported in any version of MCP + released within 1 year of `DRAFT-2026-v1`, according to the deprecation policy + outlined in + [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596). + + The Model Context Protocol (MCP) provides a standardized way for servers to send structured log messages to clients. Clients control logging verbosity per-request via `_meta`, with servers sending notifications containing severity levels, optional logger From 6b6292358593f0ae34582e9f91a6562f045d786a Mon Sep 17 00:00:00 2001 From: kurtisvg <31518063+kurtisvg@users.noreply.github.com> Date: Fri, 15 May 2026 12:00:45 -0600 Subject: [PATCH 5/6] chore: regenerate SEP index after rebase --- docs/seps/index.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/seps/index.mdx b/docs/seps/index.mdx index 9d0e736d6..a6363c81d 100644 --- a/docs/seps/index.mdx +++ b/docs/seps/index.mdx @@ -13,7 +13,7 @@ Specification Enhancement Proposals (SEPs) are the primary mechanism for proposi ## Summary - **Draft**: 1 -- **Accepted**: 3 +- **Accepted**: 4 - **Final**: 29 - **Approved**: 1 @@ -24,6 +24,7 @@ Specification Enhancement Proposals (SEPs) are the primary mechanism for proposi | [SEP-2577](/seps/2577-deprecate-roots-sampling-and-logging) | Deprecate Roots, Sampling, and Logging | Draft | Standards Track | 2026-04-14 | | [SEP-2575](/seps/2575-stateless-mcp) | Make MCP Stateless | Accepted | Standards Track | 2025-06-18 | | [SEP-2567](/seps/2567-sessionless-mcp) | Sessionless MCP via Explicit State Handles | Final | Standards Track | 2026-03-11 | +| [SEP-2549](/seps/2549-TTL-for-list-results) | TTL for List Results | Accepted | Standards Track | 2026-04-09 | | [SEP-2322](/seps/2322-MRTR) | Multi Round-Trip Requests | Approved | Standards Track | 2026-02-03 | | [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests) | Require Server requests to be associated with a Client request. | Accepted | Standards Track | 2026-02-16 | | [SEP-2243](/seps/2243-http-standardization) | HTTP Header Standardization for Streamable HTTP Transport | Final | Standards Track | 2026-02-04 | From e3514f77ff173cf4320a8a756be4f1aa9abc920b Mon Sep 17 00:00:00 2001 From: kurtisvg <31518063+kurtisvg@users.noreply.github.com> Date: Fri, 15 May 2026 12:01:41 -0600 Subject: [PATCH 6/6] chore: promote SEP-2577 to Final --- .../2577-deprecate-roots-sampling-and-logging.mdx | 6 +++--- docs/seps/index.mdx | 11 +++++------ seps/2577-deprecate-roots-sampling-and-logging.md | 2 +- 3 files changed, 9 insertions(+), 10 deletions(-) diff --git a/docs/seps/2577-deprecate-roots-sampling-and-logging.mdx b/docs/seps/2577-deprecate-roots-sampling-and-logging.mdx index 7fd0db190..6d87fa412 100644 --- a/docs/seps/2577-deprecate-roots-sampling-and-logging.mdx +++ b/docs/seps/2577-deprecate-roots-sampling-and-logging.mdx @@ -5,8 +5,8 @@ description: "Deprecate Roots, Sampling, and Logging" ---
- - Draft + + Final Standards Track @@ -17,7 +17,7 @@ description: "Deprecate Roots, Sampling, and Logging" | ------------- | ------------------------------------------------------------------------------- | | **SEP** | 2577 | | **Title** | Deprecate Roots, Sampling, and Logging | -| **Status** | Draft | +| **Status** | Final | | **Type** | Standards Track | | **Created** | 2026-04-14 | | **Author(s)** | Kurtis Van Gent ([@kurtisvg](https://github.com/kurtisvg)) | diff --git a/docs/seps/index.mdx b/docs/seps/index.mdx index a6363c81d..7234aa59e 100644 --- a/docs/seps/index.mdx +++ b/docs/seps/index.mdx @@ -12,21 +12,20 @@ Specification Enhancement Proposals (SEPs) are the primary mechanism for proposi ## Summary -- **Draft**: 1 +- **Final**: 32 - **Accepted**: 4 -- **Final**: 29 -- **Approved**: 1 ## All SEPs | SEP | Title | Status | Type | Created | | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | ------------------------------------------------- | ---------------- | ---------- | -| [SEP-2577](/seps/2577-deprecate-roots-sampling-and-logging) | Deprecate Roots, Sampling, and Logging | Draft | Standards Track | 2026-04-14 | +| [SEP-2663](/seps/2663-tasks-extension) | Tasks Extension | Final | Extensions Track | 2026-04-27 | +| [SEP-2577](/seps/2577-deprecate-roots-sampling-and-logging) | Deprecate Roots, Sampling, and Logging | Final | Standards Track | 2026-04-14 | | [SEP-2575](/seps/2575-stateless-mcp) | Make MCP Stateless | Accepted | Standards Track | 2025-06-18 | | [SEP-2567](/seps/2567-sessionless-mcp) | Sessionless MCP via Explicit State Handles | Final | Standards Track | 2026-03-11 | | [SEP-2549](/seps/2549-TTL-for-list-results) | TTL for List Results | Accepted | Standards Track | 2026-04-09 | -| [SEP-2322](/seps/2322-MRTR) | Multi Round-Trip Requests | Approved | Standards Track | 2026-02-03 | -| [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests) | Require Server requests to be associated with a Client request. | Accepted | Standards Track | 2026-02-16 | +| [SEP-2322](/seps/2322-MRTR) | Multi Round-Trip Requests | Accepted | Standards Track | 2026-02-03 | +| [SEP-2260](/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests) | Require Server requests to be associated with a Client request. | Final | Standards Track | 2026-02-16 | | [SEP-2243](/seps/2243-http-standardization) | HTTP Header Standardization for Streamable HTTP Transport | Final | Standards Track | 2026-02-04 | | [SEP-2207](/seps/2207-oidc-refresh-token-guidance) | OIDC-Flavored Refresh Token Guidance | Accepted | Standards Track | 2026-02-04 | | [SEP-2149](/seps/2149-working-group-charter-template) | MCP Group Governance and Charter Template | Final | Process | 2025-01-15 | diff --git a/seps/2577-deprecate-roots-sampling-and-logging.md b/seps/2577-deprecate-roots-sampling-and-logging.md index 356f91850..3efd9b522 100644 --- a/seps/2577-deprecate-roots-sampling-and-logging.md +++ b/seps/2577-deprecate-roots-sampling-and-logging.md @@ -1,6 +1,6 @@ # SEP-2577: Deprecate Roots, Sampling, and Logging -- **Status**: Draft +- **Status**: Final - **Type**: Standards Track - **Created**: 2026-04-14 - **Author(s)**: Kurtis Van Gent (@kurtisvg)