MCP deprecated Roots, Sampling and Logging
Quick answer: The 2026-07-28 revision of the Model Context Protocol deprecated four features — Roots, Sampling, Logging and OAuth Dynamic Client Registration — and introduced the first formal deprecation policy MCP has ever had. Nothing stops working now. The minimum window is twelve months, so the earliest any of those four can disappear is the first revision released on or after 28 July 2027. The exception is the old HTTP+SSE transport, which was already deprecated and gets a three-month clock instead. Read the deprecated registry, not the changelogs.
The interesting part of MCP's July revision is not the four deprecations. It is that MCP now has a rule for how deprecation works, which it did not before — and that rule is what tells you how much time you actually have.
Until SEP-2596, "deprecated" in MCP meant whatever the prose around a feature happened to say. The HTTP+SSE transport had been described as deprecated since 2025-03-26 with no stated removal date. Two includeContext values had been soft-deprecated since 2025-11-25, whatever soft-deprecated meant. If you were deciding whether to build on a feature, there was nothing to plan against.
What is deprecated, and when it can go
The spec now maintains a single deprecated features registry, which the policy describes as "the canonical answer to 'what is on its way out, and by when'". Six rows are in it today.
| Feature | Deprecated in | Migrate to | Earliest removal |
|---|---|---|---|
| Roots | 2026-07-28 | Tool parameters, resource URIs or server config | On/after 2027-07-28 |
| Sampling | 2026-07-28 | Integrate directly with LLM provider APIs | On/after 2027-07-28 |
| Logging | 2026-07-28 | stderr on stdio, or OpenTelemetry | On/after 2027-07-28 |
| Dynamic Client Registration | 2026-07-28 | Client ID Metadata Documents | On/after 2027-07-28 |
includeContext: thisServer / allServers | 2025-11-25 | Omit the field, or use none | Follows Sampling |
| HTTP+SSE transport | 2025-03-26 | Streamable HTTP | Three months after SEP-2596 is Final |
That last row is the one to act on. Everything deprecated in July 2026 has a year. The transport that has been deprecated the longest has the shortest remaining clock, because the policy's transition provisions reclassified it rather than restarting its window. If you still run HTTP+SSE, that is the migration with an actual deadline attached.
Why these four, and not others
Roots and Sampling were not deprecated because nobody used them. They were deprecated because the mechanism they depended on no longer exists.
The same revision introduced Multi Round-Trip Requests, which replaced server-initiated requests — roots/list, sampling/createMessage, elicitation/create — with a pattern where the server returns an InputRequiredResult carrying inputRequests, and the client retries the original request with inputResponses. Once a server can no longer call the client, a feature defined as "the server calls the client to ask for roots" has no shape left. The stateless rewrite we covered when the revision landed is the cause; these deprecations are the consequence.
Logging is a cleaner story. logging/setLevel was removed outright in the same revision, not deprecated — log level is now set per request via io.modelcontextprotocol/logLevel in _meta, and servers must not emit notifications/message for requests that did not include the field. The remaining Logging feature is a protocol-shaped way of doing something stdio and OpenTelemetry already do better, and the spec says so: log to stderr on stdio transports, use OpenTelemetry for observability.
Dynamic Client Registration is the one with a different flavour. RFC 7591 DCR is deprecated in favour of Client ID Metadata Documents, but the changelog is careful: "It remains available for backwards compatibility with authorization servers that do not support Client ID Metadata Documents." That is a deprecation you cannot fully act on yet, because your authorization server has to move first. If you are choosing one, the authentication and identity category is where to check whether a given provider has shipped CIMD support.
The policy, in the details that matter
Three clauses are worth reading closely, because they change how you should plan.
The window runs from the revision, not from the SEP
The minimum deprecation window is "at least twelve" months, and the policy is explicit that it "is measured from the release of the specification revision in which the feature is first marked Deprecated, not from the date the SEP reaches Final." A feature becomes eligible for removal in the first revision released as Current on or after the window elapses. That makes dates computable: deprecated in 2026-07-28 means eligible from the first revision after 28 July 2027, not twelve months after some PR merged.
Expedited removal needs a real vulnerability
The twelve-month floor can be shortened, but only for "an active security risk, meaning a vulnerability with a published security advisory or documented in-the-wild exploitation for which no in-place mitigation exists." Even then the shortened window "must still provide at least ninety days." Ninety days is the real floor on any MCP feature removal. Not thirty, not next revision.
Eligible is not scheduled
The policy states that removal "is executed at the discretion of the Core Maintainers after the minimum deprecation window has elapsed" and that features "may remain Deprecated, without removal, for much longer than the minimum deprecation window." A deprecated feature can also be restored to Active by a superseding SEP, in which case the window is measured afresh. So July 2027 is the date nothing can be removed before — it is not a date anything will be removed on.
What your SDK owes you
This is the part most people will feel rather than read. Once the revision marking a feature Deprecated is Current, Tier 1 SDKs must mark the matching API surface deprecated using the language's native mechanism in their next release — @Deprecated in Java, [Obsolete] in .NET, @deprecated JSDoc in TypeScript, the Deprecated: doc convention in Go — and should emit a runtime warning when the feature is exercised.
The enforcement line is unusual for a protocol spec: an SDK that "consistently fails to surface a Deprecated feature is subject to the Tier Relegation Process." Deprecation visibility is now a condition of SDK tiering, which means your editor should start telling you about this without you reading any changelog. If it is not, that is a reportable gap against the SDK, not a thing you missed.
Removal from the spec does not oblige an SDK to drop the feature, though — that timeline follows the SDK's own revision-support policy. Expect the generated types to outlive the spec text. If you are regenerating clients from schema.ts, a JSON-to-TypeScript converter is a quick way to diff what a revision's schema actually declares against what your code assumes, and a JSON-to-Zod converter gets you runtime validation for the parts you care about.
What to do in the next month
Audit for HTTP+SSE first, because it has the shortest clock. Then grep your server for roots/list, sampling/createMessage and logging/setLevel — the last one is already gone, not deprecated, so if it is in your code you are behind the current revision, not merely ahead of a deadline. If you lean on Sampling to borrow the client's model, plan the provider integration now; that is a procurement and billing change, not a refactor, and it takes longer than the code does.
Then subscribe to one page rather than several. The registry is a derived view, kept consistent with the per-feature notices and changelog entries, which remain the normative records — but it is the only page that answers "by when" in one place. Bookmark it and check it when a revision ships. For the broader tooling layer, the AI tools and platforms category and our open-source listings track the servers and frameworks that will have to follow this policy whether or not they advertise it.
FAQ
Does my MCP server break today if it uses Sampling?
No. Deprecated features "remain fully functional during the deprecation window". The guidance is that new implementations should not adopt them and existing ones should migrate before the earliest removal date, which for Sampling is the first revision released on or after 28 July 2027.
What replaces Sampling?
Nothing inside MCP. The documented migration is to integrate directly with LLM provider APIs. That is a deliberate scope reduction: the protocol is stepping out of model invocation rather than redesigning it.
Is Logging gone or deprecated?
Both, in parts. The Logging feature is Deprecated. The logging/setLevel method was removed in 2026-07-28 and log level moved to the per-request io.modelcontextprotocol/logLevel key in _meta.
Can a deprecated feature come back?
Yes. A Deprecated feature may be restored to Active by a SEP that supersedes the deprecation SEP and documents the changed circumstances. If it is later deprecated again, the twelve-month window starts over from the revision in which the new deprecation takes effect.
How short can a removal window get?
Ninety days, and only for a vulnerability with a published advisory or documented in-the-wild exploitation that cannot be mitigated in place. Expedited removal requires Core Maintainer approval recorded in a SEP.
Where is the authoritative list?
The deprecated registry at /specification/2026-07-28/deprecated. It is a derived view; the per-feature deprecation notices and revision changelog entries are the normative records, but the registry is the only single page with earliest-removal dates.
A protocol that publishes its removal dates is easier to build on than one that publishes more features. This is the more useful half of the July revision.