How should a host handle user consent before invoking a tool or accessing a resource?
Quick Answer
The MCP spec's guiding principle is that hosts must obtain explicit user consent before invoking a tool, and should give users clear visibility and control over data shared with servers — this isn't automatically enforced by the protocol itself (a server can't force a host to prompt), so it's an implementation responsibility every host takes on. In practice this typically means: an initial approval step when a server is first connected (showing what it can do), per-call or per-session confirmation before invoking tools flagged as risky (particularly ones annotated destructiveHint: true), a way for the user to review what data/context is being sent to a given server, and the ability to revoke a server's access at any time. Because tool annotations are self-reported hints (covered earlier) rather than guarantees, well-designed hosts don't rely on annotations alone to decide when consent is truly needed for a genuinely untrusted server — they layer in additional judgment, like requiring confirmation more broadly for newly installed or less-trusted servers.
Detailed Answer
MCP the protocol doesn't, and can't, force a host to ask permission. Consent is a host implementation responsibility the spec calls out explicitly as expected behavior, not something baked into the wire format.
What the spec expects, at a high level
- Tool invocation consent: users should understand what a tool does before it runs on their behalf. Hosts should implement appropriate confirmation flows for it.
- Data-sharing visibility: users should have clear visibility into and control over what data is shared with connected servers, not just at connection time, but as an ongoing property of the session.
- Sampling requests (the client-side primitive from the previous topic) similarly need user awareness and control, since the server is asking to spend the user's model access and potentially see conversation context.
A layered consent design in practice
Server connection time:
- Show what tools/resources/prompts this server offers before enabling it
First tool call from a new/untrusted server:
- Require explicit confirmation, showing the exact arguments
Subsequent calls to the same tool:
- Depending on host policy, may auto-approve reads,
but re-confirm anything destructiveHint-annotated
Ongoing:
- Let the user see/revoke which servers are connected and what
they've been invoked to do
Why annotations alone aren't a sufficient consent mechanism
A readOnlyHint: true annotation is a claim the server makes about itself, and as covered earlier, a dishonest or compromised server can lie about it. A host that auto-approves every readOnlyHint: true tool call with no further scrutiny is extending trust based entirely on the server's own self-report. Reasonable practice weighs consent requirements not just by declared annotations, but by the server's actual trust level. A well-known, vetted server might reasonably get lighter-touch confirmation than one the user just installed from an unknown source, regardless of what that server's tools claim about themselves.
The tension this creates
Prompting for every single tool call quickly becomes unusable friction. Never prompting removes the safety net entirely. Most hosts land somewhere in between: confirming meaningfully risky actions and giving users session-level visibility and control, while allowing low-risk, frequently-used, well-understood tools to run with less friction. Getting this balance right is genuinely one of the harder open UX problems in building an MCP host, not something the protocol spec fully resolves for you.