cisa_kev_list

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

Annotations already establish readOnlyHint=true, so the safety profile is known. The description adds context by stating it 'Returns all actively exploited CVEs' and lists the entry fields (CVE ID, vendor, product, etc.). However, it does not disclose potential response size, pagination behavior, or any rate limits, leaving some behavioral uncertainty for a potentially large dataset.

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 four sentences, front-loaded with the tool's core purpose. Each sentence provides distinct value: purpose, return scope, entry composition, and filter capability. No fluff or redundant restatement of the name.

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?

With no output schema, the description compensates by listing return fields and filter options. It covers the essential information for a list-retrieval tool. However, it doesn't mention potential large payloads or any limits, which would be useful for a catalog with 'all actively exploited CVEs.' Still, the description is adequately complete for basic usage.

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 the schema already documents all five parameters. The description adds a grouping phrase ('narrow results by vendor, product, or date range') but omits ransomware_only. Since the schema fully explains each parameter, the description is not required to compensate; baseline 3 is appropriate.

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 opens with a specific verb+resource: 'Get CISA Known Exploited Vulnerabilities with mandatory federal remediation deadlines.' It clearly differentiates from siblings like nvd_cve_search by focusing on the CISA KEV catalog and explicitly listing the returned fields. The purpose is unmistakable.

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?

The description provides clear context for when to use the tool: when you need CISA KEV data with federal remediation deadlines. It does not explicitly mention alternatives or when not to use it, but the unique scope (CISA vs NVD) is implied. This fits 'clear context, no exclusions'.

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