In MCP, what does sampling/createMessage let a server ask the client to do?

## The idea Most of the Model Context Protocol runs one way: a client calls a server to list and invoke tools, read resources, or fetch prompts. Sampling is the one place where the server needs something back from the model side. `sampling/createMessage` is the server saying: *here is a conversation, please run it through a language model and give me the completion.* The point is credential and cost inversion. A server that wants to summarise a file, rewrite a query, or classify a record would otherwise need its own provider account, its own API key, and its own billing relationship. With sampling it borrows whatever model the user's host application already has configured. The server ships no secrets and pays for no tokens. ## The shape of the exchange The request carries a `messages` array of role-tagged content (`user` and `assistant` turns holding text, image or audio content blocks), a required `maxTokens` budget, and optional steering: `systemPrompt`, `modelPreferences`, and pass-through knobs such as `temperature` and `stopSequences`. The response is a `CreateMessageResult`: the assistant message the model produced, plus a `model` string naming what actually generated it and an optional `stopReason` explaining why generation ended. The server never receives a session with the model, a key, or the user's wider conversation — only the completion for the messages it itself supplied. ## Where the request travels in revision 2026-07-28 This is the part that trips up anyone working from older material. Through revision 2025-11-25, a server could open a JSON-RPC request of its own and push `sampling/createMessage` down the wire at the client. Revision 2026-07-28 removed server-initiated requests entirely — there is no `ServerRequest` union any more. A sampling request now appears as one entry in the `inputRequests` map of an `InputRequiredResult`, which the server returns in place of the normal result for a `tools/call`, `prompts/get` or `resources/read`. The client fulfils it and re-issues the original call, carrying the completion back in `inputResponses`. So the flow is: client calls a tool → server answers "I need a completion first" → client runs it → client calls the tool again with the answer attached. The server's tool logic is therefore written to be resumable rather than blocking. ## What the client controls Everything that matters. The client decides which model to use — `modelPreferences` is advisory, not binding — and whether to run the request at all. Approval, prompt review and the surrounding user-control duties belong to the host application, and MCP cannot enforce them at the protocol level. A server must be written to survive a completion that never arrives. ## Capability gating Sampling only exists if the client declares it. Under the modern per-request model, capabilities travel in every request's `_meta` under `io.modelcontextprotocol/clientCapabilities`, and a server must not assume support because an earlier request had it. If the capability is absent and the server needs it, the correct answer is a `MissingRequiredClientCapabilityError` (`-32021`), not a hopeful sampling request. ## Deprecated in 2026-07-28 Sampling is deprecated in revision 2026-07-28. It stays in the specification for at least twelve months, so it is still implementable, but new implementations should not adopt it; the migration path is for the server to integrate directly with an LLM provider API. In practice client support was always optional and patchy, which meant a server could never rely on the feature being there — a fragile foundation for any behaviour a server actually needs. ## What to say in an interview Name the direction (server asks, client runs), name the credential benefit, name the delivery change in 2026-07-28, and finish by saying the feature is on its way out. Candidates who describe sampling as a live, server-initiated request are describing the 2025-era protocol.