What is MCP Sampling?
MCP Sampling is a deprecated Model Context Protocol Client feature that lets a Server request model generation through a Client; new implementations should use direct LLM provider API integration.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
MCP Sampling standardized a way for a Server to request a model generation through the Client side. The Client chooses the available model and credentials, may modify or reject the request, runs the model, and returns an approved result. This differed from a normal Tool call: a Tool asks the Server to perform an operation, while Sampling asked the Client-controlled model runtime to generate Text, Image, Audio, or Tool-use content for work nested inside a Server operation.
Sampling is Deprecated as of MCP 2026-07-28 under SEP-2577. Deprecated does not mean Removed: it remains in the specification during a minimum twelve-month window and is first eligible for removal in a Current revision released on or after 2027-07-28; actual removal may happen later. Existing compatible implementations can continue using it, but new implementations should not adopt it. The specified migration path is direct integration with LLM provider APIs.
The modern compatibility flow uses Multi Round-Trip Requests (MRTR), not an unsolicited Server-to-Client JSON-RPC Request. While handling prompts/get, resources/read, or tools/call, a Server may return resultType: "input_required" with a named sampling/createMessage entry in inputRequests. The initial Request is complete at the transport level. After policy and any user review, the Client retries the original method with a new JSON-RPC ID, matching inputResponses, and the exact opaque requestState when one was supplied.
Sampling is optional and capability-gated. A Client that supports it declares sampling in _meta.io.modelcontextprotocol/clientCapabilities on each Request. Tool-enabled Sampling additionally requires sampling.tools; a Server must not request unsupported input. The older includeContext values thisServer and allServers are also Deprecated, default context inclusion is none, and Client policy may modify or ignore requested context, systemPrompt, model hints, or generation settings.
A CreateMessage Request can carry user and assistant Messages, model preferences, a System Prompt, token and Sampling parameters, and optionally request-scoped Tool Definitions. Hints and cost, speed, or intelligence priorities are preferences rather than a contract for one exact provider or model. Tool-use output must be balanced by matching Tool Results before the next model turn, and a Tool Result Message cannot mix Tool Results with other Content types. Protocol shape does not prove the generated answer is correct, deterministic, safe, or approved for a side effect.
The Host and Client remain the policy boundary for legacy use. They should show the configured Server identity, purpose, exact prompt and context destination, requested model class, Token and cost budget, Tools, and data sensitivity; allow denial or editing; and review the result before it returns to the Server. Human-in-the-loop behavior is a specification recommendation, not a guarantee supplied by every Client. A trusted Connection, Client Capability, or earlier approval must not silently approve a changed prompt, context set, Tool, destination, or budget.
Sampling expands the semantic attack surface. A malicious or compromised Server can submit Prompt Injection as a user Message, request sensitive context, consume model budget, bias model selection, create an unbounded Tool loop, or use generated Tool calls to cross another trust boundary. Default to no ambient cross-Server context, allowlist Server identities and model destinations, redact secrets before model submission, cap bytes, Tokens, cost, latency, retries, and loop iterations, validate every Content Block, and authorize each Tool execution independently. Model output remains untrusted even after user review.
MRTR State does not grant authority. Clients must echo requestState without parsing or modifying it and must not reuse it for another Request. Servers must treat returned State as attacker-controlled; when it affects access or behavior, protect its integrity and bind it to the Principal, original method, salient parameter digest, policy revision, and short expiry. If replay could duplicate a side effect, the Server also needs single-use enforcement or backend idempotency.
Migration starts by inventorying every sampling/createMessage dependency and its actual purpose. For each path, name the owner of provider credentials, billing and quota, model and region policy, prompt and retention policy, Tool execution, retries, and incident response. Replace the Client callback with an approved provider adapter or model service, preserve user-visible consent where the risk requires it, and compare output quality, privacy, latency, cost, refusal behavior, and fallback semantics on a versioned test set. Do not infer that the Server operator, Host vendor, or end user must always pay; MCP does not define that commercial arrangement.
Production evidence should record the immutable Server and Host builds, protocol revision, originating method and Request ID, MRTR step, Sampling descriptor hash, Principal and Tenant, model provider and exact model revision, Prompt and Context digest, Tool definitions, approval and policy revisions, Token usage, latency, stop reason, cancellation, rejection, retry, and downstream effect status. Logs should exclude provider credentials, raw secrets, unrestricted prompts, complete private context, and sensitive generated content. During migration, test Client refusal, missing capability, malformed Content, Model unavailability, budget exhaustion, Tool-loop termination, Request State tampering, replay, and duplicate-effect cases.
Key Characteristics
- Deprecated lifecycle: remains functional during the compatibility window but should not be adopted by new MCP implementations
- MRTR delivery: `sampling/createMessage` is embedded in `InputRequiredResult.inputRequests` and answered on an independent retry
- Per-request capability gate: basic Sampling requires `sampling`, while Tool-enabled Sampling additionally requires `sampling.tools`
- Client control: model hints, System Prompt, context, budget, request, and result remain subject to Client and user policy
- Semantic risk boundary: Server-authored Messages and model output can carry Prompt Injection, data leakage, cost abuse, or unsafe Tool proposals
- Explicit migration: direct provider integration must assign credentials, billing, model policy, privacy, evaluation, and operational ownership
Common Use Cases
- Maintaining an existing MCP Sampling integration during the deprecation window while a direct provider path is validated
- Auditing which Server workflows depend on Client-owned model credentials, model choice, or human review
- Testing MRTR compatibility for Sampling requested during `prompts/get`, `resources/read`, or `tools/call`
- Constraining a legacy model-assisted Server workflow with explicit context, Tool, Token, cost, and iteration budgets
- Comparing direct LLM provider integration against the legacy Sampling path before migration
Example
Loading code...Frequently Asked Questions
Is MCP Sampling removed in protocol version 2026-07-28?
No. It is Deprecated, so its types and behavior remain available during the minimum compatibility window. New implementations should not adopt it, existing implementations should migrate, and removal cannot occur before the first Current revision released on or after 2027-07-28.
How does MCP Sampling work with MRTR?
A Server processing `prompts/get`, `resources/read`, or `tools/call` returns an `input_required` result containing a named `sampling/createMessage` request. The Client gathers an approved model result and retries the original method with a new JSON-RPC ID, matching `inputResponses`, and any opaque `requestState`.
Does MCP Sampling guarantee human approval or a specific model?
No. The specification recommends a human who can review and deny requests, but does not mandate one UI. Model hints and cost, speed, or intelligence priorities are advisory; the Client selects the model and may modify or reject the prompt, context, settings, and result.
What are the main security risks of MCP Sampling?
Server-authored Messages can introduce Prompt Injection, leak sensitive context, consume model budget, influence model selection, or start unsafe Tool loops. Bind every request to a reviewed Server and purpose, minimize context, enforce budgets and iteration limits, and independently authorize every Tool side effect.
How should an existing MCP Sampling integration migrate?
Inventory each workflow, choose an approved direct LLM provider adapter or model service, assign credential and billing ownership, preserve necessary consent, and validate privacy, quality, cost, latency, Tool behavior, denial, and failure handling before disabling the legacy path.