MCP Security: Most Destructive Tools in Docker's MCP Catalog Carry No Safety Hint
Your agent is about to call delete_all_integrations. Does it know that's dangerous?
Often, it doesn't. MCP gives every tool a way to say "I'm destructive" or "I only read": the
destructiveHint and readOnlyHint annotations. We looked at about 20,000 tools across two public
catalogues to see how often servers use them. In Docker's MCP Catalog, 69% of tools that delete or
overwrite something carry no safety hint at all, and only a quarter say they're destructive. So for
MCP security, an agent or a client can't treat a missing hint as a safe one, and it can't take a hint
on trust either.
What tool annotations are for
An MCP server lists its tools with a name, a description, an input schema and, optionally, a few annotations:
| Hint | Meaning |
|---|---|
readOnlyHint | The tool doesn't change anything |
destructiveHint | The tool may delete, overwrite or revoke something |
idempotentHint | Calling it twice has the same effect as once |
openWorldHint | The tool reaches systems outside the server, such as the web |
Clients can use these to decide when to ask a person before running a tool: a tool that says it only reads might run straight away, while one that says it's destructive gets a confirmation prompt. The MCP project's own post, Tool Annotations as Risk Vocabulary, explains what the hints can and can't do, and notes that "many servers ship without them". We wanted to know how many.
What we measured
We read public catalogue metadata only. We never connected to or called anyone's server.
| Source | Servers | Tools | What it gave us |
|---|---|---|---|
| Docker MCP Catalog | 259 | 4,902 | Curated servers you install yourself, with each tool's annotations |
| Glama hosted connectors | 999 | 15,314 | Hosted servers, with annotations captured from each server |
| Official MCP Registry | 38,145 | — | Remote endpoints and the credentials each server asks for |
To find destructive tools, we classified every tool by its name and description, using published keyword rules. We checked the rules against 200 hand-labelled tools they had never seen: 91% of the tools they mark destructive are destructive. The full method is at the end of this post.
Finding 1: most destructive tools carry no hint
In Docker's catalogue we found 292 destructive tools on 68 servers. Only 73 (25%) declare
destructiveHint: true. 201 (69%) declare no hint of any kind, so a client has nothing to go on but
the tool's name.
Across all tools in the catalogue, the picture is the same: 31% of tools carry any annotation, and three in four servers don't annotate a single tool.
Finding 2: hosted connectors are far more disciplined
Glama's hosted connectors tell a different story. 88% of their tools carry annotations, and 87% of
destructive tools declare destructiveHint: true.
Glama captures these hints from each server rather than adding its own, so the gap is real. It also has a likely cause: hosted connectors go through an onboarding step before they're listed, and the ones we sampled lean toward well-maintained listings. If you run servers you installed yourself, the Docker numbers are closer to what your agents see.
Finding 3: a hint can be wrong, and stay wrong
Hints are only as good as the code that sets them. In Docker's catalogue we found one server that marks
15 delete and remove tools as readOnlyHint: true, destructiveHint: false, among them "delete a user
account", "delete a secret" and "delete ALL consumer-provider integrations in the workspace".
Nobody set those hints by hand. The tools didn't declare any, so a framework default marked every one of them read-only. The vendor fixed it upstream within a week. But the catalogue still pins the earlier version three months later, so anyone installing the server from it gets the mislabelled tools today. A client that trusts the hints would treat "delete all integrations" as a harmless read.
The MCP specification anticipates this. It says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers" (MCP spec, Tools).
Finding 4: a quarter of servers need a secret
In the official MCP Registry, 24% of the 38,145 servers ask for at least one secret, usually an API key or token, before they'll run. Every one of those is a credential an agent's host holds on your behalf. Of the remote servers, only 17% declare a credential header in their registry entry. That doesn't mean the rest have no authentication, since OAuth doesn't appear in registry entries, but it does mean you can't read a server's auth model from the registry alone.
What to do about it
None of this is a reason to avoid MCP. It's a reason to decide, in one place, what an agent may do, rather than trust each server to describe itself.
- Treat a missing hint as "unknown", not "safe". In Docker's catalogue, two-thirds of destructive tools say nothing. Default to asking before a tool you haven't classified.
- Don't take a hint on trust. Our third finding is a case where the hint was the problem. Check what a tool does against its name and description, and confirm destructive actions however they're labelled.
- Pin and review the servers you run. Catalogues can lag behind upstream fixes. Know which version you have.
- Enforce policy outside the server. Route tool calls through an AI gateway that applies your own rules: which tools a workspace may call, which need a human's approval, and a record of every call. That works whether or not a server annotates its tools, and whether or not the annotations are right.
DVARA, an AI gateway for model, tool and agent calls, does the fourth: it allows or denies each tool call by policy, can hold a call for approval, redacts personal data in results, and audits every call. You can try it in five minutes with no licence key.
Method
- Sources and dates: Docker MCP Catalog v3 and per-server tool files (MIT licence), Glama MCP API connector records, and the official MCP Registry API, all collected on 2 Oct 2026. Tool data from Glama is credited to Glama. Glama returned 1,000 connectors, which may be a cap on the list rather than its full size.
- Excluded: Glama's self-hosted servers (its API returns no tool lists for them) and Smithery (we couldn't find published terms of use).
- Destructive tools were found with keyword rules on each tool's name and description, tuned on 200 hand-labelled tools and then frozen. On a separate 200-tool validation sample, labelled before seeing the rules' answers, the rules scored 91% precision for destructive tools, 92% for read-only, 84% for write and 80% for code execution. Other classes we tried (payments, external messaging, secrets, personal data) weren't accurate enough to report. One person labelled both samples.
- Annotation counts use each server's own declarations and need no classifier.
- The read-only delete tools in Finding 3 were checked by hand against the catalogue records and the vendor's public fix.
- We report aggregates only and name no server as an example.
Related work: How are AI agents used? Evidence from 177,000 MCP tools classifies MCP tools by what they do, but doesn't look at annotations.
Tool data: Glama (glama.ai). Docker MCP Catalog data is MIT-licensed.