MCP Sampling: When the Server Calls the Client Model

Quick answer: Sampling is the reverse of a normal tool call. Instead of the client calling a server tool, the server sends a sampling/createMessage request asking the host to run its own LLM and return the result. The server supplies messages and model preferences, but the host chooses the actual model, controls cost and consent, and can decline the request. A server that needs language ability without holding its own model key uses sampling.

The direction reverses

Most of MCP flows one way: the host calls tools and reads resources the server exposes. Sampling flips that path. While handling a request, a server may need to summarize, classify, or draft text, and it may have no model access of its own. Rather than embedding a key or calling a separate provider, it asks the host to complete the message using the model the user already configured. The model choice, billing, and any approval stay with the host, while the server gets the generated text it needs.

How a sampling request works

The server sends a request containing the messages, an optional system prompt, and parameters such as max tokens and temperature. It can include model preferences expressed as hints for intelligence, speed, or cost, but it cannot name a specific model. The host receives the request, decides which model to use, and in many implementations surfaces the call for review because it spends tokens and runs content the server supplied. The host then calls the model and returns the generated message, or rejects the request.

Sampling vs tools

What the server can and cannot set

The request gives the server real control over the task itself: it provides the message history, an optional system prompt, and limits such as max tokens and temperature, and it can state model preferences as hints. It cannot force a named model, cannot guarantee the host keeps those parameters, and cannot see which model the host ultimately selected unless the response reports it. This split is deliberate. The server owns the question and the context around it, while the host owns the resource that answers it, including the spend and the decision to expose that model to an external server. Designing around that boundary means the server should frame the prompt clearly enough to work across models rather than tuning it to one.

Honest limits

A server cannot assume a sampling request will be fulfilled. The host can reject it, select a different model than the hints suggest, or change the parameters, so the output varies across hosts and is not deterministic. Logic that needs a fixed answer should not depend on sampling, and the server should handle a declined request rather than treating it as an error it can retry blindly. The protocol defines the message shape, not how each host presents the prompt or whether it asks the user. To see the real behavior, run a live request and inspect what the host returns; Powerduck keeps the request and response visible so you can confirm the model selection and the exact message that comes back instead of assuming the hints were honored.

Frequently asked questions

Does the server choose the model? No. It sends preferences as hints, and the host selects the actual model and may ignore the hints.

Why use sampling instead of a model API key? The server borrows the host's configured model, so it avoids storing keys and leaves cost and consent with the user.

Can the host refuse? Yes. The host can decline the request, and the server should handle that path.

Is sampling output predictable? No. Different hosts and models return different results, so it is not suited to deterministic logic.

The bottom line

Sampling lets a server request a completion from the model the host controls, with the host retaining model choice, cost, and consent. Treat it as a best-effort, reversible call rather than a guaranteed function. For more on operating these servers, see the MCP server guide hub.