cisa-cybersecurity-mcp-server

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

Beyond the readOnly and idempotent annotations, the description discloses that the catalog is a cached snapshot, that a full batch costs zero upstream requests, that not-in-KEV is a normal result rather than an error, and that summary mode drops specific fields. These are meaningful behavioral details an agent needs.

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 purpose and usage, and most sentences carry distinct value. It is somewhat long because it enumerates return fields in prose that the output schema already covers, but the density is justified by the tool's batching and cross-tool integration behavior.

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 two-parameter schema, existing annotations, and output schema, the description covers batch limits, error semantics, detail-mode tradeoffs, and integrations with sibling tools. Nothing an agent needs to call the tool correctly seems 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?

Even though the schema already documents both parameters, the description adds actionable context: cveIds can carry a full dependency-audit alias list because the batch is upstream-free, and detail='summary' is recommended for large batches with the exact retained triage fields enumerated.

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: checking CVE IDs against the CISA KEV catalog. It also adds scope details (up to 200 per call, cached snapshot) that distinguish this tool from the sibling search/advisory 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?

The description explicitly says when to use detail='summary' for large batches and explains the reverse direction through cisa_search_ics_advisories. It also names sibling tools and gives concrete routing rules for CWE chaining into cisa_search_kev and cisa_search_ics_advisories.

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/closed-world, so the bar is lower, yet the description adds genuine behavior: large advisories degrade to a section outline with byte sizes and CVE IDs, and every response carries source URLs and attribution. It also notes the non-expanding relationship selection. Not exhaustive on pagination/error behavior, but solid beyond the 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?

Dense but front-loaded: the core read action and return contents come first, followed by narrowing mechanics and the search-tool pointer. Every sentence carries information, though it is on the longer side and repeats some schema-level detail.

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 an output schema exists, return values needn't be spelled out, yet the description usefully previews them and explains the overflow/outline behavior that an agent needs to interpret large responses. Complete for the task; only minor gaps around error or revision-edge behavior.

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% and the schema already documents sections, cves, productIds, and advisoryId syntax in detail, so the baseline is 3. The description largely restates that behavior; the one real addition is 'relationship selection does not expand components' for productIds.

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 ('Read one CISA industrial control system advisory') and enumerates the concrete content it returns (product definitions, CVSS score/vector/CWE, remediations, sectors, revisions). It also names the sibling used to find IDs, making it clearly distinguishable from cisa_search_ics_advisories.

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?

Explains how to narrow results (re-call with sections, cves, or productIds) and routes the agent to cisa_search_ics_advisories for discovering IDs. Clear contextual guidance, though it doesn't explicitly state when-not to use this tool versus other advisory tools like cisa_get_ssvc.

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 only declare readOnlyHint and idempotentHint; the description goes well beyond them by disclosing the fixed 30-item rolling window, absence of history/pagination/date-range querying, and the fact that coverage varies from roughly a week to two months by feed. That is exactly the operational context an agent needs before calling.

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 action and feed options, then the constraint, then the fallback route. No filler and nothing buried.

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, and the description covers the scope, the rolling-window limitation, and the alternative tool for deeper history. Nothing an agent needs to call this 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 description coverage is 100% and each parameter already documents its enum values, 30-item ceiling, and windowed-filter behavior, so the baseline is 3. The description adds little param-level detail beyond reiterating the window constraint, and its 'no date-range query' phrasing sits in mild tension with the existence of `since` (the schema resolves this, but the description does not).

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 concrete verb and resource ('List what CISA has published recently') and immediately enumerates the three specific feeds it can read. It also names the sibling cisa_search_ics_advisories, so an agent can distinguish scope 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?

Explicitly states both when to use it (recent publication lookup across the three feeds) and when not to (ICS history beyond the rolling window), routing to cisa_search_ics_advisories and noting that it covers the full corpus back to 2010. The 'no pagination, no date-range query' clause further bounds its use.

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 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.

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuine behavioral context: this is a static lookup surface, it discloses data-freshness information via the 'sources' topic, and it tells the agent this tool is an input to other tools rather than an action.

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 the core purpose, then the topic inventory, then the usage rule. The middle sentence is long but each item is a distinct reference block, so little is wasted; the usage rule is slightly deferred to the end.

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-value detail is not required. The description covers purpose, full topic inventory, and invocation timing for a single-parameter, one-of-enum tool — an agent has everything needed to call it 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 the enum values are documented in the schema, so baseline 3 applies. The description goes beyond the schema by glossing the two most opaque topics ('the BOD 26-04 remediation timeline table', 'the freshness of the data this server currently holds'), adding semantics the enum labels alone don't 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?

States a specific verb and resource ('decode the vocabulary the other CISA tools take as input') and then enumerates exactly what vocabulary is covered. It is immediately distinguishable from the search/get siblings, which consume this vocabulary rather than define it.

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 an explicit when-to-use rule ('Call this before constructing filters for cisa_search_kev or cisa_search_ics_advisories') and a second trigger ('whenever another tool's recovery hint points here'). Both the alternative tools and the condition that selects this one 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?

Goes beyond the readOnly/idempotent/openWorld annotations by disclosing a real corpus limitation: sector filtering only reaches advisories carrying a sector note, which begins in 2017, and the response reports how many documents a sector filter can never match. It also states that every response carries source URL and attribution. Rate limits, ordering effects beyond the schema, and result-size caveats are not covered, keeping it 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?

Front-loaded with purpose and scope before enumerating filters, and no sentence is pure filler. It is a single long sentence dense enough to be hard to skim, so a small structure penalty applies, but the information density is high.

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 20-parameter, zero-required search tool with an output schema, the description covers corpus boundaries, the filter surface, the sector-coverage caveat, and the shape of returned IDs and KEV flags. Pagination is delegated to the cursor schema and sort behavior to sortBy, so nothing critical is missing, though explicit composition/default guidance is absent.

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% and every parameter is already documented in the schema, so the baseline is 3. The description largely restates the filter taxonomy the schema already provides; the one nuance it adds (KEV coverage is checked against every CVE an advisory covers, not just the twenty listed) is also present in the inKev schema description, so the marginal semantic value is limited.

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) plus resource (CISA ICS advisory corpus) and pins the scope precisely: CSAF 2.0 advisories covering PLC/HMI/SCADA/building-automation/medical-device products from 2010 onward. It also routes the agent onward by naming cisa_get_advisory as the consumer of the returned IDs, which cleanly separates it from the fetch-by-ID 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?

Gives strong context for when this is the right tool: an enumerated filter surface (vendor, product, CVE, CWE, CVSS range, severity, sector, series, dates, KEV) plus full-text search, and it implies the follow-up path via cisa_get_advisory. It never explicitly contrasts itself with siblings like cisa_search_kev or cisa_check_cve_status, so the when-not/alternative case is left 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?

Goes well beyond the readOnlyHint/idempotentHint annotations: it discloses that the data is a cached snapshot, that results are paged and sortable, that vendor/product are CISA free-text labels rather than CPE names, and a genuine data-model limitation (no per-record modified timestamp, so revised due dates are undetectable). That last point is exactly the kind of caveat an agent cannot infer elsewhere.

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 verb and resource, then filters, then paging/sorting, then the two caveats. The long filter enumeration is dense but every clause maps to a real capability, and no sentence is filler.

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-value documentation is unnecessary, and the description covers what matters for correct invocation: scope, filter inventory, pagination, sort keys, label vocabulary warning, and the temporal caveat. Nothing an agent needs to call this 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 description coverage is 100%, so 3 is the baseline, but the description adds interpretive meaning the schema does not: the vendor/product label-vs-CPE distinction, the paging/sorting behavior, and the semantic asymmetry between the added-date and due-date filters. It does not restate the enum values or patterns, which 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?

States a specific verb and resource ('Search the CISA Known Exploited Vulnerabilities catalog') and immediately scopes it ('across every entry in the cached snapshot'), then enumerates the filterable dimensions. This is clearly distinguishable from sibling reads like cisa_get_advisory or cisa_check_cve_status without opening a 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?

Gives an explicit prerequisite-style routing instruction: call cisa_list_reference for the field vocabulary before guessing vendor/product values. It also clarifies which date filter answers which question (dateAddedFrom = 'what is new since D'). It does not, however, state when to prefer this tool over siblings like cisa_check_cve_status, so it stops short of full when/when-not coverage.

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