A trusted internal server publishes a tool whose annotations set readOnlyHint to true and destructiveHint to true. A host developer wants to know how to interpret this combination. What does the specification say?
Select an answer to reveal the explanation.
Short Explanation
If a door is labeled "no entry," a second sign about how to wipe your feet inside doesn't matter. Once readOnlyHint is true, destructiveHint has nothing to describe. The trap is assuming the scarier label wins.
Full Explanation
The tool annotation definitions are layered. readOnlyHint, default false, says whether the tool modifies its environment. destructiveHint, default true, says whether a modifying tool may perform destructive updates rather than only additive ones, and the schema notes that it is meaningful only when readOnlyHint is false. idempotentHint, default false, has the same condition. With readOnlyHint true the tool claims not to modify its environment at all, so destructiveHint has nothing to qualify and the tool is described as read-only. Saying destructiveHint overrides readOnlyHint inverts the defined relationship; there is no override rule. Dropping the tool as invalid has no basis either, because the specification defines no conflict check for annotations and clients exclude tools only for specific defined problems, such as an invalid x-mcp-header on Streamable HTTP. Inferring idempotency from the pair invents meaning; idempotentHint is its own field and is also ignored when readOnlyHint is true. Exam caveat: the scenario says the server is trusted; from an untrusted server, all annotations are hints that should not drive tool-use decisions. Operational check: review the server's annotations and ask its maintainers to remove the meaningless destructiveHint so humans reading the definition are not confused.