Why readOnlyHint in MCP Isn't Enough to Block Destructive Tools
An in-depth look at MCP tool annotations where 69% of destructive tools lack hints and why policy gateways are necessary for security.
Stock photo for illustration only, not from the actual event
- MCP uses hints like readOnlyHint and destructiveHint for tool self-description.
- Critical issues arise because hints are frequently missing or completely wrong.
- 69% of deleting tools in Docker's MCP Catalog carry no security hint at all.
- The safer architectural approach is enforcing policies at a controlled gateway.
The Model Context Protocol allows tools to describe themselves through hints. A readOnlyHint: true indicates safe reading, while destructiveHint: true warns about deletion or overwriting. Clients use these hints to decide when human intervention is required before tool execution.
However, two major flaws undermine this practice in real-world scenarios. First, the hint is often missing entirely. An analysis of roughly 20,000 MCP tools for a report on tool annotations showed that 69% of tools capable of deleting or overwriting data in Docker's MCP Catalog carry zero hints.
Second, hints can be entirely incorrect. One catalog server incorrectly marked 15 deletion tools as read-only, including delete ALL integrations. Because the tools lacked explicit settings, a framework default applied readOnlyHint: true to all of them automatically. Although fixed within a week, the catalog continued serving the outdated version for three months.
"For trust & safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers."
Official MCP Specification
Consequently, the MCP specification dictates that for trust, safety, and security, clients must treat tool annotations as untrusted unless sourced from trusted servers. The decision of what an agent is permitted to execute should never rely on the tool's self-description.
Stock photo for illustration only, not from the actual event
From an AI security perspective, relying on third-party tool self-reporting is akin to letting actors self-certify their safety compliance. Centralizing enforcement through an independent gateway running explicit governance policies represents a vital architectural pattern to mitigate catastrophic risks in automated agent workflows.
Using the DVARA MCP quickstart framework allows developers to route agent traffic through a managed gateway, applying strict workspace rules—such as blocking irreversible actions like delete_customer—regardless of what self-reported annotations claim.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment