Most people learn MCP as "a server exposes tools, a model calls them." That covers the common direction of the flow — server gives the model something to do — but the spec also defines the opposite direction: a server asking the client’s model for a completion. That primitive is called sampling, and it’s the least-used part of MCP, mostly because it inverts who’s in charge of the conversation.
What sampling actually is
A normal tool call goes model → server: the model decides to call a tool, the server runs some logic, and returns a result. Sampling goes the other way. While a server is in the middle of handling a tool call, it can send a sampling/createMessage request back through the client, asking the client’s own connected model to generate a completion — then use that completion to keep doing its job.
Concretely: a server processing a large document might hit a point where it needs to summarize a chunk before deciding what to do next, or classify a piece of text, or draft a short reply for a human to review. Instead of the server shipping its own model, its own API key, and its own inference cost, it asks the client to run that one completion using whatever model the user is already paying for and already trusts.
Why the client stays in control
This is the part that makes sampling different from a tool call, and it’s deliberate. A tool is model-controlled — the model decides whether to call it, as we cover in tools, resources, and prompts. Sampling flips that: the request originates from the server, but the client decides whether to honor it, what context actually gets sent to the model, and whether a human needs to approve the request first. The spec leans on human-in-the-loop review here on purpose — a server asking your model to generate text on its behalf is a server asking to spend your inference budget and see whatever context you hand over, and the client is the trust boundary that’s supposed to gate that.
That design mirrors the approval pattern we wrote about in human-in-the-loop approvals for AI tool calls: the interesting security question isn’t whether the mechanism exists, it’s whether the approval step actually gets read before someone clicks through it.
Why a server would want this instead of its own model call
A few reasons show up repeatedly in how the spec frames it:
- No API key to manage. The server doesn’t need its own model provider account, billing, or key rotation — it borrows the client’s connection instead.
- The cost lands where the usage happens. Inference spend shows up on the user’s own model subscription rather than the server operator’s bill, which matters a lot for a server that might get called thousands of times by users the operator has no billing relationship with.
- One fewer model in the loop to trust. The user already decided which model and which client they trust. A server that asks that same model to do a sub-task, under the client’s supervision, doesn’t introduce a second, unaudited model call happening somewhere the user can’t see.
Why almost nobody uses it yet
In practice, sampling is the least-supported primitive of the three MCP defines beyond plain tools. Implementing it well means a client has to build a real approval UI, decide what context is safe to forward to the server’s request, and handle a server that might ask for a completion mid-tool-call rather than at a predictable point in the conversation. That’s meaningfully more client-side work than rendering a tool result, and client support for it has lagged behind tool support across the ecosystem as a result — check whatever client you’re building against before assuming it’s there.
On the server side, the practical alternative is simpler and far more common: just call a model provider directly with your own key, the way any other backend service would. That skips sampling entirely, at the cost of the operator now owning inference billing and key management — which is exactly the tradeoff sampling exists to avoid, when a client actually supports it.
If you’re building a server and considering it
Sampling is worth reaching for when your server does real work that benefits from a model call in the middle — summarizing, classifying, drafting — and you’d rather not stand up your own model access to do it. It’s not worth reaching for as a substitute for tool calls in general; the model-decides-when-to-call-a-tool flow covered in our primitives guide is still the right default for the vast majority of what a server exposes. If you’re generating a server from an existing API with a tool like gate’s MCP server builder, sampling isn’t something that gets generated for you from an OpenAPI spec — it’s a deliberate addition for a server that needs a model call as part of its own logic, not as a stand-in for connecting to an API. See our broader walkthrough on turning an API into an MCP server for the more common path.
The bottom line
Sampling is MCP’s server-initiated request for a model completion, kept in check by putting the client — not the server — in charge of whether it happens and what it sees. It solves a real problem (servers that need a model call without owning their own inference bill) but needs client-side approval machinery most clients haven’t fully built yet, which is why it’s still the primitive you’ll read about far more than you’ll see in a real tool list. See our MCP server directory for the tool-first servers that make up most of what’s actually in use today.