Canonical: https://botbento.com/blog/mcp-sampling-deprecated/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 4 MIN READ # MCP Sampling Is Deprecated. What Should Bot Builders Do Now? MCP deprecated Sampling and Roots in protocol version 2026-07-28. Existing integrations have at least twelve months before either feature is eligible for removal; builders should inventory usage and plan the migrations named in the specification. By BotBento Editorial · Published 2026-09-25 · Updated 2026-09-25 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [What changed in the MCP spec](#what-changed) - [How sampling worked, briefly](#how-sampling-worked) - [Roots is also deprecated, but it was never an access-control boundary](#roots-also-deprecated) - [Why this matters if your bot connects to MCP servers](#why-it-matters) - [What to do now](#what-to-do-now)[Read as Markdown ](/text/blog/mcp-sampling-deprecated/index.md) ## Key takeaways - Sampling let an MCP server request a model generation through a supporting client; it is deprecated, not yet removed. - The specification keeps deprecated features for at least twelve months before removal eligibility; that is a minimum, not a guaranteed removal date. - New integrations should avoid Sampling and Roots. Review model-provider ownership separately from filesystem permissions. ## What changed in the MCP spec The Model Context Protocol's sampling feature is deprecated as of protocol version 2026-07-28, tracked under SEP-2577. Under the protocol's feature lifecycle policy, a deprecated feature stays in the specification for at least twelve months after the deprecating revision before it can even be considered for removal, so nothing breaks immediately for bots that already rely on it. The specification advises new implementations not to adopt Sampling and asks existing ones to migrate toward direct LLM provider APIs. Its Roots page separately deprecates the client feature for listing relevant filesystem locations and recommends tool parameters, resource URIs, or server configuration instead. These are two distinct migration paths; the specification does not say that either change removes the need for client consent or server-side access controls. Sources: [Sampling - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/sampling), [Roots - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/roots). ## How sampling worked, briefly Sampling gave MCP servers a way to request a completion from a language model without holding an API key of their own. The protocol provided a standardized way for servers to request LLM sampling from language models via clients, letting the client keep control over model access, selection, and permissions while the server borrowed that capability to power its own logic. A server might use this to summarize a document, classify an input, or draft a reply, all without ever seeing a raw provider credential. Because a server calling into your model is a meaningful trust boundary, the spec built in a safeguard: for trust and safety, there should always be a human in the loop with the ability to deny sampling requests, and applications were expected to make reviewing those requests easy. That review step, not the sampling call itself, was the main control a bot owner had over what a connected server could ask a model to do. Sources: [Sampling - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/sampling), [Sampling - Model Context Protocol](https://modelcontextprotocol.io/specification/2025-06-18/client/sampling). ## Roots is also deprecated, but it was never an access-control boundary The 2026-07-28 revision also deprecates Roots. A root tells a supporting server which filesystem locations the client considers relevant. The specification explicitly says roots are informational guidance, not access control, and the protocol does not force a server to remain inside them. A server that needs filesystem access still needs its own permission and path checks. An illustrative review: if a document-search server reads only one project folder today, first find out whether that limit comes from the server's actual permissions or merely from a Roots hint. Then ask its maintainer how it will receive relevant paths after migration. Passing a path as a tool parameter changes how the server discovers it; it does not authorize reading that path by itself. Sources: [Roots - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/roots). ## Why this matters if your bot connects to MCP servers Bot builders often connect a client or agent to MCP servers built by another team. A server may request Sampling only if the client advertises support; the server does not declare a Sampling capability on the client's behalf. If a server uses that path, the client mediates model access and can present the request for human review. A direct provider integration moves the model request into the server's own provider relationship. Ask the server owner what model, credentials, data handling, and approval controls replace the client-mediated path. Illustrative example: imagine a small MCP server called 'invoice-explainer' that used sampling to ask your client's model to summarize uploaded invoices in plain language. Under the old design, every summary request passed through your client, which meant your approval gate and your model choice governed what happened. If invoice-explainer's maintainer migrates to a direct provider API, that summary request stops touching your client at all. Your bot loses visibility into that call, and the server takes on its own cost and model choice. That is a meaningful shift in who is accountable for what the tool does, even though the end result — a summarized invoice — looks the same to the user. It also means a security review of invoice-explainer after migration needs to ask a different question: not 'what can it ask my model to do,' but 'what provider account does it use, and what data does it send there.' Sources: [Sampling - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/sampling). ## What to do now Treat the deprecation as an inventory and migration task, not an emergency. The twelve-month minimum is a floor for removal eligibility, not a promise of a particular removal date or of universal implementation support. Start by checking the capabilities your client advertises and the MCP servers that actually request Sampling or Roots. Record which server owns each request and how a human reviews it. - Inspect the client's advertised Sampling and Roots capabilities and the requests made by each connected server. - Ask server maintainers how any Sampling use will migrate to a direct provider integration and how model data and cost will be governed. - Do not design new integrations around deprecated features. - Keep a human review path for sensitive model requests while Sampling remains in use. - Treat Roots as guidance, never as the sole filesystem permission boundary; verify actual server-side controls. Sources: [Sampling - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/sampling), [Roots - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/roots). ## Primary sources Sources checked 2026-09-25. Standards and product documentation can change; follow the linked version when implementing. - [Sampling - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/sampling) — Model Context Protocol - [Sampling - Model Context Protocol](https://modelcontextprotocol.io/specification/2025-06-18/client/sampling) — Model Context Protocol - [Roots - Model Context Protocol](https://modelcontextprotocol.io/specification/draft/client/roots) — Model Context Protocol BotBento is in development. [Suggest a correction](/contact/).