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

Annotations already indicate read-only and idempotent behavior. The description adds crucial details: UNKNOWN means all upstream sources were unreachable (not low risk), rate limit of 60/minute, no auth required, and that it makes a 'parallel call' to multiple sources. These go well beyond annotations and prevent misinterpretation.

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?

The description is longer than average but every sentence contributes: the verdict output, the UNKNOWN clarification, rate limit, auth, usage context, and fallback. It's front-loaded with the core purpose and then provides essential operational details. No fluff, though it could be slightly tightened.

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 tool that combines multiple sources and has an output schema, the description covers all necessary aspects: what it returns, how to interpret the UNKNOWN verdict, rate limit, auth, and when to use it. The presence of an output schema means return details don't need to be spelled out. Nothing essential is missing.

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?

The schema covers the sole parameter cve_id with a description and example, and schema coverage is 100%. The description doesn't add anything about the parameter itself beyond what the schema provides, which meets the baseline for high coverage.

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 states a specific verb ('fetch') and resource ('CVE risk summary'), explicitly lists the data sources (CVSS, CISA KEV, EPSS) and the exact verdicts returned. It clearly distinguishes itself from sibling tools that fetch individual data points like security_fetch_cve_detail or security_fetch_cve_epss.

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?

It explicitly says it is for security engineers triaging vulnerabilities 'after fetch_cve_watch fires', giving a clear context. It also includes a fallback instruction to call report_feedback if the result doesn't meet the need. However, it doesn't explicitly state when not to use it or name alternatives to avoid, but the context is strong.

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