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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds substantial behavior that structured fields do not: a 3-page pattern-search bound, a CPE_NOT_FOUND error shape with scanned/total counts, the fact that the upstream search ignores the deprecation filter, and a 7-day cache. These are exactly the operational traits an agent needs to reason about failure and staleness.

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?

Four compact sentences, front-loaded with what is returned, then the key-selection rule, then failure behavior, then caching. Every sentence carries distinct operational information with no repetition of the schema or annotations.

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?

An output schema exists, so return structure need not be explained, and the description instead covers the one output case that matters (CPE_NOT_FOUND). For a two-parameter, read-only lookup with a documented fallback path, nothing needed to invoke it correctly 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?

Schema coverage is 100% and both properties carry descriptions, so the baseline is 3. The description adds real value beyond the schema by declaring cpeNameId 'preferred, exact' versus cpeName, which is only 'resolved by upstream pattern search' — a semantic distinction the schema does not convey.

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 first sentence states a specific verb and resource ('Return one entry of the NVD Official CPE Dictionary'), immediately scoping it to a single-entry lookup. The mention of nvd_search_cpes on failure distinguishes it from the sibling search tools without the agent needing to open 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?

It states the selection rule explicitly: 'Provide exactly one of cpeNameId (preferred, exact) or cpeName', and names the alternative (nvd_search_cpes) for the failure case. It also explains what happens when the exact name is outside the scanned window, so the agent knows the escape hatch.

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 establish read-only, idempotent, non-destructive and open-world, but the description adds behavior they cannot express: a 24-hour cache and a documented degradation path where a stale copy is returned during an NVD outage with a warning surfaced in meta.warnings. That is real operational context about freshness and failure modes.

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?

Three dense sentences with no waste: the payload comes first, the sibling routing second, the caching/outage caveat last. Nothing is repeated and every clause carries new 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?

With an output schema present, return values need not be described, and the description still covers the caching horizon and outage fallback. For a single-record fetch tool with 100% schema coverage and annotations, nothing an agent needs 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?

Schema description coverage is 100%, so the three optional toggles (includeRaw, includeReferences, includeConfigurations) and the cveId pattern are already fully documented in the schema. The description implies the default shape of the record but adds no syntax or default-override guidance beyond it, so the baseline 3 applies.

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 (Return) and resource (the full NVD record for one CVE) and enumerates the payload contents: description, CVSS metrics, CWEs, configurations, references and CISA KEV status. It also explicitly distinguishes itself from nvd_get_cve_summary and nvd_get_cves, so an agent can pick it without opening any 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?

Names two concrete alternatives with the condition that selects each: nvd_get_cve_summary for the essentials and nvd_get_cves for a batch. The full/summary/batch trichotomy is exactly the routing decision an agent needs.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds non-structured behavior: a 1-hour cache and the 120-day maximum window, plus the opaque-cursor pagination model. It does not mention rate limits or auth, so it stops short of a 5.

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 dense sentences, front-loaded with what is returned, followed by filtering, caching, and pagination constraints. No filler and every clause carries operational 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?

An output schema exists, so return values need not be described. For a single-CVE read with nested filter objects, the description covers scope, filters, cache TTL, window limit, and pagination, leaving nothing an agent needs before calling it.

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 cveId, cursor, pageSize, eventName and changeBetween are already fully documented at the schema level. The description restates eventName and changeBetween and the 120-day cap but adds no syntax, default, or format detail beyond the schema, so the baseline 3 applies.

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 ('Return the change history of one CVE') and enumerates the concrete event types returned, so an agent can distinguish it from nvd_get_cve, nvd_get_cve_summary, and nvd_get_modified_cves (which is multi-CVE) without opening any 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?

Usage is implied through the description of filters ('Filter by eventName or changeBetween') and pagination, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative such as nvd_get_modified_cves for bulk change tracking. Adequate but leaves routing to inference.

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 readOnly/idempotent/openWorld, so safety is covered; the description adds non-obvious behavior: identifiers are uppercased, de-duplicated, and only missing/stale entries are fetched (a cache-aware batch read). That is real value beyond the annotations, though it overlaps the output schema by naming the response fields.

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?

Three dense, front-loaded sentences with no filler; the batch limit and routing to nvd_get_cve come early. Minor redundancy in enumerating response fields (foundIds, missingIds, meta.*) that the output schema already exposes.

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 a complete input schema, an output schema, and rich read-only annotations, the description supplies the remaining essentials: batch cap, normalization/dedup semantics, cache behavior, and sibling routing. Nothing needed to invoke it correctly 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?

Schema coverage is 100% and the single param already documents the 1-100 range, case-insensitivity, and de-duplication. The description restates the same normalization/limit facts rather than adding format or syntax detail beyond the schema, so baseline 3 applies.

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 with scope ('summaries for up to 100 CVE identifiers in one call') and explicitly routes the single-record case to nvd_get_cve, which lets an agent separate it from siblings without opening schemas.

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?

Names the alternative (nvd_get_cve for a full record) with the condition that selects it, giving clear batch-vs-single guidance. It stops short of addressing the other siblings (nvd_get_cve_summary, nvd_search_cves, nvd_search_cves), so no explicit exclusions beyond the one alternative.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the result is derived from a cached record sharing a 24 hour freshness window, which tells the agent results may be stale. It does not mention rate limits or auth, but the caching disclosure is the meaningful extra.

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?

Three tight sentences: field inventory first, exclusions and the alternative second, freshness caveat last. Every sentence carries information and nothing is repeated from the schema or annotations.

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 an output schema present, return values need no prose, yet the field list usefully frames the compactness tradeoff. Combined with the named alternative and the cache-freshness disclosure, an agent has everything needed to select and call this 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?

Schema coverage is 100% and there is only one parameter (cveId) with a regex pattern and example already in the schema. The description adds no format or case-handling detail beyond the schema, so the baseline 3 applies.

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 (return) and resource (compact view of one CVE) and enumerates exactly what the view contains (id, timestamps, status, summary, CVSS, CWEs, products, KEV flag, reference count). It also names the sibling it differs from (nvd_get_cve), so an agent can separate the two 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?

It routes the agent explicitly: configurations, references and raw payload are omitted, so 'use nvd_get_cve for those'. That gives a clear condition for choosing this tool versus its sibling. It stops short of stating broader when-not-to-use conditions (e.g., bulk retrieval, history), but the core routing decision is unambiguous.

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?

Goes well beyond annotations: notes the 5-minute cache, that filters are pushed upstream so totalResults is exact, that the resolved window is embedded in the cursor so a relative `days` window stays stable across pages, and the 30-minute cursor TTL. This is exactly the kind of pagination/caching contract an agent needs for a read tool.

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?

Front-loaded with return semantics and ordering, then window rules, then caching and pagination. Four dense sentences, no filler, every clause earns its place.

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 an output schema present, it needn't describe return values, and it covers the operational hazards (caching, cursor lifetime/binding, window exclusivity, upstream filtering) that an agent would otherwise guess wrong. Complete for an 11-param read 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?

Schema coverage is 100% and the schema already documents most params with enums and constraints. The description still adds non-obvious semantics: cursor binding to filters/pageSize/window and cursor stability with relative days, which the schema only partly conveys.

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 precisely what the tool returns (CVEs ordered by last-modified date, newest first) and separates it from siblings like nvd_search_cves or nvd_get_cve by its ordering and windowing behavior. An agent can immediately tell this is the 'recently modified' feed.

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 explains the default window (last 7 days), the exclusive `days` vs `start`+`end` choice, and the 120-day cap. It doesn't explicitly say when to prefer a sibling (e.g. search_cves for keyword-driven queries), so it's clear but not fully routing.

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 readOnly/idempotent annotations, it discloses two non-obvious behaviors: results are cached for 5 minutes (a freshness caveat), and the resolved date window is embedded in the cursor so a relative `days` window stays stable across pages while filters and pageSize are bound. Neither fact is derivable from the annotations or top-level schema.

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 dense sentences, front-loaded with the ordering and default window before pagination mechanics. The parenthetical `("published_desc")` and nested asides add some visual noise but every clause carries operational 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?

With 10 optional parameters, a nested CVSS object, and an output schema present, the description covers the things structured fields cannot: default window, window-size cap, mutual exclusivity, cache TTL, and the exact cursor round-trip protocol. An agent has everything needed to call and paginate 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?

Schema description coverage is 100%, so the parameter baseline is 3. The description exceeds that by stating the cross-parameter constraint (days vs start/end mutual exclusivity, 120-day max) and the default lookback, none of which appear in the per-parameter schema text.

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 and resource ("Return CVEs") plus the ordering dimension ("ordered by publication date, newest first"), which separates it from date-based siblings like nvd_get_modified_cves. It does not explicitly name or contrast any sibling tool (nvd_get_cves, nvd_search_cves), so differentiation is implied by scope rather than stated.

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 gives concrete usage rules: default 7-day lookback, and that `days` and `start`+`end` are mutually exclusive alternatives capped at 120 days. What it lacks is guidance on when to prefer this over nvd_get_cves or nvd_search_cves — no tool-level alternatives are named.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add operational context — and it does: 24-hour caching, cursor-based pagination, and the upstream rejection of partial keywords and version ranges in matchStringSearch. These are non-obvious behaviors an agent cannot infer from the annotations or schema.

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?

Three densely packed sentences with the resource definition front-loaded, then the filter requirement, then the two gotchas (matchString syntax, caching/pagination). No filler, nothing repeated from the schema verbatim.

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 six-parameter, nested-object search with an output schema present, the description covers what the tool returns conceptually, the filter precondition, the pagination mechanics, the cache window, and the input-format trap. An agent can call it correctly without opening anything else.

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 baseline is 3, but the description adds real meaning on top: matchStringSearch must be a complete CPE match string with the cpe:2.3:a:vendor:product:*... form, and the lastModified window is capped at 120 days. It does not add anything further about cursor freshness or pageSize, which the schema already handles.

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 (Search) and resource (CPE Match Criteria) and explains what the resource is: the join that links CVEs to CPE names and version ranges. That implicitly separates it from nvd_search_cpes / nvd_get_cpe, but no sibling is named explicitly and no exclusion is stated.

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?

Gives a hard precondition ('At least one filter is required') and enumerates the four admissible filters plus the 120-day ceiling on lastModified, so an agent knows how to form a valid call. It does not, however, say when to reach for this tool over nvd_search_cpes or how it complements nvd_get_cve.

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?

With annotations already covering read-only/idempotent/non-destructive/open-world, the description still adds substantial non-obvious behavior: deprecated CPEs filtered locally unless includeDeprecated, totalResults being the upstream count that can exceed returned items or be positive with an empty items array, and 24-hour caching. This is exactly the operational context annotations cannot express.

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?

Four dense sentences, all load-bearing, with the core scope stated first and constraints/edge cases after. The totalResults explanation is the longest clause but justifies its length because it prevents a misinterpretation of an empty result set.

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 an 8-parameter, nested-object tool with an output schema, the description covers the prerequisites, the local-vs-upstream filtering split, cache lifetime, and cursor lifetime/binding — everything an agent needs to call it correctly and interpret pagination. Return-value shape is rightly left to the output schema.

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 100%, so the baseline is 3, but the description adds genuine cross-parameter semantics: cursors must be reused with the same filters and pageSize, the 120-day cap on the date window, and that includeDeprecated is a local filter reflected in meta.filteredOut. keywordExactMatch and cpeMatchString get no extra narrative, but the schema already documents them.

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 ("Search the NVD Official CPE Dictionary") and enumerates the four filter modes (keyword, match string, criteria UUID, last-modified window), so the agent knows exactly what the tool operates on. It is clear it deals with the CPE Dictionary rather than CPE matches, but it never names the nearest sibling (nvd_search_cpe_matches or nvd_get_cpe) to harden the boundary.

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?

"At least one filter is required; date windows are limited to 120 days" gives a firm precondition the agent must satisfy before calling. It stops short of routing guidance — no statement of when to prefer nvd_get_cpe or nvd_search_cpe_matches instead — so the alternative-selection layer is missing.

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 read-only, idempotent, open-world behavior, so the description need not restate safety. It adds genuinely non-obvious traits: results are cached for 15 minutes, and NVD evaluates every filter so totalResults is the exact upstream total, plus how to paginate via nextCursor. Missing details like rate limits or cache-staleness implications keep it below 5.

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?

Three sentences, front-loaded with purpose then rules then caching/pagination, with no filler. The opening filter enumeration slightly overlaps with what the schema already lists, so it is not maximally economical, but every clause carries usable 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 19-parameter, nested-object tool with an output schema present, the description covers the essential non-schema gaps: constraint interactions, window caps, caching, exactness of totals, and pagination mechanics. An agent can call it correctly without opening the schema, though sibling routing is the one untouched area.

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 95%, so the baseline is 3, but the description adds cross-parameter semantics the schema only partially encodes: the keyword/keywordExactMatch and cpeName/isVulnerable dependencies, the exclusivity pair, and the shared 120-day window limit. It also clarifies that statuses and filters are applied upstream by NVD, which is meaning beyond the field-level text.

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+resource ('Search CVE records') and enumerates the exact NVD 2.0 filter dimensions the tool accepts, so the agent knows precisely what surface it covers. It is clearly distinct from get-style siblings in name and behavior, but never explicitly names those siblings or contrasts itself with them, keeping it 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?

The 'Rules' sentence gives real operational constraints (keywordExactMatch requires keyword; isVulnerable requires cpeName; cpeName/virtualMatchString mutually exclusive; 120-day windows) and explains pagination. However, there is no guidance on when to choose this over sibling tools like nvd_get_cves or nvd_get_recent_cves, which is the main 'when-to-use' question for a search tool.

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