Good MCP approval UX gives informed consent: tool name, server origin, plain-language intent, the full description, and risk-tiered prompts. Blanket and silent auto-approve break the model.
Imagine a contractor wants into your house to do jobs. Good security means the doorbell shows you who they are, which company sent them, and what they want to do before you unlock anything. Risky jobs like rewiring get a fresh knock each time; harmless ones like reading the mail meter can be waved through together. A bad system hands the contractor a master key the first time they ring, or lets anyone labeled 'just looking' wander in unannounced. MCP hosts are that door. They must show you the tool, its server, and a clear summary so you actually understand what you are approving, instead of clicking yes on a blank prompt.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
This question looks like a UX puzzle, but it is really a security question wearing a UX costume. The whole point of MCP host approval is that the Model Context Protocol deliberately does not enforce sandboxing at the protocol layer. There is no built-in mechanism that stops a server from advertising a dangerous tool or hiding malicious text in a description. Enforcement is delegated to the host application.
That delegation makes the approval prompt the single most important security control in the stack. It is the moment a human can intercept a tool call before it touches the filesystem, the network, or a private API. Every option in this question is testing whether you understand that the prompt is a consent boundary, not a speed bump. Interviewers use the multi-select format here precisely because the wrong answers are seductive. Both distractors sound like sensible product decisions that a well-meaning engineer would ship to reduce friction.
The four correct answers all strengthen genuine, informed consent. The two distractors both look like reasonable convenience features and both quietly dismantle that consent. This walkthrough explains why, ties each pattern to a concrete MCP attack from the published risk taxonomy, and gives you the framing to defend your choices in an interview. A useful mental model is three pillars: consent should be informed, proportionate to risk, and durable against the server changing its behavior after you approved it.
Why the host owns approval at all
MCP separates roles cleanly. The host is the application embedding the model, such as Claude Desktop, Claude Code, or Cursor. The host also contains an MCP client that manages each connection. Servers are external capability providers that advertise tools, resources, and prompts over JSON-RPC. The protocol standardizes the wire format and the capability negotiation handshake, but it intentionally says little about trust.
Crucially, MCP does not sandbox tools and does not vouch for server behavior. A server you connect to can declare a delete_files tool, embed instructions in a description, or change its behavior after you first approve it. Nothing in the protocol prevents this. The specification is explicit that the host is responsible for user consent and authorization, which is a deliberate design choice rather than an oversight.
That is why approval lives in the host. The host is the only component that sits between the model's intent and real-world side effects, and it is the only component with a human attached. If the host's approval UX is weak, there is no other layer to catch a malicious or compromised server. This is also why several of MCP's named attacks, such as the confused deputy problem where a server acts with broader privileges than the user intended, are ultimately host-mitigated. The prompt is the boundary, and the quality of that prompt is the quality of the defense.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Practice | Verdict | Why |
|---|---|---|
| Name, server, plain-language effect | Good | Gives the user real informed consent |
| Show full LLM-visible description | Good | Lets the user spot tool poisoning |
| Risk-tiered prompts | Good | Friction matches blast radius |
| Server attribution on every prompt | Good | User knows which service owns the tool |
| 'Allow all from this server' | Bad | Blanket grant, enables later rug pull |
| Silent auto-approve read-only | Bad | Reads can still exfiltrate sensitive data |
Real products, models, and research that use this idea.
- Claude Desktop and Claude Code prompt before each MCP tool call and show which server the tool came from.
- Cursor's MCP settings let users review and toggle individual servers and tools rather than granting blanket access.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does a rug pull attack defeat a one-time tool approval, and how would you defend against it?
The server mutates a tool definition after approval. Defend by pinning a hash of the description and re-prompting when it changes.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Treating 'allow all from this server' as convenient UX. It is a blanket grant that surrenders per-call consent and hides a later rug pull.
60 second bullets to scan on the way to the call.
Why the host, not the protocol, is the MCP trust boundary
What an informed approval prompt must display
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.