MCP Roots, Sampling and Logging: migration paths after 2026-07-28 deprecation

What it is

Status as of 25 October 2026. Revision 2026-07-28 deprecates Roots, Sampling and Logging. Re-check their individual notices, the deprecated-features registry and the lifecycle policy before removing compatibility code. The registry lists their earliest removal as the first revision released on or after 2027-07-28. This is eligibility for a future specification change, not an automatic shutdown date.

Deprecated features remain in the specification. New implementations should avoid adopting them; existing implementations should migrate. SDK removal schedules are governed separately. The general policy also permits a documented expedited process for qualifying security risks, so the normal twelve-month window is not an unconditional promise for every circumstance.

Why it matters

The three features serve different purposes. Roots communicate relevant filesystem locations, Sampling delegates a model request to the client, and Logging delivers protocol log notifications. Replacing them can move responsibility between the client, server and operator. A migration that only removes capability flags can leave required work without an implementation.

Roots are explicitly informational: MCP does not enforce filesystem confinement. Sampling currently gives the client control over model access and permissions. Protocol Logging is distinct from the server's operational logs. Preserve those distinctions when choosing replacements.

How to apply

• Replace Roots with explicit context. The documented options are tool parameters, resource URIs or server configuration describing directories and files. Validate paths and permissions at the component accessing them. Preserve user consent and appropriate access controls; a supplied directory is not proof that the caller may read it. While retaining Roots in this revision, advertise the capability on each request and exchange roots/list through the input-request mechanism.
• Replace Sampling with direct provider integration. The specification recommends integrating directly with language-model provider APIs. Treat this as an ownership change, not a transparent rename: document which component obtains model access and which data it sends. The old Sampling interface provided client-side control and recommended human review. Preserve equivalent review where the application requires it, and test the refusal path. During transition, declare Sampling capabilities per request and avoid the deprecated cross-server context options.
• Move operational logging to an appropriate sink. The documented paths are stderr for stdio transports and OpenTelemetry for structured observability. Keep secrets and personal information out of log messages and control access to collected logs. If compatibility still requires protocol Logging, the server declares logging; clients request a level with io.modelcontextprotocol/logLevel in _meta.
• Test request-local logging. A server must not emit notifications/message when that request omitted the level. Allowed messages belong to that request's response stream, never the subscription stream. Verify that one client's verbosity selection cannot affect another client's request.
• Retire each dependency separately. As a proposed rollout procedure, inventory consumers, introduce the replacement, verify the same permitted workflow, and only then stop advertising the deprecated capability. Retain evidence of which clients still need it.

Pitfalls

Direct model integration does not automatically inherit the previous client's consent interface. A replacement logging sink does not automatically preserve redaction. A path parameter does not create a sandbox. Deprecation is the reason to plan these changes carefully, not permission to weaken their controls.