CISA KEV with BOD 26-04 deadlines, SSVC prioritization, and the ICS advisory corpus (CSAF). Keyless.
Scored across 7 tools
Each tool has a distinct role: KEV lookup vs KEV search, ICS advisory search vs advisory detail, recent-feed listing, SSVC enrichment, and reference vocabulary. Even where domains overlap (e.g., check_cve_status and search_kev), the input styles and outputs are clearly differentiated.
All tools use a consistent cisa_ prefix followed by a verb_noun pattern (check_, get_, list_, search_). The verbs accurately reflect each operation and no mixed casing or vague generic names appear.
Seven tools is a well-scoped count for the domain: two KEV tools, two ICS advisory tools, one alerts feed tool, one SSVC tool, and one shared vocabulary/reference tool. Each tool earns its place without bloat.
The KEV and ICS advisory workflows are well covered end-to-end, and the SSVC enrichment is supported by a reference tool. The only notable gap is that CISA alerts are limited to a rolling 30-item feed with no detail retrieval, pagination, or history search, so non-ICS alerts cannot be fully investigated.
Check CVE IDs against the CISA Known Exploited Vulnerabilities catalog — up to 200 per call, served from a cached catalog snapshot at no upstream cost. Returns, per CVE, whether it is in KEV and if so the date added, the federal remediation due date, days remaining or days overdue, which binding operational directive the entry cites, the required action text, whether it is linked to ransomware campaigns, whether it falls in the three-day forensic-triage tier, CISA's own vendor and product labels, associated CWEs, and the reference URLs parsed from the entry's notes. A CVE that is not in KEV is a normal result, not an error. The CWE IDs returned chain directly into cisa_search_kev's CWE filter, and the parsed NVD reference gives the canonical record for scoring detail.
| Name | Required | Description | Default |
|---|---|---|---|
| cveIds | Yes | CVE identifiers to check, up to 200 per call. The whole batch costs zero upstream requests, so a full CVE alias list from a dependency audit can be checked in one call. |
| Name | Required | Description |
|---|---|---|
| asOf | No | The UTC date daysUntilDue and overdue were computed against, YYYY-MM-DD. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when none of the supplied CVE IDs are in the catalog. |
| catalog | No | Which catalog snapshot answered this call. |
| results | No | One result per requested CVE, in the order supplied. |
| foundCount | No | How many of the requested CVEs are in the catalog. |
| notFoundCount | No | How many of the requested CVEs are not in the catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important non-obvious behavior beyond the readOnly/idempotent annotations: results come from a cached catalog snapshot with no upstream cost, a CVE absent from KEV is a normal result rather than an error, and the response includes derived fields such as days remaining/overdue and triage tier. No contradiction with annotations exists.
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 dense and front-loaded, leading with the core operation and batch constraint before enumerating return details. The long list of returned fields is informative but somewhat redundant given an output schema exists, so it is slightly broader than strictly necessary.
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 one-parameter, read-only, idempotent tool with an output schema, the description covers input limits, performance characteristics, non-error semantics for missing CVEs, and integration with cisa_search_kev's CWE filter. No critical operational detail appears 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 input schema already documents cveIds thoroughly, including pattern, min/max items, and whitespace/case normalization. The description reinforces batch semantics and the dependency-audit use case but does not add substantial new parameter-level meaning beyond that 100% schema 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?
States a specific operation and resource: checking CVE IDs against the CISA KEV catalog in batches of up to 200. The description also differentiates this from cisa_search_kev by emphasizing status checking and downstream chaining through CWE IDs.
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?
Clearly frames when this is useful, such as checking a full CVE alias list from a dependency audit in one call, and notes the cached-snapshot/no-upstream-cost behavior. It does not explicitly enumerate when to prefer sibling tools, but the batch-checking focus and the chaining hint toward cisa_search_kev give adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one CISA industrial control system advisory in full: affected products flattened from the CSAF product tree into vendor, product, and version ranges; per-CVE CVSS score, vector, and CWE; remediations with their category and vendor instructions; critical-infrastructure sectors; and the revision history. Large advisories return a section outline instead of the whole document — re-call with the sections you need. Republished vendor advisories carry the originating vendor's text; every response reports the source URL and attribution. Find advisory IDs with cisa_search_ics_advisories.
| Name | Required | Description | Default |
|---|---|---|---|
| sections | No | Sections to return. Omit for the whole document, or for its outline when the document overflows the inline budget. | |
| advisoryId | Yes | Advisory identifier, e.g. ICSA-26-260-07 or ICSMA-26-253-02. Case-insensitive; an optional revision suffix is a single letter a-f or a numeric -N. A trailing .json is stripped. |
| Name | Required | Description |
|---|---|---|
| kind | No | full when the document is returned; outline when only the section listing is. |
| error | No | Present when the call failed. Absent on success. |
| found | No | Whether an advisory with that ID is in the index. |
| summary | No | Narrative notes and sector classification. |
| advisory | No | Advisory identity, dates, and attribution. Always kept, including on a section selection. |
| guidance | No | What to do instead, present when found is false. |
| products | No | Affected products and version ranges. |
| sections | No | Outline arm — the sections available, largest first, with their byte sizes. |
| references | No | Document-level references. |
| outlineNotice | No | Outline arm — how to call cisa_get_advisory for specific sections. |
| acknowledgments | No | Acknowledgment entries. |
| revisionHistory | No | Revision history, oldest first as published. |
| vulnerabilities | No | Vulnerabilities the advisory covers, with scores, remediations, and product status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral detail beyond that: large advisories return an outline instead of the full document, republished vendor advisories contain the originating vendor's text, and every response reports the source URL and attribution. These behaviors would not be predictable from annotations or schema alone.
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 dense but every sentence earns its place: core purpose and contents, overflow behavior, vendor attribution behavior, source reporting, and the sibling search tool. It is front-loaded with the main purpose and avoids filler or repetition of schema details.
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?
Given the tool's moderate complexity and the presence of an output schema, the description covers the essential behavioral and usage context: what content is returned, how the outline/overflow works, source attribution, and how to find advisory IDs. No critical operational gap remains for an agent to invoke 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 description coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining how the sections parameter behaves: omitting it returns the whole document, or an outline when the document overflows the inline budget. It also ties sections to the outline's naming, which helps an agent map a prior response to a re-call.
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 and resource: 'Read one CISA industrial control system advisory in full.' It then enumerates the concrete contents (affected products, per-CVE CVSS, remediations, sectors, revision history), which clearly distinguishes it from the sibling search tool cisa_search_ics_advisories. An agent can tell what this tool does and what it returns without opening the 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?
The description explicitly routes the agent to cisa_search_ics_advisories for finding advisory IDs. It also gives operational guidance for large advisories: expect an outline instead of the full document and re-call with the specific sections needed. This is practical, actionable usage context rather than a generic statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what CISA has published recently — its combined advisory feed, its alerts feed, or its ICS advisory feed. Each feed is a rolling window of exactly 30 items with no history, no pagination, and no date-range query, so the window's coverage varies from about a week to about two months depending on the feed. For ICS advisory history beyond the window, use cisa_search_ics_advisories, which covers the full corpus back to 2010.
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | Which feed to read: advisories (all.xml, ~8 days of coverage), alerts (alerts.xml, ~8 weeks), or ics (ics-advisories.xml, ~2.5 weeks). | advisories |
| limit | No | Maximum items to return. The 30 ceiling is the upstream window, not a server choice. | |
| since | No | Keep only items published on or after this date, YYYY-MM-DD. Filters within the fetched window; it cannot reach back beyond it. |
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. |
| feed | No | The feed that was read. |
| error | No | Present when the call failed. Absent on success. |
| items | No | Items from the current window, newest first as published. |
| shown | No | Items returned. |
| notice | No | Guidance when the since filter excluded every item. |
| window | No | What the fetched window covers. |
| feedUrl | No | The absolute feed URL this window came from. |
| feedTitle | No | The channel title the feed declares. |
| truncated | No | True when the limit capped the returned items. |
| windowCaveat | No | That the feed has no history, no pagination, and no date query. |
| effectiveQuery | No | The since filter as applied, and how many window items it excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and idempotentHint, and the description adds crucial operational context: each feed is 'a rolling window of exactly 30 items' with no history and no pagination. It also explains the coverage variability by feed, so an agent understands what to expect before invoking.
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 key constraints, then the alternative. Every sentence earns its place and there is no filler or restatement of structured fields.
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 read-only, idempotent tool with three optional parameters and an output schema, the description covers purpose, limits, feed coverage, and the relevant sibling tool. There is no critical missing information for correct invocation or selection.
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 meaningful context beyond the schema by explaining the 30-item ceiling is inherent to the upstream feed and that date filtering cannot reach outside the window. This reinforces the semantics of limit and since without duplicating the schema verbatim.
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?
Description opens with a specific verb and resource: 'List what CISA has published recently' and names the three feeds: 'combined advisory feed, its alerts feed, or its ICS advisory feed.' It also distinguishes itself from a key sibling by explicitly pointing to cisa_search_ics_advisories for history beyond the window.
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 clearly states when this tool is not appropriate: 'no history, no pagination, and no date-range query.' It also names the exact alternative and its advantage: 'use cisa_search_ics_advisories, which covers the full corpus back to 2010.' This gives an agent actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the SSVC decision points CISA publishes per CVE as a CVE Authorized Data Publisher — Exploitation, Automatable, and Technical Impact — along with the CVSS score and CWE CISA contributes where present, and compute the BOD 26-04 remediation timeline those values imply for the asset exposure you supply. The computed timeline applies CISA's published decision table to CISA's published decision points and your stated exposure; it is not a compliance determination and it is not CISA's own due-date assignment, which is reported separately when the CVE is in KEV and can differ. Not every CVE is enriched — a miss returns found false with guidance rather than an error. Call cisa_list_reference with topic ssvc_values for the decision-point vocabulary.
| Name | Required | Description | Default |
|---|---|---|---|
| cveIds | Yes | CVE identifiers to look up, up to 50 per call — lower than cisa_check_cve_status's 200-CVE cap because each CVE needs its own live enrichment lookup rather than a cached batch check. | |
| assetExposure | No | Whether the affected asset is reachable by unauthenticated or untrusted entities over public networks. The one BOD 26-04 decision point CISA cannot publish. "unknown" returns both arms so the spread is visible without guessing. | unknown |
| Name | Required | Description |
|---|---|---|
| echo | No | The request as the server parsed it. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when nothing was enriched, or when a decision timestamp predates KEV. |
| results | No | One result per requested CVE, in the order supplied. |
| foundCount | No | How many CVEs carry published SSVC decision points. |
| notFoundCount | No | How many CVEs do not. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses important behaviors: misses return 'found false with guidance rather than an error,' the computed timeline is not CISA's own due-date assignment and can differ when the CVE is in KEV, and the lookup uses live enrichment per CVE. These are substantive behavioral details that help an agent set expectations correctly.
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 a typical one-liner, but every sentence adds necessary context: core function, computed-timeline limitations, miss behavior, and vocabulary reference. It is front-loaded with the primary action and structured so caveats follow naturally.
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?
Given the tool's complexity and the presence of an output schema, the description covers the essential context: what data is fetched, how the timeline is computed, what is excluded, how misses behave, and where to get supporting vocabulary. An agent has enough guidance to invoke the tool correctly and interpret unexpected 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 coverage is 100%, so the baseline is 3, but the description boosts understanding by explaining how assetExposure is the one BOD 26-04 decision point CISA cannot publish and that the supplied exposure drives the timeline computation. It also ties cveIds to per-CVE enrichment, reinforcing why the cap is lower than the sibling status tool.
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 names a specific verb and resource: 'Fetch the SSVC decision points CISA publishes per CVE' and 'compute the BOD 26-04 remediation timeline.' It clearly distinguishes the tool from siblings by focusing on SSVC enrichment plus timeline computation, not on generic CVE status, advisories, or KEV search.
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, including what it does and key caveats such as 'not every CVE is enriched' and 'not a compliance determination.' It also explicitly routes users to cisa_list_reference for decision-point vocabulary, but it does not contrast this tool with cisa_check_cve_status or cisa_search_kev as directly as it could.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode the vocabulary the other CISA tools take as input. Topics cover the BOD 26-04 remediation timeline table and what each tier means, the KEV record fields and their value domains, the SSVC decision points CISA publishes, the critical-infrastructure sector names as the advisory corpus spells them, advisory ID formats, CVSS severity bands, and the freshness of the data this server currently holds. Call this before constructing filters for cisa_search_kev or cisa_search_ics_advisories, and whenever another tool's recovery hint points here.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Which reference block to return: directives (BOD 26-04 Table 1 and its definitions), kev_fields, ssvc_values, sectors, advisory_id_formats, severity_bands, or sources (what this server currently holds). |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| title | No | Human-readable title for the topic. |
| topic | No | The topic that was decoded. |
| entries | No | The decoded terms for this topic. |
| sources | No | Topic sources only — what this server currently holds, read from in-process state. |
| summary | No | What this topic covers and when to reach for it. |
| supersedes | No | Topic directives only — the directives BOD 26-04 supersedes and revokes. |
| definitions | No | Topic directives only — supporting definitions from the directive text. |
| timelineTable | No | Topic directives only — all sixteen rows of BOD 26-04 Appendix A, Table 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, lowering the burden. The description adds valuable context beyond those hints, including data freshness and that the returned content reflects what 'this server currently holds.' No contradiction with annotations exists.
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 front-loaded with its core purpose and uses three dense sentences. The long middle enumeration is justified because it maps directly to the allowed topic values and clarifies the content of each block, though it is slightly longer than minimally necessary.
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 reference tool with a documented enum, output schema, and safety annotations, the description supplies everything needed: what it does, what topics it covers, when to call it, and the freshness angle. No critical invocation detail 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 enum values are individually described, so the baseline is 3. The description adds semantics by explaining what each block means — for example, 'BOD 26-04 remediation timeline table and what each tier means' and 'value domains' for KEV fields — which helps an agent pick the correct topic value.
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 action ('Decode the vocabulary the other CISA tools take as input') and names the concrete resource blocks it serves, such as KEV fields, SSVC values, sectors, and advisory ID formats. It clearly positions itself as the reference/vocabulary tool rather than a search- or advisory-fetching sibling.
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 explicit usage triggers: 'Call this before constructing filters for cisa_search_kev or cisa_search_ics_advisories, and whenever another tool's recovery hint points here.' It does not enumerate when-not-to-use scenarios, and a sibling like cisa_get_ssvc could plausibly overlap on SSVC values, so the guidance is strong but not fully exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the CISA industrial control system advisory corpus — 3,926 CSAF 2.0 documents covering PLC, HMI, SCADA, building-automation, and medical-device products from 2010 onward. Filter by vendor, product, CVE, CVSS range, severity band, critical-infrastructure sector, advisory series, publication date, or revision date, and run full-text search over advisory titles and product names. Sector filtering reaches only advisories that carry a sector note, which begins in 2017; the response reports how many documents a sector filter can never match. Returns advisory IDs for cisa_get_advisory, the CVEs each advisory covers, and the source URL and attribution every advisory response carries.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full-text search over advisory titles, vendor names, and product names. Tokens are AND-combined; FTS5 operators in the input are neutralized rather than honored. | |
| cve | No | Exact CVE membership. The corpus covers 12,321 distinct CVEs. | |
| limit | No | Maximum advisories per page. | |
| order | No | Sort direction. Under relevance, desc means most relevant first. | desc |
| cursor | No | Opaque pagination cursor from a previous call. Omit for the first page. | |
| sector | No | Critical-infrastructure sector, matched against the normalized sector set. Multiple is the sentinel the corpus uses for an advisory affecting many sectors. | |
| series | No | Advisory series: ICSA (3,738 documents) or ICSMA medical devices (188). | |
| sortBy | No | Field to sort by. relevance requires q and ranks by FTS5 bm25. | revised |
| vendor | No | Case-insensitive substring of a vendor label. Vendor names are unnormalized upstream — the same company appears under several spellings — so this is substring, not exact. | |
| cvssMax | No | Maximum value of the advisory's maximum CVSS base score, inclusive. | |
| cvssMin | No | Minimum value of the advisory's maximum CVSS base score, inclusive. | |
| product | No | Case-insensitive substring of a product name. | |
| severity | No | Severity band of the advisory's maximum CVSS score. | |
| publisher | No | coordinator selects CISA-authored advisories (2,863); other selects republished vendor advisories (1,063). | |
| revisedTo | No | Latest current release date, inclusive, YYYY-MM-DD. | |
| publishedTo | No | Latest initial release date, inclusive, YYYY-MM-DD. | |
| revisedFrom | No | Earliest current release date, inclusive, YYYY-MM-DD. | |
| publishedFrom | No | Earliest initial release date, inclusive, YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
| cap | No | The page limit that was applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Advisories returned on this page. |
| cursor | No | Opaque cursor for the next page. Absent when this is the last page. |
| mirror | No | Which index state answered this call. |
| notice | No | Guidance when nothing matched. |
| hasMore | No | Whether more matches exist beyond this page. |
| results | No | Matching advisories for this page. |
| truncated | No | True when the page limit capped this result. |
| totalCount | No | Total matches before paging. |
| cvssCoverage | No | Disclosure of derived-band and no-score coverage under a score filter. |
| appliedFilters | No | The filters the server actually applied. |
| sectorCoverage | No | Disclosure of how many advisories a sector filter can never match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint already supplied, the description adds meaningful non-obvious behavior: sector filtering works only on advisories with a sector note beginning in 2017, and the response explicitly reports how many documents cannot match a sector filter. It also discloses what results contain, including advisory IDs, CVEs, source URL, and attribution. This is valuable transparency beyond the annotations and does not contradict them.
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 efficient and well-structured: purpose and scope first, then the filter surface, then the sector caveat, then return values. Despite the large parameter count, every sentence earns its place and no filler is present.
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 read-only search tool with rich annotations and a full output schema, the description provides the missing operational context an agent needs: corpus scope, the sector-filter blind spot, and how results connect to cisa_get_advisory. Pagination, ordering, and defaults are already covered by the input schema, so nothing essential is left unexplained.
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%, with every one of the 18 parameters documented in detail, so the baseline is 3. The description enumerates filter categories but does not add per-parameter semantics beyond the schema. One minor divergence: the description says full-text search covers 'advisory titles and product names,' while the q parameter schema says it also covers vendor names.
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 the specific verb 'Search' and names the exact resource: the CISA industrial control system advisory corpus. It immediately distinguishes this tool from siblings by specifying the corpus size, document format, product coverage, and available filters. The return-value sentence further clarifies that this is a search/indexing tool feeding cisa_get_advisory.
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 gives clear context for when to use the tool: querying the ICS advisory corpus with structured filters and full-text search. It also suggests a workflow by returning advisory IDs intended for cisa_get_advisory. However, it does not explicitly say when not to use it or name alternatives such as cisa_search_kev or cisa_check_cve_status, so it stops short of full alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the CISA Known Exploited Vulnerabilities catalog across every entry in the cached snapshot. Filter by vendor or product using CISA's own labels, by name substring, by CWE, by the date an entry was added, by due date, by overdue status, by ransomware linkage, by the three-day forensic-triage tier, or by which binding operational directive the entry cites. Results are paged and sortable by due date or date added. Vendor and product values are CISA's free-text labels, not CPE names — call cisa_list_reference for the field vocabulary before guessing one. The catalog records additions but carries no per-record modified timestamp, so dateAddedFrom answers "what is new since D" while a revised due date on an existing entry is not detectable from the feed.
| Name | Required | Description | Default |
|---|---|---|---|
| cwe | No | Exact CWE identifier, e.g. CWE-362. Excludes the 175 entries with no CWEs. | |
| limit | No | Maximum entries per page. | |
| order | No | Sort direction. | desc |
| cursor | No | Opaque pagination cursor from a previous call. Omit for the first page. | |
| sortBy | No | Field to sort by. | dateAdded |
| overdue | No | True selects entries whose due date is strictly before the echoed asOf date. | |
| product | No | Case-insensitive substring of CISA's own product label. 694 distinct values. | |
| dueAfter | No | Earliest due date, inclusive, YYYY-MM-DD. | |
| directive | No | Which directive the entry cites. "none" selects the 1,277 entries citing neither. | |
| dueBefore | No | Latest due date, inclusive, YYYY-MM-DD. | |
| ransomware | No | True selects entries CISA has linked to ransomware campaigns (360 entries). | |
| cveIdPrefix | No | Year scope for the CVE ID, e.g. CVE-2026. | |
| dateAddedTo | No | Latest date added, inclusive, YYYY-MM-DD. | |
| nameContains | No | Strict token match over the vulnerability name and short description: every token must appear. No fuzzy fallback. | |
| dateAddedFrom | No | Earliest date added, inclusive, YYYY-MM-DD. | |
| vendorProject | No | Case-insensitive substring of CISA's own vendor label. 283 distinct values. | |
| forensicTriage | No | True selects the BOD 26-04 three-day forensic-triage tier (58 entries). |
| Name | Required | Description |
|---|---|---|
| cap | No | The page limit that was applied. |
| asOf | No | The UTC date overdue and daysUntilDue were computed against, YYYY-MM-DD. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Entries returned on this page. |
| cursor | No | Opaque cursor for the next page. Absent when this is the last page. |
| notice | No | Guidance when nothing matched. |
| catalog | No | Which catalog snapshot answered this call. |
| hasMore | No | Whether more matches exist beyond this page. |
| results | No | Matching KEV entries for this page. |
| truncated | No | True when the page limit capped this result. |
| totalCount | No | Total matches before paging. |
| appliedFilters | No | The filters the server actually applied, as it parsed them. |
| snapshotCaveat | No | Disclosure that additions are queryable but revisions are not detectable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint already set, the description adds substantial behavioral context: the catalog is a cached snapshot, results are paged/sortable, vendor/product are free-text labels rather than CPE names, name matching is strict with no fuzzy fallback, and there is no modified timestamp so revised due dates are not detectable. These are meaningful caveats beyond what annotations or schema provide.
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 dense but every sentence earns its place: main purpose first, filter categories, pagination/sorting, vocabulary warning, and the timestamp limitation. It is front-loaded with the core action and maintains relevance despite the tool's 17 parameters.
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?
Given the large parameter surface and the presence of a full output schema, the description is remarkably complete. It covers catalog scope, filter semantics, paging/sorting, vocabulary sourcing, and known data limitations. Nothing essential for correct invocation 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%, so the baseline is 3, but the description adds value beyond the schema by explaining high-level semantic constraints: CISA labels are not CPE names, dateAddedFrom tells 'what is new since D' but misses revised due dates, and the strict token-match behavior for nameContains. It does not re-document every parameter but enriches the most ambiguous ones.
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 and resource: 'Search the CISA Known Exploited Vulnerabilities catalog across every entry in the cached snapshot.' It then enumerates the filter dimensions (vendor, product, CWE, dates, ransomware, directive, triage tier), making the tool's role unambiguous and clearly distinct from sibling tools like cisa_search_ics_advisories or cisa_get_alerts.
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 gives clear context for when to use the tool and importantly tells the agent to call cisa_list_reference for the field vocabulary before guessing vendor/product values. It does not explicitly state when not to use this tool versus each sibling, but the KEV-specific scope and the explicit reference to a sibling tool provide adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cisa_check_cve_statuscisa_get_advisorycisa_get_alertscisa_get_ssvccisa_list_referencecisa_search_ics_advisoriescisa_search_kevCVE intelligence: exploitation (KEV/EPSS), detection coverage, fixed versions. All tools keyless.
Daily CVE priorities ranked by real exploitation (KEV+EPSS) for AI agents; free teaser, paid full
x402 CVE triage MCP: EPSS + CISA KEV -> exploit priority, $0.01 per query.
Add one secure layer between your agents and this server.
