Sampling, roots and logging are deprecated: what replaces them

The 2026-07-28 revision moves three capabilities to deprecated: roots, sampling and logging. In the SDKs they are marked obsolete, with pointers to their replacements.

Before opening this work, one scheduling point that changes everything: the protocol now has a formal feature lifecycle. A deprecated feature stays functional for at least twelve months before removal, and deprecations are tracked publicly with timelines. So you are not under the same pressure as with the transport.

Split the two efforts. The transport has an immediate compatibility constraint, the deprecations have a known date. Doing both in the same sprint is the surest way to fumble the first.

That said, there is a practical reason not to wait too long: deprecated code that compiles but throws at runtime costs more to debug in six months than to delete today, while you still have the context.

Sampling: the one that changes an architecture

This is the painful one, because it moves a cost.

Sampling let a server ask the client to run a model on its behalf. The server had no API key and no inference bill: it borrowed the host application's. That was also its fragility, because it only worked if the host had a model configured, and failed quietly otherwise.

Without sampling, a server that needs a model calls a provider directly, or goes through a unified inference layer it manages itself.

What to anticipate:

You now own the inference cost. What the user paid for through their host application lands on your invoice. If your product is free or cheap, that alone can break your economics. Check this before writing a single line.

You now own the secrets. A provider key to store, rotate and monitor.

You now own the latency and the outages. Your tool depends on an external service you do not control. You need a timeout, a fallback behaviour and monitoring.

You have to disclose it. If user data now goes to a model provider you picked, that belongs in your privacy policy. It is also something a connector directory submission will look at.

The classic trap: leaving sampling paths in place as dead code. It compiles, so it looks harmless, and it throws at runtime the day someone hits that path. Deleting is faster than debugging later.

Roots: making context explicit

roots let the client tell the server which locations it was granting access to.

The general direction of the spec applies here as everywhere: what used to be implicit and carried by the connection becomes explicit and carried by the request. The scope a tool works on becomes an argument declared in its schema, possibly as a server-minted handle.

For the exact replacement mechanics, read the [Obsolete] pointer in your SDK rather than guessing. The SDKs point to the recommended replacement for each deprecated capability, and that is more reliable than any blog post, this one included.

What matters for your design: a tool that guesses its own scope is a tool that will get it wrong. A tool that receives it as a parameter is testable, and its authorization is verifiable.

Logging: moving to your own observability

Protocol-level logging existed to push messages from server to client.

In practice, most teams running an MCP server in production already have an observability stack, and protocol logging duplicated it. The deprecation pushes you toward what you were probably already using: structured server-side logs, traces, per-tool metrics.

This is the easiest of the three replacements, and it pairs well with the new Mcp-Method and Mcp-Name headers, which finally let you slice every metric by tool.

One caveat: if you used protocol logging to return genuinely useful information to the user, such as progress on a long-running job, that is not an observability problem but a product one. Look at the Tasks extension, which exists for long-running work.

The exit plan

1. Inventory every use of the three capabilities, in the server and in in-house clients
2. Handle sampling first, because it is the only one with cost and compliance impact
3. Delete dead paths while you have the context, even though the deadline is far off
4. Check the [Obsolete] pointers in your SDK for exact replacements
5. Put a calendar alert on the announced removal date, not on "someday"

FAQ

Does my server break on the deprecation date?

No. Deprecated means functional with a removal date, and the policy guarantees at least twelve months.

Can I keep sampling while my clients still support it?

Technically yes during the window. But you are building on something with a known expiry, and you will have to migrate anyway. The only question is whether you do it when you choose or when you are forced.

How do I track these deadlines without spending every Friday on it?

Deprecations are tracked publicly, and the protocol now requires a conformance suite. The minimum viable setup is a conformance check wired into CI plus watching the changelog. That is exactly what compliance monitoring covers.

You do not want to track SEPs yourself

Compliance monitoring is €290 a month: I watch the protocol as it moves, tell you what concerns your server specifically, and warn you before it becomes urgent. No twenty-page report, just what applies to you.

Interested? Talk about compliance monitoring →

Related reading

• How to migrate an MCP server to the 2026-07-28 spec
• The 12-point MCP migration audit checklist