Report #5582
[gotcha] readOnlyHint tool performed a destructive write — why are tool annotations not enforced?
Never rely on MCP tool annotations \(readOnlyHint, destructiveHint, idempotentHint, openWorldHint\) for access control or safety decisions. Implement your own enforcement layer that validates tool behavior independently — for example, by wrapping tool execution in a policy engine that checks actual side effects, not self-reported hints. Treat annotations as UI documentation only.
Journey Context:
The MCP spec explicitly defines annotations as advisory hints for client UIs, not as guarantees or enforced constraints. A server can mark a tool with readOnlyHint: true while it actually deletes records. Agents that gate unattended execution on readOnlyHint are trusting a self-reported, unverified claim from the tool provider — equivalent to trusting an HTTP client's self-reported Intent header. The common mistake is building safety-critical branching logic around these hints because they feel like a type system when they are actually honor-system labels.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T21:42:01.609907+00:00— report_created — created