In MCP sampling, what human review does the spec expect before and after the model call?

## What sampling is Sampling is the MCP feature that lets a **server** ask the **client** to run a language-model completion on its behalf. The server sends the messages it wants completed; the client runs them against a model it already has access to and returns the generated text. The point of the arrangement is that the server never needs an LLM provider API key of its own, and the client keeps control over which model runs, what it costs, and what leaves the machine. That arrangement only works as a trust boundary if a person is actually in the loop, which is why the specification attaches human-review guidance to sampling specifically. ## Where the request shows up in revision 2026-07-28 This matters because it changes who is in a position to review. Before 2026-07-28, a server could send a `sampling/createMessage` **request** to the client at any time — servers could initiate JSON-RPC requests. Revision 2026-07-28 removed server-initiated requests entirely. A sampling request now arrives as one entry in the `inputRequests` map of an `InputRequiredResult` returned from a `tools/call`, `prompts/get` or `resources/read` that the client itself started. The client is therefore always mid-way through an operation it chose to begin, holding the interim result in hand, deciding whether to go on. The review point is structurally guaranteed rather than bolted on. ## Review point one: before the model runs The client should surface the request to the user and allow three outcomes: approve as-is, **edit the prompt** and then approve, or reject. Editing is not a nicety. The messages and system prompt in a sampling request are authored by the server — a third party — and approving them unchanged means letting a remote party write instructions straight into your model with your credentials behind them. A reviewer who can see and change that text can strip an instruction they do not want executed, remove context they do not want spent, or cut a request down to size. The reviewer should also be shown **which server** the request came from. Note that self-reported identity fields such as `io.modelcontextprotocol/serverInfo` are explicitly untrusted in 2026-07-28, so the trustworthy label is the one the host derives from its own configuration, not the name the server sends. ## Review point two: before the completion is returned The second gate is easy to forget and is the one that protects data rather than budget. The completion is generated on the client's side, from whatever context ended up in the prompt, and then handed to the server. That is an outbound channel: anything the model writes goes to the remote party. So the user should be able to see the completion, and edit or redact it, before it is delivered. Related to the same concern, the `includeContext` values `"thisServer"` and `"allServers"` were deprecated in 2026-07-28 in favour of omitting the field or using `"none"`, precisely because pulling extra context into a server-requested completion widens what can flow back out. ## SHOULD, not MUST — and why that is not a loophole All of this is advisory in the specification's own terms. MCP is a wire protocol; it can describe a message but it cannot make a desktop application draw a dialog. The consistent position across the specification is that the **host** is the enforcement boundary for consent, and no protocol field proves that a human saw anything. Two consequences follow. First, a server must not be written as though approval is guaranteed — it has to cope with never getting a response. Second, a client that skips review is not violating a parser rule, it is failing its users; the quality of the host is the whole safety story here. ## How a refusal is expressed Because there is no server-initiated request in 2026-07-28, there is also no response to send a rejection in. If the user says no, the client simply does not retry the original request. The server sees nothing further and eventually treats the operation as abandoned. There is no decline error, no reason string, and no way for the server to distinguish a deliberate refusal from a crashed client. ## Practical notes for a client implementation Show the actual prompt text rather than a summary; make the edit box the same box the user reads from; show token cost or a per-server budget alongside the approve button so the decision is informed; and keep a log of what was approved so an unattended run can be audited afterwards. Finally, remember that sampling as a whole is deprecated as of revision 2026-07-28, so a client may reasonably decide the safest human-in-the-loop policy is not to advertise the `sampling` capability at all.