MCP Sampling Explained: Model Calls Requested by Servers

Core idea: sampling lets an MCP server ask the client to perform model generation, while the client keeps control of model access, policy, and user approval.

Normally, an MCP server exposes capabilities and responds to requests. Sampling reverses part of that flow: while processing a client request, the server can request language-model assistance through the client. This can support summarization, classification, planning, or a bounded tool loop without giving the server a separate model-provider API key.

TL;DR

• The server requests generation; the client controls the model and may modify or reject the request.
• Clients must advertise sampling support before servers use it. Tool-enabled sampling needs additional declared support.
• Approval, sensitive-data handling, rate limits, and loop limits remain essential.
• Model preferences are hints, not guarantees that a named model is available.
• The current specification marks sampling on a removal path; new implementations should evaluate direct model integration or other current patterns first.

The basic flow

Imagine a code-analysis server needs a concise explanation of a dependency graph. It already has deterministic graph data, but generating a reader-friendly explanation benefits from a model. The server returns an input-required result containing a sampling/createMessage request. The client inspects it, applies policy, optionally asks the user, chooses an available model, performs generation, and returns the result. The server then completes its original work.

This division matters. The server expresses what it needs; the client remains responsible for model access, cost policy, privacy, and presentation. A server cannot assume its preferred system prompt, context inclusion, temperature, or model hint will be honored exactly.

Capabilities and preferences

Clients supporting sampling declare the capability in request metadata. Servers must not request unsupported modes. If tools are included in sampling, the client must also declare sampling tool support.

The server can provide abstract preferences for intelligence, speed, and cost, plus model hints. A client may map those hints to another provider or model with similar characteristics. Builders should describe capability needs instead of making correctness depend on one vendor-specific name.

The client must respect the maximum-token boundary, but may modify or ignore several other generation preferences. Treat sampling output as negotiated service, not deterministic RPC.

Sampling with tools

A sampling request may define request-scoped tools. These tools do not need to be ordinary registered MCP tools. The model can request one, receive a matching tool result, and continue. Tool-use messages and results have strict pairing rules so the conversation remains valid.

Every loop needs a maximum iteration count, deadline, token budget, and tool policy. “Continue until complete” is not an operational limit. The server must also respond to every requested tool use with a matching result before continuing.

A concrete example

A document server extracts text and asks the client model to classify it into an approved taxonomy. The client shows that the server wants to send the document text to a model, checks data classification, selects an allowed deployment, and limits the response to 300 tokens. The server validates the returned category against its known list before saving it.

The model result is a proposal, not authorization. If classification triggers a sensitive workflow, deterministic policy or user approval must decide the action.

Security and product boundaries

Sampling can expose server-provided content to a client-controlled model. Both parties should minimize data, validate message content, and avoid secrets. The client should clearly identify the requesting server and offer approval controls appropriate to the risk. Rate-limit requests by server, user, and tenant.

Do not let a server use sampling to smuggle new privileges. Request-scoped tools still need client enforcement. Tool descriptions are not security policy, and an approved generation request is not blanket approval for every tool call inside it.

Current design status

The current MCP documentation marks sampling as eligible for removal and recommends that new implementations assess direct model integration instead. Existing systems still need an accurate mental model for interoperability and migration.

Choose sampling when supporting an existing ecosystem or when client-controlled model access is a deliberate product boundary. For a new server with its own well-governed model runtime, direct integration may be simpler and more observable. Record the protocol revision because behavior and availability are version-dependent.

Common mistakes

• Assuming the client will use an exact model.
• Sending sensitive context without visible policy or consent.
• Allowing unlimited model/tool iteration.
• Treating generated content as validated business data.
• Requesting sampling when the client did not advertise it.
• Starting a new architecture without checking the feature's current lifecycle status.

My Take

Sampling is valuable as an architectural lesson even where it is not the preferred new implementation path: capability can be requested without surrendering client control. Preserve that principle in any replacement. The component paying for and governing model access should retain policy, visibility, and the right to refuse.

Sources

• Model Context Protocol specification (2026-07-28): Sampling
• Model Context Protocol specification: Multi-round-trip requests and capability metadata