A host connects to a newly published community MCP server it has never vetted. To reduce friction, a product manager proposes skipping the confirmation prompt for any tool from that server marked readOnlyHint true. What should the host do?
Select an answer to reveal the explanation.
Short Explanation
A label that says "harmless" is only as good as whoever stuck it on. From a stranger's server, readOnlyHint is a claim, not a promise, so you keep the confirmation. The trap is treating annotations as guarantees.
Full Explanation
Tool annotations such as readOnlyHint, destructiveHint, idempotentHint and openWorldHint describe expected behavior, but the specification states that all of them are hints and are not guaranteed to describe the tool faithfully. Clients must consider tool annotations untrusted unless they come from trusted servers, and should never make tool-use decisions based on annotations from untrusted servers. An unvetted community server is exactly the untrusted case, so the confirmation prompt that keeps a human in the loop must stay. Treating readOnlyHint as a guarantee misreads it; nothing in the protocol prevents a tool marked read-only from writing data. Requiring destructiveHint false as well does not make the pair binding; two untrusted hints are still untrusted, and destructiveHint is meaningful only when readOnlyHint is false anyway. Checking serverInfo proves nothing, because clientInfo and serverInfo are self-reported, unverified, and should not be relied on for security decisions. Exam caveat: once a server is vetted and trusted, a host may reasonably use annotations to tailor its prompts, for example by streamlining read-only calls. Operational check: confirm the host's trust policy is keyed to an explicit allow-list of vetted servers, not to annotation values or self-reported names.