No destructive tools in the public surface
Authored by Stanley Hong · AgentReserve (founder).
No advertised tool matches destructive data verbs (delete, drop, purge, wipe, destroy, truncate). Destructive actions are typically irreversible and should be exposed under explicit, scoped authorization rather than a default `tools/list`.
When this rule runs
Requires a successful MCP `initialize` / `tools/list`. Skipped on perimeter-only scans where the server refused or failed the MCP handshake.
Why it matters
Destructive actions are typically irreversible. Surfacing them in a public `tools/list` means any agent that connects to the server can request them; review and authorization belong before that point, not after.
Pass condition
No advertised tool's name, description or schema fields match a destructive verb (delete, drop, purge, wipe, destroy, truncate, …).
Fail condition
At least one tool surfaces a destructive verb in its name, description, or input schema.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"destructiveTools": [{"toolName": "delete_record", "verb": "delete", "source": "name"}]}
Remediation
Move destructive tools off the public `tools/list` and behind an explicit, scoped authorization step — or split the server into a read-only public endpoint and an authenticated admin endpoint.
Methodology
This rule belongs to the Tool surface risk dimension. What an agent could do if it trusted every advertised tool. Covers destructive actions, credential disclosure, code execution, filesystem mutation, PII handling, prompt-injection-shaped input fields, and injection-bearing tool descriptions — i.e. the agent-specific threat surface, not just generic verb risk.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.