A security lead assumes that because a deployment uses MCP, the protocol itself will stop a tool from running unless the user has approved it. What does the specification actually say?
Select an answer to reveal the explanation.
Short Explanation
MCP is like a road with lane markings, not a traffic cop. You're told users must consent before tools run, but the spec says plainly the protocol can't enforce that — your host has to ask. Don't let 'annotations' or 'capabilities' sound like a safety lock.
Full Explanation
The specification's security section sets out key principles: users must explicitly consent to and understand data access and operations, hosts must obtain explicit user consent before invoking any tool, and tools represent arbitrary code execution. It then states that MCP itself cannot enforce these security principles at the protocol level, so implementors SHOULD build robust consent and authorization flows into their applications. The tools specification adds that there SHOULD always be a human in the loop able to deny tool invocations. A signed user-approval token in _meta is not defined anywhere in the protocol; no such field exists, so servers cannot be required to check one. Tool annotations such as destructiveHint are hints that describe behaviour, and clients must treat them as untrusted unless they come from a trusted server; they never pause execution by themselves. Client capabilities declare which features the client supports for a request, such as elicitation, and say nothing about whether a user approved a call. Exam caveat: authorization on HTTP controls whether a client may access a server, which is different from a user approving a specific tool invocation. Operational check: verify the host shows tool inputs and requires confirmation for sensitive operations before any tools/call leaves the client.