MCP lets a host application connect to outside tool servers. Each tool can do real things: read a file, delete a file, send a message, charge a card. The host has to decide when to ask you before it acts.
Two obvious designs both fail. If you confirm every single call, you get **approval fatigue**: after the tenth popup you stop reading and just click yes. If you auto-approve everything, there is no real consent at all, and a malicious server can do whatever it wants.
The better answer is risk tiering. Group low-risk reads, like fetching a public page, and let them flow with one batch approval. Save the individual stop and ask prompts for the dangerous operations: deletes, writes, payments, calls to outside services.
The deeper point is what the prompt shows. Good trust UX surfaces the full tool description and the exact arguments the model is about to send. That visibility is the real defense against hidden instructions smuggled into a tool's metadata.
Risk tiering wins because it spends the user's attention where it matters.
Prompting on every call trains people to click through without reading. That is approval fatigue, and it quietly destroys consent. Auto-approving everything skips consent outright. Both extremes leave the user blind to what a server is actually doing.
The right pattern batches low-risk read operations and reserves individual prompts for destructive or high-privilege actions. Reading a public web page is cheap to allow. Deleting files, writing data, or hitting a payment API deserves a deliberate, well-informed confirmation each time.
Good trust UX is the real defense. The host should surface what the model sees: the full tool description, the exact arguments, and which server owns the tool. MCP threats like tool poisoning and rug pulls hide malicious instructions inside that metadata. If the user never sees it, no approval click is meaningful.
The consent prompt is a security boundary, not a speed bump. Design it to inform a decision, not just collect a tap. Tier by risk so the dangerous moments still get genuine attention.
Quick reference
TL;DR
Risk-tier the prompts: batch low-risk reads, individually confirm destructive or high-privilege calls, and always show the user what the model actually sees.
Think of a building's security desk like a gatekeeper. If the guard stops every single person for a full ID check, the line backs up and the guard starts waving people through without looking. If the guard waves everyone through, there's no security at all. The smart desk lets badged staff walk straight in but stops anyone carrying a large box or heading for the vault. MCP tool approval works the same way. Reading a public web page is a badged employee, just let it through. Deleting files or sending money is the person heading for the vault, so the system stops and asks you, showing exactly what will happen, before it acts.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A fully sandboxed, read-only tool set with no destructive or external operations available If no tool can cause irreversible harm, individual gating buys little and a single batch grant is reasonable.
A non-interactive automation pipeline with no human present to approve anything Interactive consent prompts cannot run unattended; safety must shift to pre-vetted allowlists and policy engines instead.
A trusted first-party server whose tools the host author wrote and ships themselves The cross-vendor trust gap that motivates per-call prompts mostly disappears when one team controls both sides.
Quick scan · 2–4 min
Everything important, quickly.
5 min: name the two failed extremes, define risk tiering, explain why UX visibility is the real defense, then connect to tool poisoning and rug-pull mitigations.
Side-by-side
Approach
Friction
Consent quality
Allow-all-forever per server
None
None; one click signs away everything
Per-call approval for everything
Maximum
Degrades to zero via fatigue
Risk tiering (batch reads, gate writes)
Targeted
High where it matters
Auto-approve plus after the fact log
None
None; harm already happened
Real-world examples
Real products, models, and research that use this idea.
1Claude Desktop and Claude Code prompt per tool call and offer an allow for this session grant rather than a permanent blanket approval.
2Cursor surfaces the MCP server name and tool arguments in its approval dialog so users can see what is being invoked.
3The OWASP MCP Top 10 (2025) lists tool poisoning and rug pulls, threats that informed-consent UX is designed to blunt.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you classify an MCP tool into a risk tier automatically, before any human has reviewed it?
Sign in or go Pro to see the approach for this follow-up.
QA server passed review, then silently updated a tool's definition. How does your UX catch the rug pull?
Sign in or go Pro to see the approach for this follow-up.
QHow do you stop a poisoned tool description from manipulating the user during the approval prompt itself?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating approval UX as a checkbox instead of the real defense. If users click through prompts without reading, poisoned tool descriptions sail right past them.