KEVWire

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond them by stating the payload contents — every source, measurement date, CISA deadline, and a permalink — which tells the agent this returns a complete, self-contained evidence bundle rather than a summary. It stops short of noting behavior for missing IDs or payload size.

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?

One sentence, no filler, identifier forms and return contents both front-loaded. Nothing could be removed without losing information.

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 single-parameter read tool with no output schema, the description covers the two things an agent must know: what to pass and what comes back. Missing only edge-case behavior (nonexistent IDs, ambiguous IDs matching more than one scheme).

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 0% — the single 'id' property is a bare string with only maxLength — so the description carries the burden, and it does: it names the three accepted identifier schemes. It would earn a 5 with concrete format examples such as CVE-2024-1234 or whether prefixes are case-sensitive.

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?

A specific verb ('Fetch') and resource ('record') plus the three accepted identifier families (CVE ID, GHSA ID, KEVWire record ID) that define what records exist. It is distinguishable from the siblings by inference — it is the by-ID lookup, not a listing or search — but it never names search_vulnerabilities or recent_exploited 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: the enumerated ID formats signal 'use this when you already have an identifier,' while search_vulnerabilities is left for the discovery case. There is no explicit when-to-use/when-not statement or precondition (e.g., what happens on an unknown ID).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely behavioral point beyond that: each source carries limitations and retrieval status, warning the agent that ingested data may be partial or stale and that it should qualify coverage claims accordingly.

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?

Two sentences, zero filler. The returned-field summary comes first so the agent learns what it gets before the usage hint, which is the right front-loading for a zero-arg list tool.

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 must sketch the return shape, and it does so by enumerating the per-source fields (scope, limitations, status, last success, counts). Slightly more detail on whether results are paginated or how many sources typically return would make it complete, but it is sufficient to call correctly.

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 tool takes zero parameters, so there is no parameter semantics burden; baseline 4 applies. The description correctly does not invent arguments or filtering options.

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 the specific resource (every source KEVWire ingests) and the fields surfaced for each (scope, limitations, retrieval status, last success, record counts), which is far more than a restatement of the name. It does not explicitly contrast with siblings like list_technologies or get_record, but the resource is unambiguous enough to route on.

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?

"Use this to describe coverage honestly" gives a directional hint about the intent (coverage reporting) but not a concrete trigger condition, prerequisites, or named alternatives. The agent can infer it is the discovery/status entry point, but that is inference rather than guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful fact that each label is returned with a record count, but says nothing about default ordering, truncation, or what the limit does when the list is large.

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?

Two short sentences with no filler, and the highest-value information (what the labels are, what they carry) is front-loaded.

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 simple read-only enumerator this is roughly adequate, but with no output schema the description should have characterized the response shape more (e.g., how counts relate to limit/truncation) and explained both parameters.

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 0%, so the description must carry parameter meaning; it covers only the text filter via "optionally filter by text." The limit parameter (default 100, max 500) is entirely undocumented in both schema and description.

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?

It states the resource (technology labels), the usable purpose (filters), and what each entry carries (record counts), so the agent knows exactly what comes back. It does not name or contrast with any sibling tool, so it stops short of a 5.

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?

"Usable as filters" implies when an agent would want this list, and "optionally filter by text" hints at narrowing, but there is no explicit when-to-use/when-not guidance and no mention of list_sources or search_vulnerabilities as alternatives.

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

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

The readOnlyHint=true and openWorldHint=false annotations already cover the safety profile. The description adds useful behavioral context by naming the exploitation sources (CISA KEV or explicit reporting), the recency window, and the urgency ordering, but it does not describe pagination or result format.

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 definition is a single, front-loaded sentence with no redundant or filler text. Every phrase contributes to scope, source, recency, or ordering.

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 simple read-only retrieval tool, the description covers the core domain well and annotations cover safety. However, with no output schema and 0% parameter description coverage, it leaves gaps around the 'limit' parameter and the shape of the returned results.

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 0%, so the description must compensate for two undocumented parameters. It clarifies that 'days' controls the publication recency window, but it never explains the 'limit' parameter or what the defaults and maximums mean.

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 resource and scope: vulnerabilities with documented exploitation, within the last N days, ordered by urgency. It is clear what the tool returns, but it does not explicitly distinguish itself from the sibling search_vulnerabilities tool.

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 scope implies when to use it, namely for recent, documented-exploited vulnerabilities, but there are no explicit when-to-use or when-not-to-use instructions. It also does not name alternatives such as search_vulnerabilities for broader queries.

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

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

Beyond the `readOnlyHint`, the description reveals critical behavioral traits: the specific data sources consulted (CISA KEV, NVD, GitHub advisories, etc.) and the complex, tiered logic of the default sorting algorithm. This is behavioral context not present in the structured annotations.

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 highly effective. It packs a lot of information into two sentences—defining the scope and then detailing the default execution logic—without becoming overly verbose or repetitive.

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?

The description provides all the necessary context for an agent to understand the scope of its search, its limitations (it searches specific public repositories), its default logic, and even guarantees the inclusion of source URLs in results. This is highly complete for a search tool.

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?

Given the low schema description coverage (43%), the description is vital. It clarifies that the `query` can handle CVE IDs, products, or event names, and most importantly, it explains the entire logic behind the `sort` parameter's default 'urgent' setting.

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 specifies the resource ('KEVWire corpus') and the exact actions ('Search the KEVWire corpus'). It explicitly mentions the types of data searched (CVE, advisories, breaches), making the purpose crystal clear and distinct from listing or retrieval tools.

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 provides clear guidance on default behavior, stating that the default sort order prioritizes urgency (last 30 days, exploitation, CVSS 9+, breaches). This provides a strong context for how the tool behaves without user intervention.

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