Describe the MCP host approval model and explain what granularity of consent a well-designed host should require from the user.
Free · 2 AI evals / day
**MCP** lets an LLM app connect to outside servers that offer tools, files, and prompts. But the protocol itself does not decide what is safe. That job belongs to the host, the application the user actually trusts, like Claude Desktop or Cursor.
The host sits between the model and every server. Before any tool runs, the host can pause and ask the user, "this server wants to run this tool, allow it?" That checkpoint is the approval model. The model never reaches a server directly; it always goes through the host.
Granularity is the key idea. The weakest design asks once and approves everything forever. The strictest asks before every single call. A good host lands in between. It shows which server and which tool, plus a plain description of what gets touched.
The rule of thumb: cheap, read-only actions can be waved through, while anything that writes data, sends a request, or touches secrets should ask first. That way the user spends attention only where it matters.
In MCP the host is the trust boundary, not the protocol. The spec defines how servers advertise tools, resources, and prompts. It says nothing about what is allowed to run.
The host mediates every tool call. It decides which servers connect, scopes what each may do, and surfaces calls to the user for consent before execution. The model only ever sees what the host chooses to expose.
Consent has a granularity dial. Per-server approval is the floor: the user sees which server connects and what tools it carries. For high-risk tools that write data, make network calls, or touch secrets, per-tool or per-category consent is the better default.
The two failure modes sit at the extremes. Blanket approve-all gives zero information and lets a destructive write ride in behind a harmless read. Prompting on every call causes approval fatigue, so users rubber-stamp without reading.
A good host splits the difference. It allowlists safe read-only tools to run silently. It always prompts on side-effecting ones. Each prompt shows the tool name, server origin, and a plain description of what gets touched, so the decision is actually meaningful.
Quick reference
TL;DR
In MCP the host, not the protocol, is the trust boundary: it surfaces every tool call for consent, scopes what each server may do, and picks the approval granularity.
Think of a building with one security desk. Vendors (the servers) show up offering services, but none can walk in and touch anything on their own. Every action goes through the front desk (the host), which asks you, the resident, before letting a vendor open a door or move a box. A lazy desk hands out a master key on day one, so a window-cleaner could empty your apartment. A careful desk asks before risky jobs but waves through harmless ones, like reading the lobby notice board. The protocol just defines how vendors describe their services. It is the desk that decides what they are actually allowed to do, and what to check with you first.
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.
Fully autonomous batch agent with no human in the loop at runtime Interactive per-call consent cannot apply; safety must shift to pre-vetted allowlists and hard policy limits instead.
Single trusted read-only server inside a closed internal tool Per-tool prompting adds friction with little benefit when no operation has side effects or touches secrets.
Latency-critical pipeline where every tool call must complete in milliseconds A blocking human approval step is incompatible with the budget; consent has to move to configuration time.
Quick scan · 2–4 min
Everything important, quickly.
4 min: host as trust boundary + three host jobs + the consent granularity spectrum + approval fatigue + allowlisting and its rug pull risk.
Side-by-side
Granularity
User burden
Safety
Best for
Blanket approve-all
None after first prompt
Poor, hides destructive calls
Anti-pattern, avoid
Per-server
Low
Floor, weak inside a server
Trusted single-purpose servers
Per-tool or per-category
Moderate
Strong for side effects
Writes, network, secrets
Per-call always
High, causes fatigue
Strong on paper, weak in practice
Rarely, only highest risk
Real-world examples
Real products, models, and research that use this idea.
1Claude Desktop and Claude Code prompt the user before a discovered MCP tool runs, showing the server origin and tool name.
2Cursor and Zed both gate MCP tool execution through the editor host, so the user approves connection and risky calls.
3The OWASP MCP Top 10 (2025) lists rug pull and tool poisoning as host-side risks that an allowlist alone does not stop.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does allowlisting safe tools interact with a rug pull attack on an MCP server?
Sign in or go Pro to see the approach for this follow-up.
QWhat concrete information must a consent prompt show to make the decision meaningful?
Sign in or go Pro to see the approach for this follow-up.
QHow would you design consent for an autonomous agent that runs many tool calls per task?
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
Assuming the protocol enforces safety. MCP defines no sandboxing or consent. The host is the trust boundary, and a blanket approve all destroys it.