MCP Sampling: Deprecation and Version Compatibility

MCP sampling lets a server request model generation through a client. It is deprecated in protocol revision 2026-07-28. The current specification advises new implementations not to adopt it and existing implementations to migrate toward direct LLM provider APIs. If you are maintaining a sampling-based server, begin by identifying its actual client and protocol dependencies before changing the generation path.

Deprecated does not mean already removed. The current sampling specification retains the feature under the protocol's lifecycle policy. This guide is for operators deciding what to keep compatible during a migration and which responsibilities need a new owner. It does not recommend sampling as a new default integration pattern.

Understand the dependency you inherited

In the 2025-11-25 sampling specification, a server could ask a capable client to generate a response through sampling/createMessage. The client mediated model access and selection. Sampling support was a capability to verify, not something every MCP client automatically supplied.

That distinction matters when an integration appears to work in one host but fails in another. The tool itself may be discoverable and callable, yet its internal generation step depends on client behavior. A successful connection or tools/list response does not exercise that dependency.

Consider a fictional document-review tool that retrieves a report and asks the host's model to summarize it. Its external interface may look like a single tool call. Internally, successful completion depends on retrieval, permission to send the content for generation, a compatible sampling handler, an available model, and a valid returned result. Put those dependencies in the incident record rather than labeling every failure “MCP unavailable.”

Record the protocol and feature separately

Use a compatibility record for each supported host/server pairing. Do not infer wire behavior from a package major version alone, and do not infer a feature from a product's general claim of MCP support.

The 2026-07-28 deprecated-feature registry is the current status reference. Keep a checked date with your compatibility record. Avoid turning the earliest eligibility for removal into a promised removal date, or assuming that a feature retained in the document must remain enabled by every client.

Distinguish legacy delivery from current compatibility

The 2026-07-28 specification changes server-to-client interactions to multi round-trip requests. Where deprecated sampling is still supported in this revision, its request is carried in an input-required result and the original operation is resumed with the response. Earlier standalone server-initiated request examples describe a different lifecycle.

Do not mix those shapes in a troubleshooting reproduction. Capture the request method, protocol revision and result category while redacting content. A server expecting one delivery pattern and a host implementing another needs a compatibility correction, not a longer timeout.

This article intentionally provides no runnable legacy sampling snippet. Reproductions should use the documented SDK and revision for the system under test. If a bridge translates between revisions, test the complete translated interaction, including refusal and failure, rather than only the initial tool call.

For the related case where a server needs a person's input, see MCP elicitation. Asking for a user's decision and asking for model generation are different dependencies, even when both appear inside a larger operation.

Migration changes ownership, not just an API call

Moving generation to a provider API can remove the server's reliance on the client's sampling handler. It also creates decisions that the host may previously have made on the workflow's behalf. Assign those decisions explicitly before switching the path.

Data selection: identify the exact content sent to the provider. A report-review tool should not forward unrelated conversation history because it happens to be available. Define redaction, size limits and handling for content the provider cannot accept. A successful response does not establish that the chosen data handling was appropriate.

Identity and billing: name the account that owns provider usage and the component that holds its credential. Separate user-facing MCP authentication from downstream provider access. The credential-boundary guide can help document where a secret is available and where it must not be included.

Model choice: record the selected model, request options and expected result shape. Do not assume the host previously used the same model as its visible chat interface. Treat a model change as a behavior change to evaluate, even if the surrounding tool schema stays constant.

Consent and policy: determine which application control replaces the earlier host-mediated review. A direct provider call should not silently expand who can authorize generation or which data may leave the environment. Keep the workflow's allowed purpose and its enforcement evidence in the governance register.

These are proposed migration design questions, not claims that a particular SDK or gateway implements the controls automatically.

Work through a bounded migration example

For the fictional document-review tool, start with a fixed set of synthetic reports. Give each a clearly stated expected outcome: a concise summary, identification of missing evidence, or a refusal to process an unsupported input. Include a report containing misleading instructions so the evaluation distinguishes source content from authorized behavior.

Measure the existing supported path first. Record output quality against the task criteria, generation failures, latency and usage where observable. Then evaluate the direct-provider path using the same reports. If you change both the model and the prompt, state that the result reflects both changes; do not attribute the entire difference to removing sampling.

Use this migration decision card for the paired evaluation. Its observation cells are intentionally blank: fill them from the supported route and candidate you actually test, and mark missing evidence unknown. Define acceptance criteria before reviewing the outputs.

For usage, retain each account's categories and accounting source; a reduction in one dashboard cannot stand in for the combined workflow. For review controls, establish who can deny generation and what that denial prevents. Keep publishing or other consequential downstream actions separately authorized on both routes.

Record one decision with its owner and evidence references: accept the candidate when the agreed criteria are met; keep supported compatibility when the existing route is still demonstrably available and approved but the candidate has a named unmet criterion; or defer when required evidence, ownership or an acceptable recovery path is missing. Name the gap and what evidence would reopen the decision. Neither a deprecation notice nor this card supplies a removal deadline or guarantees that an old host remains available as fallback.

Roll out to a limited set of owned workflows. Define a fallback that is actually available: perhaps a manual review path or an explicitly supported compatibility route. Do not promise a rollback to a deprecated feature if the intended host has already disabled it. Document the conditions under which the operation returns an incomplete result instead of guessing.

Test failure ownership as carefully as success

A provider timeout can leave the tool awaiting generation while the MCP request deadline approaches. Decide where cancellation is observed, how retries are bounded, and whether a repeated request can duplicate any side effect. Keep the generation step separate from publishing so recovery can be reasoned about independently.

Exercise a rejected provider credential, a rate limit, an unsupported input, an interrupted request and an invalid model response. The useful result is not merely an error code; it is an explanation of which boundary failed and what the operator can safely do next.

Use audit evidence to correlate the incoming operation, generation attempt and final result without storing unnecessary document content. For cost comparisons, use the whole-task token workflow: moving work between accounts or APIs can make one dashboard look cheaper while total usage remains unchanged.

Finish migration by removing obsolete compatibility configuration only after its consumers have been accounted for. Keep the historical protocol and release information in the server inventory so old incident records remain understandable.

Frequently Asked Questions

Is MCP sampling deprecated?+

Yes. Protocol revision 2026-07-28 marks sampling deprecated and advises new implementations not to adopt it. Existing implementations are directed toward integrating with LLM provider APIs.

Is deprecated sampling already removed?+

No. It remains in the current specification under the feature lifecycle policy. Retention in the specification does not guarantee that every client supports or enables it.

Why can a sampling-based tool work in one client but fail in another?+

The tool may depend on a sampling capability or delivery pattern that the other client does not support. Verify the host, server and protocol revision and exercise the generation step, not only tool discovery.

What changes when a server calls a model provider directly?+

The deployment must explicitly own provider credentials, billing, model selection, data handling, approval policy and failure recovery. Those responsibilities should be reviewed alongside the API integration.

Identify one sampling-dependent workflow and complete its compatibility record. Then assign the data, billing and approval owners before selecting a replacement generation path.