How do I handle MCP sampling requests (a server asking my client's model for a completion) without leaking secrets or burning my model quota?

What should I check, step by step?

1. Decide whether you need it at all. If your client doesn't need to serve sampling, don't declare the sampling capability; servers may only send sampling to clients that declared it (and sampling.tools for tool-enabled requests).

2. Require approval per request, at least per server: show which server is asking, the full messages and systemPrompt, the model it would run on and maxTokens, with Deny as an easy option. Don't offer "always allow" for servers you didn't write.
3. Cap the spend: set your own ceiling on maxTokens and lower the server's value when it asks for more (the spec only says clients MUST respect maxTokens, so the ceiling is yours), add a per-server rate limit and a daily token budget, and map model hints to a cheaper model when they ask for the most capable one. Hints are advisory; the client makes the final model choice.
4. Keep other context out: treat includeContext as "none" whatever the server asks; the spec lets the client modify or ignore it, for example when honoring it would share sensitive information with the server.
5. Review what goes back: the server receives the model's full reply, so look at it before returning it. If the user's secrets or another server's tool results appear in it, deny or edit.
6. Bound tool loops: when a request includes tools, cap iterations and review the model's tool calls before they go to the server, as the spec's sampling-with-tools flow shows.
7. Log every request: server, time, model used, maxTokens, tokens actually used, stopReason, and whether you approved, edited or denied. Don't keep the message list between requests; the spec says it SHOULD NOT be retained.
8. If you maintain a server that uses sampling: move to a direct provider call from your server with your own key and budget. On 2026-07-28 connections the request travels inside an InputRequiredResult; the MCP TypeScript SDK v2 notes its requestSampling helper throws there.

What does an MCP server get when it sends a sampling request?

Sampling runs a server's prompt through the model your client controls, so the cost lands on your model account and quota. The spec presents this as the feature's benefit ("no server API keys necessary"), and that's also why an unchecked server can spend your quota in a loop.

• The server chooses the messages, an optional systemPrompt, model preferences and maxTokens. The client may change or ignore systemPrompt, temperature, stopSequences and metadata, and maps model hints to whatever model it has. The completion goes back to the server, so anything the model writes, including text it copied from the context you gave it, leaves your machine.
• SEP-2577 names sampling as the most security-sensitive of the three features it deprecates (with Roots and Logging), because it creates attack surface for prompt injection and data exfiltration, and notes few clients ever supported it.

How should an MCP client approve, cap and log sampling requests?

The spec's user interaction model is clear for clients: easy-to-use review UI, the ability to view and edit prompts before sending, and review of generated responses before delivery. Its security list adds approval controls, message validation by both parties, rate limiting, and that both parties MUST handle sensitive data appropriately.

• Put the cost limits where the server can't argue with them: a client-side maxTokens ceiling, a per-server request rate, a per-day token budget and an iteration cap for tool loops. A denied or failed request needs no special reply; under the InputRequiredResult pattern the client simply doesn't retry.
• For tool-enabled sampling, the tools in the request are defined by the server for that request and don't have to match its registered tools. Treat them like any other unreviewed tool list, and keep tool calls visible to the user.

How do I migrate an MCP server off deprecated sampling?

The deprecated-features registry gives the path: integrate directly with LLM provider APIs. The TypeScript SDK's guide says the handler keeps its shape; only the requestSampling call becomes a call to your provider's SDK with your own key, and you stop depending on which clients support sampling.

• Deprecation doesn't break anything yet. Wire behavior is unchanged during the window, and the registry lists the earliest removal as the first revision released on or after 2027-07-28. What changes is that new clients have little reason to add support.
• After migrating, the server pays for its own completions, so the user's prompts and secrets aren't routed through it unless you send them. Send the provider only what the task needs, and give the server its own budget and key.