BuildNot yet confirmed elsewhere1 publisher2 min readPublished
MCP deprecates sampling, the request that lets a server borrow the client's model
MCP is moving away from sampling, the request that lets a server borrow its client's model, according to a dev.to post. Servers that relied on it will need their own provider integration or a different split of work with the client.
The Engineer · Build desk
Four actors. Server developers: without sampling, need their own provider integration and may pay per use. Keyless servers: sampling let them generate via the client. Firms and local-model users: sampling let them reuse their setup. Clients: applied permissions and approval.
- cost MCP server developers Without sampling, need own provider integration: credentials, model choice, error handling, possibly paying per use, claim 4
- capability Servers with no provider key Sampling let them request a generation via a compatible client without their own LLM provider API key, claim 5
- exposure Firms and local-model users Sampling let them reuse a central AI environment or local model instead of separate integrations per MCP server, claim 9
- decision MCP clients Mediated sampling requests: applied permission policies, chose the model, potentially asked for human approval, claim 6
| Who | How | Kind | Claim |
|---|---|---|---|
| MCP server developers | Without sampling, need own provider integration: credentials, model choice, error handling, possibly paying per use | cost | 4 |
| Servers with no provider key | Sampling let them request a generation via a compatible client without their own LLM provider API key | capability | 5 |
| Firms and local-model users | Sampling let them reuse a central AI environment or local model instead of separate integrations per MCP server | exposure | 9 |
| MCP clients | Mediated sampling requests: applied permission policies, chose the model, potentially asked for human approval | decision | 6 |
What happened
- Sampling reverses the usual call direction: partway through its own work, the server turns to the client and has the client's model run a generation for it, where ordinary tool calling has the model ask the server.
- The client decides whether to allow a sampling request, selects an available model, performs the generation, and returns the result to the server.
- With sampling, a server can offer an LLM-dependent capability through a compatible client without holding its own LLM provider API key.
- The post's author says the reason for the deprecation is "more nuanced than sampling being a bad idea".
Why it matters
- cost A server that moves to its own model calls takes on API credentials, model selection, provider error handling, and a per-use inference bill that sampling let it skip.
- constraint Sampling let users point a server at their managed AI environment or local model. A server with its own provider call no longer routes through that reuse.
- exposure A server calling its own provider sits outside the client's permission policies and human-approval step, which only applied to sampling requests.
The post's running example is a server that builds quarterly business reports. It retrieves sales data, identifies the relevant metrics, and then needs an LLM to turn the figures into a coherent report, explain what changed, and summarize the business implications [8]. Only that last step touches a model. In our view, losing sampling means rewriting one step of that server, not the whole thing.
There are two exits.
The first is a provider integration inside that step. The second is to stop generating on the server: the tool returns the figures, and the assistant's model writes the narrative. That second route is the ordinary tool-calling direction, where the model asks the server to perform an operation [3]. For a report-shaped tool we think it is the cheaper route, because the server adds no provider integration at all.
It also costs less control than it looks. A server that used sampling never chose its model. The client did [2]. Only the provider route gives that choice back.
A server whose whole value is the generation has less to hand back. We'd expect those to take the provider route.
The post's author describes the old split in one line: "The client supplies the intelligence, while the server supplies the specialized capability or workflow." [10] The same author calls sampling "a legitimate design choice" [11], and the text breaks off mid-sentence right after. It does not include a deprecation date, a spec version or a replacement, so how long existing sampling code keeps working is open.
What to watch
- The MCP spec text or changelog naming a removal version or date for sampling, which the post does not give.
- Whether the spec names a replacement pattern for server-side generation or leaves it to server builders.
- Whether major MCP clients keep supporting sampling after deprecation, since the feature only works if the client implements it.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence35
- Adoption
- Insufficient
- Hype gap
- Insufficient
- Incentives
- Insufficient
- Confidence40
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Sampling allows an MCP server to request an LLM generation through the MCP client.
- [2]
In a sampling request, the client decides whether to allow it, selects an available model, performs the generation, and returns the result to the server.
- [3]
In ordinary tool calling, the model asks the server to perform an operation; with sampling, the server asks the client to use its model as part of the server's own operation.
- [4]
Without sampling, a server that needs to summarize documents, classify information, or generate reports generally needs an integration with an LLM provider, which means managing API credentials, selecting models, handling provider errors, and potentially paying for inference every time the service is used.
- [5]
With sampling, a server can request a generation through a compatible client without requiring its own LLM provider API key.
- [6]
The client can mediate sampling requests, apply permission policies, select the model, and potentially request human approval.
- [7]
The post's author writes that the answer to why sampling is being deprecated is 'more nuanced than sampling being a bad idea'.
- [8]
The post's example is a server that generates quarterly business performance reports: it retrieves sales data, identifies relevant metrics, and needs an LLM to turn the figures into a coherent report, explain significant changes, and summarize the business implications.
- [9]
A company with a centrally managed AI environment, or a developer with a local model, may prefer to reuse it instead of setting up separate model integrations for every MCP server; sampling offers a way to request output through that environment, assuming the client supports the necessary functionality.
- [10]
The post's author writes: 'The client supplies the intelligence, while the server supplies the specialized capability or workflow.'
- [11]
The post's author calls the sampling split 'a legitimate design choice'; the text then begins 'But it also creates' and breaks off.
- [12]
A dev.to post titled 'MCP Sampling Is Deprecated' says MCP is moving away from sampling, in which a server asks the client's model to generate text.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toMCP Sampling Is Deprecated. But Was Delegating to the Client Ever a Bad Idea?
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- LLM provider integrationFollow
- Model Context ProtocolFollow
- Prompt injectionFollow