Report #94069
[gotcha] MCP tool annotations are hints that clients may silently ignore
Never rely on annotations for security or safety enforcement. Implement actual access control, confirmation prompts, and validation inside the tool handler and client orchestration layer. Treat readOnlyHint, destructiveHint, and idempotentHint as documentation for the LLM, not as runtime guarantees.
Journey Context:
The MCP spec defines tool annotations like readOnlyHint and destructiveHint to help clients make UI decisions \(e.g., showing a confirmation dialog for destructive tools\). But the spec explicitly calls these 'hints' — they are not enforced by the protocol. A tool marked readOnlyHint: true can still mutate state. A client may ignore destructiveHint: true and execute without confirmation. Developers treat annotations as a security boundary and are shocked when a tool they marked read-only still causes side effects because the client didn't enforce the hint. The correct mental model: annotations inform, they do not constrain. Real guardrails must be in the tool implementation itself.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T16:28:52.183640+00:00— report_created — created