MCP sampling: letting a server borrow your model safely

The control gap

Sampling inverts the usual direction. The server asks the client to run a completion, which means a third-party server chooses the prompt, consumes your tokens, and receives model output back inside its own control flow. Without limits, the cost is unbounded and the prompt is unreviewed. Worse, a server can use the model's answer as a stand-in for a decision it should have had to justify.

What good looks like

Sampling requests are visible, budgeted, and attributable, and no completion is ever the last word on whether a consequential action executes.

• Require explicit per-server consent before sampling is available at all, and show the user what will be sent.
• Cap tokens, model tier, and request rate per server, and record spend against the server rather than the workspace as a whole.
• Keep the model preferences advisory. The client, not the server, decides which model actually runs.
• Never allow a sampled completion to satisfy an approval requirement or to widen the scope of a tool call.

A production workflow

1. The server sends a sampling request with messages, model preferences, and a token limit.
2. The client checks that this server is permitted to sample, applies its own budget and model policy, and optionally shows the prompt.
3. The client runs the completion and returns the result with the model that was actually used.
4. The server uses the text as content, while any action it then proposes is authorized independently.

Copy this

The request is straightforward. Everything that keeps it safe lives in the client's response to it.

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [{ "role": "user", "content": { "type": "text", "text": "Summarise this diff" } }],
    "modelPreferences": { "intelligencePriority": 0.4, "costPriority": 0.8 },
    "maxTokens": 800
  }
}

# Client-side gate, before the completion runs
allowSampling(server)        or reject with an error
tokens_this_hour(server) < budget
model = client_chooses(modelPreferences)     # preferences are a hint, not a command

# Response names the model that actually ran
{ "role": "assistant", "model": "<model actually used>",
  "stopReason": "endTurn", "content": { "type": "text", "text": "..." } }

# The line that must not exist anywhere
if (completion.text.includes("approved")) { execute(action); }

Model preferences are deliberately advisory in the protocol. A server that requires a specific model is asking the client to hand over a decision that belongs to whoever pays for the tokens.

Evidence to require

• Sampling requests per server, with token counts and the model that ran.
• The consent that permitted sampling for that server, and when it was granted.
• Rejected requests: over budget, server not permitted, prompt exceeded limits.
• Any tool call whose arguments were derived from a sampled completion, linked to its own decision record.

Buyer checklist

• Which servers can currently sample, and who approved each one?
• Is model spend attributable to the requesting server?
• Can a user see the prompt before it runs, at least for servers on first use?
• Does any code path treat model output as an authorization result?