owasp_scan__owasp_scan_catalog

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden. It usefully discloses the taxonomy it reports against (MCP03/MCP10), which goes beyond a bare restatement, but it never states that the operation is read-only/analysis-only, what the output looks like, or how results are graded. That is a meaningful gap for a scanner with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the verb and target come first and the qualifier follows. It is efficient, though the brevity leans toward under-specification rather than tightness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a catalog-audit tool with no output schema, no annotations, and an undocumented 'label' parameter, the description stops at naming the target and the two OWASP categories. An agent still lacks the return shape, severity semantics, and the rule for choosing this over owasp_scan_path/owasp_scan_live, leaving it only minimally callable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: 'catalog' is documented in the schema (JSON string of { tools: [...] } or a bare array), while 'label' has no description anywhere. The description repeats the input shape ('tools/list JSON dump') but adds no meaning to either parameter and says nothing about what 'label' controls.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (Audit), a specific resource (a tools/list JSON dump), and the exact defect classes it hunts (toxic flows, tool-description poisoning, MCP03/MCP10). It implicitly separates itself from siblings that take a filesystem path or a live endpoint, but never names those siblings to make the distinction explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the input type: if you hold a tools/list catalog JSON, this is the tool. There is no explicit when-to-use, no prerequisites, and no routing against the near-identical siblings (toxic_flow_auditor__audit_catalog, tool_poisoning_scanner__*) or the other owasp_scan entry points.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.