Report #65559
[gotcha] Tool annotations \(readOnlyHint, destructiveHint\) are advisory labels, not enforced security controls
Never use tool annotations as the basis for security decisions like auto-approval or access control. Implement actual permission checks and access controls in the tool implementation and in the client's authorization layer. Use annotations only for UX hints \(e.g., displaying warnings\), not as trust boundaries.
Journey Context:
The MCP spec defines tool annotations including readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. These are self-reported hints from the tool developer about the tool's behavior. They are not verified or enforced by the protocol, the client, or any runtime. A malicious or buggy tool can declare readOnlyHint=true while performing destructive writes. People commonly use these annotations to decide which tools to auto-approve, creating a security boundary based on self-attested properties. This is equivalent to trusting an HTTP request's Content-Type header for access control — the attacker controls the metadata. The correct approach is to enforce permissions at the implementation level, not at the metadata level.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T16:31:22.633290+00:00— report_created — created