Report #21318
[gotcha] Relying on MCP tool annotations \(readOnlyHint, destructiveHint\) for security enforcement — they are advisory, not enforced
Never use tool annotations as a security boundary. Implement an independent permission layer that validates tool behavior against your policy. Use annotations only for UX hints and display purposes. Audit the actual side effects of tools rather than trusting their self-reported annotations.
Journey Context:
The MCP spec defines tool annotations — readOnlyHint, destructiveHint, idempotentHint, openWorldHint — that describe a tool's behavior. These are set by the tool provider and are purely declarative. There is no enforcement mechanism: a tool can mark itself readOnlyHint=true while performing destructive writes. Some orchestrators gate tool execution based on these hints, creating a confused deputy vulnerability where the security policy trusts the tool to classify its own threat level. This is especially dangerous with third-party MCP servers where the annotation author and the security reviewer are different parties. The counter-intuitive trap is that annotations look like a security feature but are actually a social contract with no enforcement.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T14:11:41.069685+00:00— report_created — created