MCP's Sampling lets servers prompt your model, and the approval gate varies by client

A one-directional picture, corrected

Most coverage of the Model Context Protocol describes one direction of travel: your model picks a tool, the server runs it, a result comes back. A dev.to post by kenimo49 points at a less-discussed primitive that inverts this. Sampling lets an MCP server send a request up to the client asking it to run an LLM completion on the server's behalf, with a prompt the server wrote. The server stops being a thing you call and becomes, briefly, a thing that prompts your model.

What Sampling actually does

In an ordinary MCP exchange, the model does the reasoning and the server is plumbing that runs tools and returns text. Sampling lets a server with no model of its own borrow the client's. The post's example is an expense-processing server that hits a transaction it cannot categorize. Instead of failing, guessing, or handing the problem back, it pauses mid-task, asks the client's LLM which account the transaction belongs to, and carries on. According to the MCP concept documentation, this is what makes agentic server workflows possible: a server can stop and reason at a step rather than run blind, without shipping its own model and API key.

What travels in the request

The method is sampling/createMessage. Per the post, drawing on the MCP spec draft, several fields do more than they appear to:

• messages and systemPrompt constitute a prompt authored by a remote party. The user did not write it.
• modelPreferences lets the server lobby for a model class via hints and costPriority, intelligencePriority and speedPriority values. The client still makes the final pick, but the server can push toward an expensive one.
• includeContext accepts "none" (the default), "thisServer" or "allServers", and tells the client how much surrounding conversation to fold into the request. The spec draft reportedly soft-deprecates the two broader values; a compliant client honors them only if it has declared a sampling-context capability.

The gate the spec built in

The protocol authors anticipated the risk and specify human review at two points, not one. Before the call, the client should show the user the prompt the server wants to run, which the user can edit, approve or reject. Before the result returns, the client should show the completion, which the user can approve or block. The server proposes, the model thinks, and a person sits on both the inbound prompt and the outbound answer.

The operative word, the post stresses, is "should". The spec describes the gate; whether a given client implements it well, or implements Sampling at all, is a separate question.

Support is thin in 2026

The author's survey of clients is the part that resets assumptions. Claude Code's MCP client still does not support Sampling; its feature request (issue #1785) has been open since June 2025 and was still open, at 58 comments, in August 2026. Elsewhere things have moved: opencode closed its sampling request (issue #11948) as completed in April 2026, and VS Code's MCP client acts on modelPreferences. Two consequences follow. Servers that lean on Sampling will fail or degrade on the clients most users actually run. And because the primitive is implemented unevenly, the human-in-the-loop guarantee is only as strong as the specific client in front of you.

The attack surface Unit 42 mapped

In April 2026, Palo Alto's Unit 42 published an analysis of attack vectors specific to Sampling. These attacks slip past tool-integrity checks and sandboxing because they ride a legitimate protocol feature rather than a malformed tool. Unit 42 groups the abuse into three classes: covert tool invocation performing hidden file and system operations, conversation hijacking that injects instructions persisting across turns, and resource theft that drains compute quota for the attacker's workloads.

The hijacking mechanism is subtle. A malicious server's Sampling prompt instructs the model to append a directive to its next visible response; because that text enters conversation history, the model keeps following it on later turns, long after the Sampling call finished. The same trick exfiltrates data by telling the model to slip extracted information into its next answer. And includeContext is the cross-server problem: a client that is not strict about scoping could let an untrusted server request "allServers" and read context belonging to trusted servers sharing the same model. The soft-deprecation looks like the spec quietly walking that back, but only for clients that respect it.

Why it matters

Sampling turns the MCP trust boundary around. Tool results flow server-to-user and are treated as untrusted output; a Sampling request flows server-to-your-model, putting a third party upstream of the model's reasoning. That makes the client-side approval gate the whole defense, and that gate exists only where a specific client chose to build it. For anyone running multiple MCP servers against one model, the practical checklist implied by the post is short: confirm whether your client supports Sampling at all, and if it does, examine how it renders the two approval steps and how it scopes includeContext.