An engineer argues that because MCP tools are model-controlled, adding an approval step before a destructive tool runs would work against the protocol's design. Evaluate that argument.

The principle — Who initiates an action and who authorises it are two separate questions, and a protocol can answer them differently without contradicting itself.

Why the key is correct — Tools are model-controlled, meaning AI models can discover and invoke them automatically. That sentence settles initiation and nothing else. On authorisation the documentation is unambiguous and goes further than permission: for trust and safety and security, there should always be a human in the loop with the ability to deny tool invocations. It also states the mechanism in the same breath — tools may require user consent prior to execution, helping to ensure users maintain control over actions taken by a model. An approval step before a destructive call is therefore not a deviation from the design; it is the design working as written.

Why the others are wrong — Pushing the guard into the server's own logic misplaces it: the server cannot know what the user intended, and the specification asks the human-facing side to hold the veto. Claiming no approval mechanism exists contradicts the consent sentence directly. And confining oversight to resources inverts the risk — resources are read, while tools act.

Remember this — Model-controlled means the model asks. It never meant nobody may say no. The distinction is worth carrying into any tool-using system, not just this one: the component that decides an action is worth taking is rarely the right component to decide it is safe to take, and the specification's habit of naming both roles separately is what keeps the two from collapsing into one.

Sources — MCP first-party documentation.