How do you keep MCP sampling approval prompts from being rubber-stamped by users?

## The failure mode being designed against MCP's sampling guidance asks the client to let a user review a server's prompt before the model runs and review the completion before it is returned. Implemented naively — a modal per request — this degrades within minutes of real use. Users approve reflexively, and a reflexive approval is worse than no approval, because the system now records consent that was never given in any meaningful sense and everyone downstream believes a human checked. So the question is not "how do we prompt" but "how many decisions can a person actually make well, and what should each one be about". ## Make the unit of consent bigger than a message A single completion is the wrong unit. It is too small for the user to have an opinion about and too frequent to sustain attention. The unit that works is an **exchange with declared limits**: "this server wants to use your model for this operation, up to N round trips and a stated token budget." One decision, made with the information that matters, covering everything that follows inside those bounds. Crossing a bound is what brings the human back. This maps cleanly onto the 2026-07-28 mechanics. Because server-initiated requests were removed, every step of a sampling exchange is the client re-issuing its own request — so the host is already the loop driver and can stop at any boundary it chooses. And because declining is expressed by simply not retrying, aborting is free: there is no error to construct, no cleanup handshake, no penalty for saying no. ## Make each prompt carry decision-relevant information When you do ask, show: - **The actual prompt text**, not a summary. A summary is a second model's opinion of what the first one was asked; the point of review is to see what is really being sent. - **What changed** since the last approval for this server. A diff is scannable; a wall of text is not. If nothing changed, that itself is the useful signal. - **Server identity you can trust.** Use the host's own configuration entry for the server. Revision 2026-07-28 is explicit that `io.modelcontextprotocol/serverInfo` is self-reported and untrusted, so a friendly name from the server is not an identity claim. - **Cost so far** in the current exchange and against the server's budget, so the decision is quantitative rather than vibes. - **Both directions.** The completion returning to the server is the data-egress half of the feature and deserves its own review step, at least for servers that are not fully trusted. ## Tier trust instead of treating all servers alike Different servers earn different defaults: a locally developed server may run inside a generous budget without prompting; an unfamiliar remote one may be restricted to a small budget and prompted every time; some are simply denied sampling. Tiering is what makes prompting rare enough to be meaningful. It should be explicit configuration, revocable, and visible — never an implicit "you approved this once, so it is trusted forever". ## Design for unattended runs honestly A great deal of MCP usage is not interactive. In batch or agent contexts, there is no human to prompt, and a system that silently auto-approves in that mode has quietly removed the control while keeping the appearance of it. Better: make unattended mode a distinct policy where sampling either runs inside a hard pre-authorised budget or is refused outright, and where every request is logged for after-the-fact review. Retrospective audit is a legitimate control when synchronous consent is impossible — but only if someone actually reads it, so pair it with alerting on budget anomalies. ## Accept the protocol's limits None of this is enforceable on the wire. MCP cannot make a host draw a dialog, and no field in a response proves that one appeared. The specification's consistent position is that the host is the enforcement boundary. That is a governance fact, not a gap to be closed with cleverness: if you do not control the host, you do not control sampling consent, and your remaining lever is which servers are installed at all. ## The strategic option Sampling is deprecated as of revision 2026-07-28 — deprecated features remain for at least twelve months, new implementations should not adopt them, and the earliest removal is the first revision released on or after 2027-07-28. The migration guidance is for servers to integrate directly with LLM provider APIs. For an organisation weighing the cost of building a genuinely good approval experience against a feature on its way out, not advertising the `sampling` capability is a defensible and often correct decision. Saying so — rather than designing an elaborate consent UI for a deprecated feature — is the answer that shows judgment.