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

Annotations only cover the read-only/idempotent profile; the description adds substantial context beyond them: the exact paid x402 request, $0.003 per-call price, refund protection ('Bad input is refused before any charge'), and the P0 access-key path that makes the paid call transparently.

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?

Purpose and scope are front-loaded in the first clause, and the payment details follow logically. The lengthy key-purchase URL makes it dense, but each element (price, refusal-before-charge, key flow) carries real operational value.

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?

Despite having no output schema, the description names the returned fields (date added, due date, vendor, product) and fully explains the two-step x402/MPP payment flow, so an agent knows both what it gets back and how to actually obtain the data.

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 description coverage is 100%, so 'since' format, pattern, and lower bound are already documented, and the description's restatement of since=YYYY-MM-DD adds little. It also says results are newest-first, which is return ordering rather than parameter meaning, and never mentions 'limit'.

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?

States a specific verb and resource: CVEs CISA added to the Known Exploited Vulnerabilities catalog since a date, newest first. An agent can distinguish this from the sibling vuln_cve lookup without opening either schema.

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?

Opens with an explicit 'Use when you track exploited vulnerabilities' trigger. It does not name when-not-to-use or point at vuln_cve as the alternative, so it stops short of full routing guidance.

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