MCP Sampling, Roots and Logging deprecated: migrate before July 2027

Summary. The Model Context Protocol (MCP) deprecated Roots, Sampling and Logging under SEP-2577 in its 2026-07-28 revision, released on 28 July 2026. Each becomes eligible for removal only in the first revision released on or after 28 July 2027, and removal is then a Core Maintainer decision, not an automatic event. The same revision deprecated OAuth Dynamic Client Registration in favour of Client ID Metadata Documents, and reclassified the HTTP+SSE transport and two includeContext values as Deprecated. With releases now planned for March and September from March 2027, September 2027 is the first release that could drop the three features; HTTP+SSE could go in March. The replacements are tool parameters, resource URIs or server configuration for Roots, direct LLM provider APIs for Sampling, and stderr plus OpenTelemetry for Logging. Our verdict: do this work while you port to 2026-07-28, which already rebuilt Sampling and Roots on InputRequiredResult; budget keys and tokens for any server-side model call; and keep client support for older servers until a removal is confirmed.

About this article. For engineers who build or run MCP servers, clients and hosts. On 7 November 2026 we checked every claim against the 2026-07-28 specification pages, changelog and deprecated-features registry on modelcontextprotocol.io, and against the SEP files, pull requests, release tags and maintainer meeting notes in the official GitHub repository. For the data-protection section we read the Digital Personal Data Protection Act, 2023 as published in the Gazette of India on 11 August 2023, and the GDPR text on EUR-Lex; that section is general information, not legal advice. The specification changes with each revision, so re-check the registry before you plan a release. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What the 2026-07-28 specification deprecated

The deprecated-features registry is the page to bookmark; the lifecycle policy calls it the one place that answers what is leaving and when. The registry describes itself as a derived view: the normative records are the deprecation notices on each feature page and the revision changelog. On 7 November 2026 the versioning page still lists 2026-07-28 as Current, and the draft registry shows the same six entries with an empty Removed section.

Two rows need explanation. Dynamic Client Registration was deprecated in PR 2858, merged on 4 June 2026, a pull request that split the authorisation specification into smaller pages rather than a SEP of its own.

The HTTP+SSE clock depends on when SEP-2596 reached Final. Its pull request was merged on 18 May 2026 while labelled accepted, and the SEP was marked Final on 3 June 2026. So HTTP+SSE has been eligible for removal since 3 September 2026. It is still listed because removal happens only when Core Maintainers decide it during release preparation, and no revision has shipped since 28 July. The release blog post for 2026-07-28 speaks of a year-long offramp for HTTP+SSE, but the registry, the Streamable HTTP deprecation notice and SEP-2596 set the shorter clock.

What earliest removal actually means

SEP-2596 created the feature lifecycle policy in the same release cycle. It defines three states, Active, Deprecated and Removed, and a few rules that decide your real deadline:

• Twelve months minimum. A deprecation SEP must set a window of at least twelve months, counted from the release of the revision that first marks the feature Deprecated, not from the date the SEP reached Final.

• Removal needs a release. A feature becomes eligible only in the first revision released as Current on or after the window ends. No new Current revision, no removal.

• Removal is a decision. Core Maintainers carry out removals at their discretion during release preparation and record them in the changelog and registry. A feature can stay Deprecated well beyond the minimum. The removal itself needs no new SEP; a SEP is needed only to extend, shorten or reverse the timeline.

• Security can shorten it. Expedited removal needs a published advisory or documented exploitation with no in-place mitigation, plus Core Maintainer approval recorded in a SEP. Even then at least ninety days must separate deprecation from earliest removal.

• Deprecation can be reversed. A later SEP can restore a feature to Active; a second deprecation restarts the twelve-month clock.

• SDKs keep their own clock. Removal from the specification does not force an SDK to drop the feature.

SEP-2577 promised more on paper: that each revision released within a year would also support the features for a year after its own release. That rested on a revision-support policy which SEP-2596 still lists as an open question, so treat the twelve-month floor as the only firm commitment.

Tier 1 SDKs, the fully supported ones that cover optional capabilities such as sampling and elicitation, must mark the affected API deprecated in their next release once the revision is Current, using @Deprecated in Java, [Obsolete] in .NET, @deprecated JSDoc in TypeScript or the Deprecated: convention in Go, and should emit a runtime warning when the feature is used. Expect those warnings after a Tier 1 SDK upgrade.

Dates come from the GitHub records, the registry and maintainer meeting notes.

At their 15 September 2026 meeting the Core Maintainers moved the next release to March 2027, replacing a 15 December date set in August, with releases every March and September after that. A March 2027 revision falls inside the window, so it must keep Roots, Sampling, Logging and DCR; if the plan holds, September 2027 is the first release that may remove them. Planned dates can slip, and the maintainers noted that the previous release slipped by about a month. The ninety-day floor has passed, so an expedited removal is now possible in principle, but only under the security conditions above.

Why these three, and who objected

SEP-2577 is short. It says a core contributor meeting picked the three features for low adoption relative to the effort of implementing them. Roots has loose semantics that overlap with tool parameters and server configuration. Sampling is hard to implement well, because of human approval, model selection and security, and few clients support it. Logging duplicates stderr and OpenTelemetry. The SEP adds that dropping Sampling shrinks the surface for prompt injection and data exfiltration.

The pull request thread shows the costs:

• The developer of pdflens-mcp wrote in September 2026 that the server had lost auto-approved PDF reading and asked for a migration path, while accepting that roots were never access control; the Roots page calls them informational guidance.

• An approving reviewer noted that servers now have to pay for inference or bill users for it, and that roots were one of the few notions of server configuration inside the protocol.

• A participant argued that many open-source servers and MCP Apps have no LLM backend, and proposed a user-approved way for tools to ask the host's AI for help.

• The SEP's author replied that deprecation does not rule out a return, and that an improved Sampling would best be trialled first as an experimental extension.

• One project member suggested deprecating Prompts too, and later called Resources and Elicitation strong parts of MCP. As of 7 November 2026 no pull request proposes deprecating Prompts.

Treat a future Sampling extension as possible, not planned.

These features already changed on the wire in 2026-07-28

SEP-2577 itself changed no messages. The rest of the 2026-07-28 revision did: it made MCP stateless, removed the initialize handshake and introduced Multi Round-Trip Requests, so servers no longer send JSON-RPC requests to clients at all. Supporting the deprecated features now means maintaining a new implementation of them. The table compares the 2025-11-25 and 2026-07-28 feature pages.

The current Sampling page still says a human should be able to deny any sampling request, and treats server model preferences as hints: the client makes the final model choice. The Logging page says a server must not emit notifications/message for a request that did not carry the log-level field, so a server ported naively from 2025-11-25 can end up with no logs the client ever sees.

Not yet on 2026-07-28? Do the deprecation migration in the same piece of work. Rebuilding Sampling and Roots on InputRequiredResult, only to delete them a year later, is the most expensive path. Our 2026-07-28 migration guide covers the rest of the stateless changes.

Migration guide for MCP server builders

Replacing Sampling

The specification's answer is to integrate directly with LLM provider APIs. Two patterns cover most cases.

1. Return data and let the host's model reason. Much Sampling use was a tool asking the client's model to summarise or classify something the tool had just fetched. Return that material as tool output, using structuredContent where a schema helps, and let the calling agent's model do the reasoning. No keys, no token bill.

1. Own the model call. When the server really needs inference mid-operation, such as agent loops that used sampling.tools, call a provider from the server. Sampling needed no server API keys; now you need credentials, a model choice the client used to make, rate limiting, retries and a token budget.

Do not lose the human-in-the-loop guarantee by accident. Under Sampling, the client could show the user the prompt and the response first. If your server now calls a model on its own, decide where approval lives: return a draft for the host to confirm, or use Elicitation, which is not deprecated, to ask the user.

Replacing Roots

Replace Roots with inputs the server validates itself:

• Tool parameters for per-call paths.

• Resource URIs when the client should choose files from a list the server exposes.

• Server configuration for the allowed workspace, set at launch for stdio servers or per deployment for remote ones.

            {
  "name": "read_pdf",
  "description": "Extract text from a PDF inside an allowed workspace directory",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "Absolute path to a PDF under a directory allowed in server configuration"
      }
    },
    "required": ["path"]
  }
}
          

Enforce the allowlist on the server, resolve symlinks and reject path traversal. The Roots page asks clients to validate root URIs against traversal and servers to check paths against the roots they were given; once paths arrive as tool arguments, both jobs are yours.

Replacing Logging

On stdio, the transport already gives you a channel. The server may write UTF-8 text to stderr for any logging purpose and must not write anything to stdout that is not a valid MCP message; the client may capture, forward or ignore stderr and should not treat it as an error signal.

            import logging
import sys

# stdout carries MCP messages only; logs go to stderr
logging.basicConfig(
    stream=sys.stderr,
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s %(message)s",
)
log = logging.getLogger("pdf-server")
log.info("tool call started")
          

Streamable HTTP servers have no stderr path to the client, so use OpenTelemetry. The 2026-07-28 revision reserves the _meta keys traceparent, tracestate and baggage for W3C trace context (SEP-414), so a host's trace and your server's spans can join up. Our OpenTelemetry GenAI conventions guide covers span design. If you used Logging to show progress, notifications/progress remains and still flows on the response stream of its request. Keep the Logging page's security rule wherever logs go: no credentials, secrets or personal identifying information.

Migration guide for MCP clients and hosts

• Keep support where you have it, stop where you don't. Existing implementations should migrate before the earliest removal, and new ones should not adopt the features. If your host never implemented Sampling, do not start now.

• Declare only what you support. Capabilities now travel in _meta under io.modelcontextprotocol/clientCapabilities on every request. Stop declaring Sampling or Roots when you drop them; servers must not send tool-enabled sampling requests unless you declare sampling.tools.

• Turn the workspace picker into configuration. Pass the directories users chose to servers as launch configuration or tool arguments.

• Collect logs and traces. Route server stderr into your own logs, and propagate traceparent in _meta.

• Register with metadata documents. The order is pre-registered credentials, then a Client ID Metadata Document when the authorisation server advertises client_id_metadata_document_supported, then Dynamic Client Registration as a fallback. The document sits at an HTTPS URL and includes at least client_id, client_name and redirect_uris. Our MCP authentication comparison covers the auth side.

• Finish the HTTP+SSE exit. Move remaining HTTP+SSE connections to Streamable HTTP now; it is the one deprecated feature the March 2027 revision could remove.

• Probe before you guess. A client that supports both handshake-era and current versions should call server/discover first and fall back to initialize only if the server returns some other error or does not answer in time, never keyed to one error code.

Decision table: what to do with each dependency

Data, cost and compliance notes for India and the EU

After migration, content that went to the user's chosen model goes to a provider you choose, under your contract. If your service decides the purpose and means of processing Indian users' personal data, the DPDP Act makes you the Data Fiduciary and the model provider your Data Processor: section 8(2) allows that only under a valid contract, and section 8(1) keeps you responsible for its processing. The DPDP Rules notified in November 2025 set an 18-month phased timeline; our DPDP Rules checklist maps what applies from 13 May 2027. In the EU, GDPR Article 28(3) likewise requires a processor to be bound by a contract or other legal act. Token spend also moves to your bill, which matters most for free or open-source servers.

OpenTelemetry pipelines often ship data to third-party backends, so apply the redaction you applied to notifications/message. Our LLM observability comparison covers self-hosted options for teams that need traces to stay in-region.

Migration checklist

1. Search code for sampling/createMessage, roots/list, logging/setLevel, notifications/message, includeContext and registration calls.

1. Upgrade to an SDK release that targets 2026-07-28 and read its deprecation notes.

1. Classify each Sampling use as return data or own the model call; price and gate the second.

1. Replace Roots with tool parameters, resource URIs or configuration, plus a server-side allowlist.

1. Move logs to stderr and OpenTelemetry, retire HTTP+SSE before March 2027, and register with metadata documents first.

1. Update DPDP and GDPR records and processor contracts for any new model-provider data flow.

1. Re-check the registry at the March 2027 release and the first release on or after 28 July 2027.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our MCP server development and integration service audits servers and hosts for deprecated features, ports them to 2026-07-28 and rebuilds Sampling, Roots and Logging use on supported patterns. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Deprecated Features (2026-07-28) — Model Context Protocol

1. Release 2026-07-28, published 28 July 2026 — modelcontextprotocol/modelcontextprotocol on GitHub

1. Feature Lifecycle and Deprecation Policy — Model Context Protocol

1. Key Changes (2026-07-28 changelog) — Model Context Protocol

1. MCP Core Maintainer Meeting, 15 September 2026 (Amsterdam), discussion 3402 — modelcontextprotocol/modelcontextprotocol on GitHub

1. Versioning — Model Context Protocol

1. Deprecated Features (draft) — Model Context Protocol

1. Authorization spec split, PR 2858, merged 4 June 2026 — modelcontextprotocol/modelcontextprotocol on GitHub

1. SEP-2596: Specification Feature Lifecycle and Deprecation Policy, PR 2596 — modelcontextprotocol/modelcontextprotocol on GitHub

1. Mark SEPs as final, commit 183238d, 3 June 2026 — modelcontextprotocol/modelcontextprotocol on GitHub

1. The 2026-07-28 Specification, 28 July 2026 — Model Context Protocol Blog

1. Streamable HTTP transport (2026-07-28), backwards compatibility — Model Context Protocol

1. SEP-2596 specification file (seps/2596-spec-feature-lifecycle-and-deprecation.md) — modelcontextprotocol/modelcontextprotocol on GitHub

1. SEP-2577 specification file (seps/2577-deprecate-roots-sampling-and-logging.md) — modelcontextprotocol/modelcontextprotocol on GitHub

1. SDK Tiering System — Model Context Protocol

1. SEP-2577: Deprecate Roots, Sampling, and Logging, PR 2577 and review thread — modelcontextprotocol/modelcontextprotocol on GitHub

1. MCP Maintainer Day, 16 September 2026 (Amsterdam), discussion 3403 — modelcontextprotocol/modelcontextprotocol on GitHub

1. Roots (2026-07-28) — Model Context Protocol

1. Transports overview (2026-07-28) — Model Context Protocol

1. Sampling (2025-11-25) — Model Context Protocol

1. Roots (2025-11-25) — Model Context Protocol

1. Logging (2025-11-25) — Model Context Protocol

1. Sampling (2026-07-28) — Model Context Protocol

1. Logging (2026-07-28) — Model Context Protocol

1. stdio transport (2026-07-28) — Model Context Protocol

1. Overview, request metadata and OpenTelemetry trace context (2026-07-28) — Model Context Protocol

1. Client Registration (2026-07-28) — Model Context Protocol

1. The Digital Personal Data Protection Act, 2023 (No. 22 of 2023), Gazette of India, 11 August 2023 — Ministry of Electronics and Information Technology

1. Government notifies DPDP Rules to empower citizens and protect privacy, November 2025 — Press Information Bureau

1. Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex