MCP sampling in 2026: deprecated one revision after it grew

Quick answer

Sampling is the Model Context Protocol feature that lets a server borrow the client's model: the server asks for a completion, the client runs it, the server never holds an API key. As of the current 2026-07-28 protocol revision it is deprecated. The spec page carries the notice in its own words: the feature "is deprecated as of protocol version 2026-07-28 (SEP-2577)", new implementations "SHOULD NOT adopt it", and existing ones "SHOULD migrate to integrating directly with LLM provider APIs" (MCP spec, read 3 September 2026). It is not gone. It stays in the spec for at least twelve more months. But it is on a clock, and most of what ranks for this term does not mention that.

I went looking for a current worked example of sampling and ended up reading four spec revisions instead. The interesting part is not that sampling was deprecated. It is that the revision before deprecated it made it considerably bigger.

What I actually checked

Four revisions of the sampling page, plus the changelog and a page that did not exist a year ago. I fetched a deliberately fake revision path first as a control, got a 404, then fetched the real ones so I knew a 200 meant something.

Both of the pages carrying the notice are the current ones. Neither of the pages without it says anything about being superseded while you are reading it.

Expanded in November, deprecated in July

This is the part I did not expect, and it took a diff of the section lists to see it.

The 2025-06-18 sampling page has ten sections. It is the small version: capabilities, sampling/createMessage, model preferences, message flow, error handling.

The 2025-11-25 page has twenty-six. That revision added tool use inside sampling, a multi-turn tool loop, tool choice modes, parallel tool use, message content constraints, tool result messages, and a cross-API compatibility section. Sampling went from "ask the client for a completion" to something close to a nested agent loop. The same revision soft-deprecated two includeContext values, and the page says so plainly: "thisServer" and "allServers" are soft-deprecated, servers SHOULD avoid them, and they "may be removed in future spec releases".

The 2026-07-28 page has all twenty-six of those sections, unchanged, sitting underneath a banner that says do not adopt this.

So the sequence is: one revision builds the feature out substantially, the next revision deprecates the whole thing. Eight months apart. If you learned sampling from the November material, you learned a version of it that was expanded and then shelved almost immediately.

The registry is new, and it is the real story

The thing that makes this different from previous MCP churn is that 2026-07-28 also introduced a feature lifecycle and deprecation policy (SEP-2596): three states, Active, Deprecated and Removed, a minimum twelve-month deprecation window, and a registry page listing everything currently in the Deprecated state.

I read the registry rather than trusting a summary of it. Here is what is on it (deprecated features registry, read 3 September 2026):

Two things worth pulling out of that table.

First, sampling is not being singled out. Roots and Logging went with it in the same SEP, and the shape of all three migrations is the same: stop asking the protocol to do it, do it yourself. Pass paths as tool arguments. Log to stderr. Call your model provider directly.

Second, the registry closes with a line I would not have predicted: "No features have been removed under this policy yet." The policy arrived with the current revision, dated 2026-07-28, roughly five weeks before I read this. Nothing has actually been taken away yet. That is the difference between a deprecation and a breakage, and it is worth holding on to before anyone rewrites a working server this week.

What the spec says to do instead

The migration path for sampling is one clause long and it is a real change of posture: integrate directly with LLM provider APIs.

Sampling existed so that a server could produce completions without holding credentials. The client owned the model, the key and the bill; the server borrowed all three. Dropping it means a server that wants a completion now brings its own provider, its own key and its own cost. That is simpler protocol-wise and strictly worse for the "install this server, it uses your model" story that sampling made possible.

I am not going to pretend that trade is obviously correct. It is a trade. What the spec does make clear is why the mechanism became awkward: 2026-07-28 made MCP stateless. It removed protocol-level sessions, removed the initialize handshake, and replaced server-initiated requests with the Multi Round-Trip Requests pattern (SEP-2322), where a server returns an InputRequiredResult and the client retries the original call carrying the answer. A feature whose whole design was "the server reaches back into a live connection" does not have an obvious home in a protocol that no longer guarantees one.

Sampling and elicitation went different ways, and that surprised me

Both sampling and elicitation were server-initiated requests. Both lost that delivery mechanism in the same revision. I assumed they had been treated identically, and checked, because assuming would have been the easy mistake.

They were not.

Elicitation carries no deprecation notice on its 2026-07-28 page. It was re-plumbed and kept. Sampling was re-plumbed and then deprecated on top. If you want the mechanism half of this in detail, I wrote it up separately in the elicitation field log; this post is the lifecycle half.

The practical read: an MCP server that asks the human a question has a future. An MCP server that asks the client's model to think for it does not, at least not through the protocol.

The tooling moved before the tutorials did

Same pattern I keep running into with MCP, so I checked it rather than asserting it. I fetched three of the pages currently ranking on page one for this term and counted occurrences of the string deprecat in each.

FastMCP, the dominant Python MCP framework, is the interesting case. Its sampling page contains zero occurrences of the word, and it has still already moved. ctx.sample() is gone from FastMCP 4; servers now return an InputRequiredResult whose inputRequests map carries the sampling request, and the answer comes back keyed on a retry. FastMCP 3 still has ctx.sample(). The page explains the reasoning directly: the revision "removed server-initiated requests" because "a stateless protocol has no such thing", and then makes a distinction I thought was sharp, that what the protocol removed "is the pushing, not the asking".

Small discrepancy worth flagging rather than smoothing over: FastMCP attributes the removal of server-initiated requests to SEP-2577, while the spec's own changelog attributes that to SEP-2322 and puts the Roots, Sampling and Logging deprecations under SEP-2577. Both descriptions land in the same place for a working developer. They are not the same SEP.

The two general-audience explainers on page one were the other direction entirely. Neither contains a single occurrence of deprecat, and neither mentions the 2026-07-28 revision at all. They are well-written pieces teaching a feature the spec now tells you not to adopt.

And the search results themselves are quietly misleading in a way I only noticed by reading them side by side. The number one result is a page that carries the deprecation banner, but Google's snippet for it starts at "User Interaction Model" and skips the notice completely. The number three result is the 2025-06-18 spec, which has no notice to skip. Scanning the page without clicking, there is nothing to tell you.

Which makes the first related search Google offers underneath all of this a little pointed: MCP sampling deprecated. People are already asking. The answer is above the results and nobody is surfacing it.

What I would check in my own servers

Concrete and cheap, in the order I did it.

1. Grep for the capability. If your server declares or expects sampling in capabilities, or calls sampling/createMessage, you are in scope. Nothing breaks today.

{ "capabilities": { "sampling": { "tools": {} } } }

2. Check includeContext first. It is deprecated separately and earlier, since 2025-11-25, and the fix is trivial: omit the field or set it to "none". This is the one change I would make now rather than later.

3. Decide whether the server should own a key. That is the actual decision the migration forces, not a code change. A server that calls a provider directly is a server with billing, secrets and rate limits. If that is unacceptable for your distribution model, sampling's deprecation is a product problem, not a refactor.

4. Do not rush. Earliest removal is a revision released on or after 2027-07-28, nothing has been removed under this policy yet, and the deprecated feature stays fully functional in the meantime. The thing to avoid is starting something new on it.

5. Pin the revision you read. Every one of these pages looks authoritative in isolation. The version selector is the only thing distinguishing current guidance from guidance written over a year ago, and it is easy to miss.

The honest summary is that this is not an emergency and it is not nothing. Sampling works, will keep working for at least a year, and is a dead end. That is an awkward status to communicate, which is probably why so little of the ecosystem is communicating it.