MCP Sampling: Let Servers Call the Model Back
MCP sampling gives a server access to the client’s model without its own API key, but its limited support and deprecation make it a compatibility feature, not a sound new dependency.
MCP sampling is the protocol feature that lets an MCP server ask its connected client to run a model generation and return the answer. It solves one specific problem: a server can use the client’s model access, selection, and approval interface instead of carrying its own provider API key. However, new projects should avoid depending on it.
Table of contents
- MCP sampling, defined plainly
- How MCP sampling works
- Worked example: classifying a support incident
- MCP sampling vs tool calling
- When MCP sampling matters—and when it does not
- What actually breaks
- Client support reality
MCP sampling, defined plainly
MCP sampling reverses the usual direction of model work: a server requests a generation from the MCP client, which decides whether and how to fulfill it. The client controls model access; the server supplies messages and preferences.
That differs from an MCP server exposing a tool for the host model. Sampling lets code inside a handler request an additional model judgment, then use it before returning. The official 2026-07-28 sampling specification permits text, image, or audio content, plus limits and model preferences.
The attraction is no provider credential in the server and no single-vendor dependency. The catch matters more: sampling was deprecated in MCP 2026-07-28. It remains available during the deprecation window, but new implementations should integrate directly with provider APIs. MCP Directory agrees.
How MCP sampling works
MCP sampling uses capability negotiation followed by a model request associated with an existing client operation. It does not let a server generate whenever it wants.
- The client declares support. On 2025-era connections, initialization capabilities include
sampling; tool-enabled sampling separately requiressampling.tools. - The user starts an MCP operation. A tool call, resource read, or prompt retrieval becomes the originating operation. Unrelated server-initiated sampling is forbidden.
- The server prepares
sampling/createMessage. It sends messages,maxTokens, and optional generation preferences. Model hints do not command an exact model. - The client reviews and routes it. It may show the prompt, allow editing or rejection, select a model, and apply budget limits.
- The client returns a generation. The response includes assistant content, the selected model, and a stop reason. The server validates it and continues the original handler.
Transport changed with MCP 2026-07-28. Legacy stateful connections can carry an in-flight server-to-client request; the stateless design uses a multi-round-trip incomplete response, which the client fulfills before retrying the original operation. The Python SDK’s sampling guide documents both eras and requires reproducible requests across retries. A stdio transport demo may conceal that deployment complexity.
Worked example: classifying a support incident
A realistic use is an existing incident-analysis server that needs one bounded model decision inside a tool call. It can enrich deterministic data without owning a model account.
Suppose the user asks to analyze incident INC-1042:
- The client calls the server’s incident-analysis tool.
- The server retrieves the description and recent errors from its authorized backend, removes secrets, and minimizes the material.
- The handler asks the client to choose one of three documented categories and give a short rationale. It sets a small token ceiling and excludes unrelated conversation context.
- The user approves the displayed request, and the client chooses an available model.
- The result says
database-capacity. The server treats it as untrusted, checks the category against an allowlist, and combines it with deterministic facts. - The tool returns the classification, evidence, and a note that a model supplied the judgment.
If approval is denied, the model times out, or the category is invalid, the tool can return incident facts with classification unavailable. The MCP debugging guide identifies undeclared client capabilities as a common cause of protocol errors. A speculative callback must not sink the workflow.
MCP sampling vs tool calling
MCP sampling and tool calling point in opposite directions. Tool calling lets the client’s model ask a server to work; sampling lets server code ask the client for another generation.
| Question | MCP tool calling | MCP sampling |
|---|---|---|
| Who initiates it? | Client calls a server tool | Server requests a client generation during existing work |
| Who does the core work? | Server code or an external API | A client-selected model |
| Where are credentials? | Usually on the server | Model access remains with the client |
| Is output deterministic? | It can be | No |
| Main control | Tool approval and authorization | Prompt review, model policy, and token budget |
| Current status | Core, widely implemented pattern | Deprecated since 2026-07-28; thin support |
Normal database, HTTP, or filesystem work belongs in server code; use local vs remote MCP to choose the deployment boundary. Sampling covers only a model-generation step, for which direct provider integration is now recommended.
When MCP sampling matters—and when it does not
MCP sampling still matters for compatibility with an installed workflow that has a supporting client, approvals, and a fallback. It does not justify a new cross-client architecture.
I would maintain it only when:
- the server already uses it in a controlled environment;
- negotiated capabilities are tested, not assumed;
- requests have small token ceilings and narrow inputs;
- denial, timeout, invalid output, and removal have fallbacks; and
- users see which data goes to the model.
I would avoid it for unattended automation, long agent loops, broad context sharing, or distribution to unknown clients. The accepted SEP-2577 names the trade-off: client control was appealing, but approval UI, model selection, security, and tool loops imposed too much complexity for the adoption achieved. Direct integration adds credential and billing work but gives predictable model availability, streaming, retries, and observability.
What actually breaks
Sampling usually breaks at capability, transport, policy, or output boundaries. Production code must treat rejection and incompatibility as normal.
- No sampling capability. Sending
sampling/createMessageanyway can produce a method or capability error. Branch on negotiation first. - Basic but not tool sampling. A client must separately advertise
sampling.tools. The sampling-with-tools change also makes the server own the tool loop and balance tool-use messages with results. - No callback path. Stateless or JSON-only assumptions can block legacy in-flight requests. Test the production protocol version and transport.
- Different model choice. Hints are advisory, so quality and format vary. Validate structured expectations.
- Invisible cost. One user action can trigger extra calls. Show the request, cap output, and never retry without a budget.
- Sensitive context leakage. Minimize prompts, obtain approval, and never treat sampling as authorization for a backend action.
The specification’s security guidance recommends human review of requests and responses. I would default to approval and automate only narrowly classified, low-risk data.
Client support reality
Client support for MCP sampling is thin, uneven, and unlikely to become universal. Runtime capability negotiation is the source of truth; MCP tool support proves nothing about sampling.
VS Code is the clearest documented mainstream implementation. Microsoft announced sampling and model-selection controls in its full MCP support release. Still test the current release, model provider, protocol version, and approval behavior.
Cursor’s published protocol list names tools, prompts, roots, and elicitation, but not sampling. Treat it as unsupported unless its capability exchange proves otherwise. Anthropic documents MCP connectivity across Claude products, but its public overview does not promise sampling; “supports MCP servers” is not the same claim.
Official SDK handlers help custom-client builders, but SDK support is not product support. The TypeScript SDK client guide shows a sampling/createMessage handler; it does not make every SDK-based client compatible.
The verdict: keep sampling only where you control both endpoints or have verified VS Code behavior. For new servers, integrate the model provider directly, disclose cost and data policies, and keep ordinary MCP tools portable. Compare established integrations in our best MCP servers directory without assuming advanced features are present.