A host team is designing the user experience for a delete_customer_records tool exposed by an MCP server. Which design best follows the specification's trust and safety guidance for tool invocation?
Select an answer to reveal the explanation.
Short Explanation
Think of a bank asking "Are you sure you want to send $5,000?" before the money moves, not after. Visible indicators plus a prompt you can say no to keep the human in charge. The trap is believing the protocol itself will stop a destructive tool.
Full Explanation
The tools specification says that, for trust and safety, there should always be a human in the loop with the ability to deny tool invocations. Applications should provide UI that makes clear which tools are exposed to the model, insert clear visual indicators when tools are invoked, and present confirmation prompts for operations. The core security principles add that hosts must obtain explicit user consent before invoking any tool. A visible indicator with a deniable confirmation prompt satisfies all of that for a destructive tool. Roots never enforced access control; they were informational boundaries, are deprecated in this revision, and are not a confirmation mechanism. Relying on destructiveHint alone fails because annotations are untrusted hints and the protocol enforces nothing on their basis; MCP itself cannot enforce these security principles, so the host must. Running the call before asking reverses the order of consent, and an undo offer is no protection when records are permanently deleted. The model-controlled label means the model may propose invocations, not that it may act without the user. Exam caveat: consent UI belongs to the host, so a server cannot rely on it being present and must enforce its own access control. Operational check: invoke the tool in a test session and confirm a deny choice prevents any tools/call from being sent.