A
licenseNot graded
qualityF
maintenanceProvides CVE search enriched with EPSS exploit likelihood and CISA KEV status, plus live IP/domain reputation and a real-time threat feed for AI agents.
MIT
cve-intelligence
Server Details
CVE intelligence: exploitation (KEV/EPSS), detection coverage, fixed versions, CPE configurations.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 67 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
A3.9/5.0
Scored across 9 tools
Disambiguation4/5
Tools are largely distinct: search_cves for discovery, get_cve for a single CVE's full record, and specialized tools for chains, EPSS movers, sightings, updates, package queries, and BOD table reads. Minor overlap exists because get_cve bundles chain, sighting, and BOD data that dedicated tools also provide, but the dedicated tools have different scopes (batch, filters).
Naming Consistency3/5
Six of nine tools use a consistent get_ verb_noun pattern, but query_package and search_cves use different verbs, and table1_read reverses the noun_verb order. All are snake_case, but the verb inconsistency prevents a perfect score.
Tool Count5/5
Nine tools cover the CVE intelligence domain without redundancy; each tool serves a distinct purpose (search, detail, chains, EPSS movers, scoreboard, sightings, updates, package query, BOD table). This is a well-scoped set.
Completeness4/5
The surface covers core CVE intelligence: search, detailed records, chained vulnerabilities, EPSS movers, field sightings, change tracking, package queries, and BOD 26-04 Table 1 reads. Minor gaps include no direct product-name search (only vendor slug or OSS package) and no standalone CWE/ATT&CK detail lookup, but these are workable via filters.
Available Tools
9 toolsget_chainsRead-onlyIdempotentInspect
Known Chained Vulnerabilities™: pairs of CVEs that a cited source reports were used together in one exploit chain (VulnCheck KEV entry text, Metasploit modules, SigmaHQ rules, press, research or academic sentences, community text judged by a local model). Each row carries both CVEs with their CISA KEV status, the claim kind (observed: the source reports attacks; potential: the source reports they can be chained), the quoted evidence with its source, URL and date, and community discussion counts, which show discussion and are not chain claims. The per-CVE record carries chains.known and chains.candidates (KCV Watch: possible chains for teams to research, pairs whose extracted exploit capabilities connect or whose records tie them together, derived and never confirmed, each with its tier, lane, reasons, basis, product, bridge, grade, a caption and the entry step where one is extracted); search_cves accepts chained=1 and chainability=1. Filters: source (vulncheck_kev, metasploit, sigma, press, research, community), since (YYYY-MM-DD, first seen), claim (observed|potential), limit (1..50).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| claim | No | observed: the source reports attacks that chained them; potential: the source reports they can be chained | |
| limit | No | 1..50 (default 50) | |
| since | No | Pairs first seen on or after this day (YYYY-MM-DD) | |
| source | No | Evidence lane: vulncheck_kev, metasploit, sigma, press, research, academic, community, github_poc, exploitdb or exploit_code |
get_cveARead-onlyIdempotentInspect
Full intelligence record for one CVE: per-scorer CVSS, EPSS, CISA KEV/ransomware/SSVC, four remote-detection modalities (the checks that work over the network) plus a host-check tier (self-contained Nuclei templates and Metasploit local modules that run on the system itself) and the Sigma log-detection layer, both kept out of scannable coverage, per-product fixed versions (fixed = first patched build; affected_through = the last vulnerable build, so upgrade past it), news/community coverage, intelligence summary, and bod_26_04: the BOD 26-04 Table 1 read on both exposure branches (CISA's row numbers and timelines from KEV status and CISA's SSVC Automatable and Technical impact) with CISA's KEV due date, forensic triage flag and the KEV entry's action text (kev_required_action, CISA's requiredAction field); the agency's exposure tag decides the row. other_databases lists the CVE's records in ENISA's EUVD, BDU (FSTEC of Russia), CNVD (CNCERT/CC) and JVN iPedia (JPCERT/CC and IPA) with the address of each. products lists the vendor and product pairs the page lists and the CPE entries NVD's configurations name: with cpes_source nvd_configurations, configurations carries them as NVD writes them (each entry's vulnerable flag, AND and OR operators, negate and the version bounds verbatim, up to 100 matches here, configurations_cap for more), and cpes their names; with nvd_cpe_list, cpes holds the first 25 names in sort order our NVD ingest stores, flagged by cpes_may_be_incomplete. No key required over MCP; an API key on the HTTP request (Authorization: Bearer cvs_live_…) is honored for attribution. Absence semantics: a null field means this dataset holds no such record. The source may still hold one.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | CVE id, such as CVE-2024-3400 | |
| configurations_cap | No | How many of NVD's configuration matches products.configurations carries (default 100; 0 to 500). GET /api/cve/{id} carries up to 500. |
TDQS
A3.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true. The description adds substantial behavioral context beyond annotations: absence semantics ('a null field means this dataset holds no such record'), auth details ('No key required over MCP; an API key ... is honored'), and the configurations_cap default/range and scannable coverage exclusion. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely long and dense single block of text with nested clauses and parentheticals. While the first sentence front-loads the purpose, the remainder is not concise and lacks structure (no bullets, very long sentences). Every detail may be useful given no output schema, but the presentation is inefficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the tool's high complexity (many nested fields), the description comprehensively explains return contents, field meanings, and edge cases like absence semantics and caps. It covers what an agent needs to interpret the response, so it is complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters (id and configurations_cap) are fully described in the schema. The description repeats some of this ('up to 100 matches here, configurations_cap for more') but adds no new syntax or constraints beyond the schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Full intelligence record for one CVE'. It clearly identifies the resource (single CVE) and scope (full record). However, it does not explicitly name or differentiate from sibling tools like search_cves or table1_read, so it falls 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are provided. The description is purely descriptive of contents; it never says when to choose this tool over search_cves or table1_read. Implied usage exists (retrieve full record for a known CVE), but no exclusions or routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_epss_moversARead-onlyIdempotentInspect
CVEs whose EPSS exploitation probability rose the most recently. window is "7d" (default) or "30d". Each rise is measured between same-EPSS-model-version scores, so a model release (which shifts the whole distribution) never appears as a mover. A rise raises the priority of a CVE; observed exploitation is recorded through CISA KEV. Returns cve_id, current score, the delta, KEV status and url, largest rise first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1..100 (default 25) | |
| window | No | Rise window (default 7d) |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behavioral nuances: rises are compared within the same EPSS model version so model releases never create false movers, and KEV status is included as observed-exploitation context. It also states the ordering (largest rise first), which is not derivable from annotations or the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears in the first clause, followed by parameter default, a key methodological caveat, output fields, and ordering. Every sentence contributes useful information; there is no filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with only two optional parameters and no output schema, the description is fully self-sufficient. It tells the agent what is returned, the ordering, the available windows and defaults, and why the mover signal is reliable, leaving no critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters, including the enum for window, the range for limit, and defaults. The description adds contextual meaning for window by explaining that it is the rise window, but it does not materially expand on limit or introduce semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it returns CVEs whose EPSS exploitation probability rose most recently. It also lists the exact output fields (cve_id, current score, delta, KEV status and url), which is specific and unambiguous. However, it does not explicitly contrast itself with sibling tools like search_cves or get_updates, so the differentiation is implicit 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you want recent EPSS movers, and it explains the window choices (7d or 30d) and default. It does not explicitly state when not to use it or point to alternatives, leaving some routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scoreboardARead-onlyIdempotentInspect
The Defender Scoreboard report (CC BY 4.0): exploited vs detectable vs patchable, every figure with its method, caveat and denominator, plus the corpus block and any method-change notes. Cite as "CVE Security Defender Scoreboard, cve-security.com/scoreboard".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only and idempotent behavior. The description adds value by disclosing the CC BY 4.0 license and the citation requirement, which is a genuine behavioral constraint beyond annotations. No contradiction exists with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At roughly 30 words, the description is compact and every phrase carries information: license, report contents, and citation. It is front-loaded with the resource name. It is slightly dense as a single long sentence, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only report getter, the description covers what the report contains and how to cite it, which compensates for the missing output schema. It does not specify the response format, but that is not essential for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter documentation is unnecessary; the baseline of 4 applies. The description appropriately focuses on report content rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Defender Scoreboard report) and details its contents: exploited vs detectable vs patchable, method/caveat/denominator, corpus block, and method-change notes. This distinguishes it from siblings like get_cve or search_cves. However, it lacks an explicit verb like 'returns' or 'fetches' and does not directly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The content description makes the use case clear: an agent should call this when the user needs scoreboard statistics with methodology, caveats, and denominators. It does not explicitly name alternatives or state when not to use it, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sightingsRead-onlyIdempotentInspect
Field sightings: CVEs a named sensor network recorded in the last 7 or 30 days, most sighting days first. A field sighting is a day on which Shadowserver honeypots (cited by VulnCheck KEV and published as daily lists by CIRCL Vulnerability-Lookup) or VulnCheck canary sensors recorded traffic aimed at the CVE. Each row carries first and last sighting day, days sighted in the last 7 and 30, the sensors, and per-sensor detail including a 30-day presence strip. Presence per day, without volume; a sighting stays apart from the exploitation claims and from CISA KEV. Filters: window (7|30, default 7), kev (0|1), limit (1..50).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kev | No | Restrict to CVEs outside (0) or inside (1) CISA KEV | |
| limit | No | 1..50 (default 50) | |
| window | No | Sighting window in days (default 7) |
get_updatesRead-onlyInspect
The publication change stream: what this site published, stamped with OUR publish time (first_published, kev_added, detection_added, remediation_added, first_sighted, chain_added, and the BOD 26-04 Table 1 input changes ssvc_changed, kev_due_changed, kev_triage_flag_changed, kev_notes_changed, which fire on value changes between snapshots; a timestamp refresh alone fires none). Pass since (YYYY-MM-DD, strictly-after) on the first call, then the returned next_cursor to continue. Over MCP the stream covers the last 30 days, up to 50 events per call: since defaults to 30 days ago, and an earlier since or cursor returns an error. Optional cve scopes the stream to one CVE's change history, with no 30-day cutoff; follow next_cursor past the first 50 events. Events for withdrawn CVE ids are omitted. The keyed GET /api/updates walks the full history.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cve | No | Scope to one CVE's change history, such as CVE-2024-3400 | |
| type | No | ||
| limit | No | 1..50 (default 50) | |
| since | No | ||
| cursor | No |
query_packageARead-onlyIdempotentInspect
CVEs affecting one open-source package, by purl (pkg:npm/lodash) or ecosystem + name (Maven names are group:artifact). Returns the CVE list KEV-first with each OSV version range VERBATIM: events plus one render-safe projection: fixed (the upgrade targets) or affected_through (the last VULNERABLE version, so upgrade past it). This tool does not evaluate version membership; compare versions on your side with your ecosystem’s own semantics. Covers CVE-linked, GitHub-reviewed OSS advisories via OSV.dev; absence is not evidence of safety.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Package name, verbatim (for example @babel/core or org.jenkins-ci.main:jenkins-core) | |
| purl | No | Package URL, such as pkg:npm/lodash or pkg:maven/org.apache.logging.log4j/log4j-core | |
| ecosystem | No | OSV ecosystem (npm, PyPI, Maven, Go, crates.io, Packagist, RubyGems, NuGet, …) or purl type (pypi, cargo, composer, gem, golang, …) |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already indicate read-only and idempotent behavior, the description adds substantial behavioral context: KEV-first ordering, verbatim OSV range output, the events/fixed/affected_through projection, the explicit refusal to evaluate version membership, and the coverage caveat that absence is not evidence of safety. This goes well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, input modes, output format, version-range semantics, and an important coverage caveat. The main action is front-loaded and there is no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly takes on the burden of explaining return values. It covers what is returned (CVE list, KEV-first), how version ranges are represented (fixed vs affected_through), and what the tool does not do. For a read-only package advisory lookup, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by clarifying purl vs ecosystem+name usage, flagging Maven group:artifact format, and giving concrete examples like pkg:npm/lodash, which helps an agent construct correct parameter combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'CVEs affecting one open-source package' and immediately distinguishes the query modes (purl vs ecosystem + name). It clearly separates this from siblings like search_cves and get_cve by emphasizing a single package's advisory list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: when you need CVEs for one package, identified by purl or ecosystem + name. It does not explicitly name alternatives or exclusions, but the package-scoped scenario is unmistakable and no misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cvesRead-onlyIdempotentInspect
Search the catalog. Free text (q) and/or structured filters: vendor (slug), cwe (CWE-nnn), technique (ATT&CK id, such as T1190), year ("2024,2025"), sev ("critical,high"), kev (0|1), kev_from / kev_to (ISO days, half-open CISA listing window; imply kev=1), kev_vendor (the CISA vendorProject string verbatim, such as "Microsoft"), ransomware (0|1), detect (0|1, a detection signal we track), fix (0|1; fix=0 means the fix status was computed and this dataset holds no actionable vendor fix), automatable (0|1, CISA SSVC Automatable; 1=yes, 0=CISA assessed no, unassessed CVEs match neither), sighted (7|30: a named sensor network recorded the CVE in the last 7 or 30 days, a field sighting; presence per day, apart from the exploitation claims), malware (0|1: a published source ties a named malware family, tool, campaign or ransomware group to the CVE), watch (0|1: on KEV Watch at tier 1 or 2, reported exploited by trackers other than CISA and outside CISA KEV), epss_gte (0..1), ti (total|partial: CISA SSVC Technical impact, for CVEs with a CISA assessment held), triage_flag (0|1: CISA's forensic triage flag on the KEV entry), ssvc (0|1; ssvc=0 selects rows with no CISA SSVC assessment held), bod (3df|3d|14d|60d|fsu: the BOD 26-04 Table 1 read at the stated exposure, with exposed 0|1, default 1; a mapping at that exposure, and an agency's timeline still needs its own enumeration date), eco (OSS ecosystem, such as npm or PyPI), pkg (pkg_key, such as npm/lodash; for ranges use query_package), page (1..5), limit (1..50). Filter-only queries return the /browse slice ordered KEV-first then EPSS.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| ti | No | CISA SSVC Technical impact, for CVEs with a CISA assessment held | |
| bod | No | BOD 26-04 Table 1 read at the stated exposure: a mapping of KEV status and CISA SSVC values to a timeline key at that exposure | |
| cwe | No | ||
| eco | No | ||
| fix | No | ||
| kev | No | ||
| pkg | No | ||
| sev | No | ||
| page | No | ||
| ssvc | No | Whether this dataset holds a CISA SSVC assessment for the CVE | |
| year | No | ||
| limit | No | ||
| watch | No | On KEV Watch at tier 1 or 2: reported as exploited by trackers other than CISA, outside CISA KEV | |
| detect | No | ||
| kev_to | No | ISO day, exclusive upper bound on the CISA listing date | |
| vendor | No | ||
| chained | No | In a known exploit chain: a cited source reports the CVE was used together with another CVE in one exploit chain | |
| exposed | No | The exposure branch for bod: 1 publicly exposed (default), 0 internal | |
| malware | No | A published source ties a named malware family, tool, campaign or ransomware group to the CVE | |
| sighted | No | Field sighting window in days: a named sensor network recorded the CVE within the last 7 or 30 days | |
| epss_gte | No | ||
| kev_from | No | ISO day, inclusive lower bound on the CISA listing date | |
| technique | No | ATT&CK technique id, such as T1190 or T1059.001 | |
| kev_vendor | No | CISA's vendorProject, verbatim (for example 'Palo Alto Networks') | |
| ransomware | No | ||
| automatable | No | ||
| triage_flag | No | CISA's forensic triage flag on the KEV entry (BOD 26-04) | |
| chainability | No | On KCV Watch™: the CVE carries at least one chain candidate at tier A or B, a pair whose extracted exploit capabilities connect or whose records tie the two CVEs together; a candidate is not a confirmed chain |
table1_readARead-onlyIdempotentInspect
BOD 26-04 Table 1 read for up to 50 CVEs at a stated asset exposure. Per CVE this dataset supplies CISA KEV status and due date, CISA's SSVC Automatable and Technical impact (Vulnrichment) and CISA's forensic triage flag on the KEV entry; you supply exposure for the asset (yes, no, or unknown, which returns both branches). Each item carries the Table 1 row and timeline for the stated exposure, both branches, kev_feed (which branch reproduces CISA's due date and flag pair, if any) and the fix and detection state held, lanes listed separately. A row is a mapping; an agency's timeline for an asset also needs the agency's own enumeration date, so no date is returned beyond CISA's KEV due date. basis says where the values came from: cisa_ssvc, cisa_interim (a CVE outside KEV with no CISA assessment held takes CISA's interim values) or kev_unassessed (a KEV entry with no values held gets no rows).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | CVE ids, such as CVE-2024-3400 (1 to 50) | |
| exposure | No | Whether the asset is publicly exposed, the agency's own per-asset value; unknown returns both branches |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint and idempotentHint, the description adds substantial behavioral detail beyond that: it explains that unknown exposure returns both branches, that kev_feed indicates which branch reproduces CISA's due date, that a row is a mapping and no agency enumeration date is returned, and the meaning of basis values. This is extra transparency about what the tool actually does and returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, but it is efficiently front-loaded with the essential purpose first, then expands into details that each earn their place. No filler or repetition exists. The flow from purpose to data provided to field clarifications is logical and compact given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 absence of an output schema, the description covers all necessary aspects: the input parameters, the returned fields (KEV status, due date, SSVC values, triage flag, row, timeline, kev_feed, fix/detection state, lanes), the basis explanation, and a key limitation (no agency enumeration date). An agent has enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of the parameters with descriptions, but the description adds significant semantic nuance: it explains the effect of exposure values (yes/no/unknown, with unknown returning both branches), the max count of 50 CVEs, and what the 'basis' field means relative to each CVE's status. This goes well beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'BOD 26-04 Table 1 read for up to 50 CVEs at a stated asset exposure,' which clearly states the verb (read), the specific resource (BOD 26-04 Table 1), and the scope. It distinguishes the operation from sibling tools like search_cves or get_cve by focusing on a specific BOD dataset and the exposure parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: to read Table 1 data for a set of CVEs given an asset exposure. It does not explicitly state when not to use it or name alternative tools, but the context is unambiguous. It explains the inputs and behavior sufficiently for an agent to decide it is the right tool for BOD 26-04 table reads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
get_chains1 field changed- changed
Input schema / properties / limit / descriptionPrevious value: -"1..500 (default 100)"New value: +"1..50 (default 50)"
- Changed
get_sightings1 field changed- changed
Input schema / properties / limit / descriptionPrevious value: -"1..500 (default 100)"New value: +"1..50 (default 50)"
- Changed
get_updates1 field changed- added
Input schema / properties / limit / descriptionAdded value: +"1..50 (default 50)"
1 tool update
- Changed
get_cve1 field changed- added
Input schema / properties / configurations_capAdded value: +{ + "description": "How many of NVD's configuration matches products.configurations carries (default 100; 0 to 500). GET /api/cve/{id} carries up to 500.", + "maximum": 500, + "minimum": 0, + "type": "integer" +}
1 tool update
- Changed
search_cves1 field changed- changed
Input schema / properties / chainability / descriptionPrevious value: -"On KCV Watch™: the CVE carries at least one chain candidate, a same-product pair whose extracted exploit capabilities connect, derived from exploit-capability analysis; a candidate is not a confirmed chain"New value: +"On KCV Watch™: the CVE carries at least one chain candidate at tier A or B, a pair whose extracted exploit capabilities connect or whose records tie the two CVEs together; a candidate is not a confirmed chain"
1 tool update
- Changed
get_chains1 field changed- changed
Input schema / properties / source / descriptionPrevious value: -"Evidence lane: vulncheck_kev, metasploit, sigma, press, research, academic, community, github_poc or exploitdb"New value: +"Evidence lane: vulncheck_kev, metasploit, sigma, press, research, academic, community, github_poc, exploitdb or exploit_code"
2 tool updates
- Changed
get_updates1 field changed- changed
Input schema / properties / type / enumPrevious value: -[ - "first_published", - "kev_added", - "detection_added", - "remediation_added", - "first_sighted", - "chain_added" -]New value: +[ + "first_published", + "kev_added", + "detection_added", + "remediation_added", + "first_sighted", + "chain_added", + "ssvc_changed", + "kev_due_changed", + "kev_triage_flag_changed", + "kev_notes_changed" +]
- Changed
search_cves5 fields changed- added
Input schema / properties / bodAdded value: +{ + "description": "BOD 26-04 Table 1 read at the stated exposure: a mapping of KEV status and CISA SSVC values to a timeline key at that exposure", + "enum": [ + "3df", + "3d", + "14d", + "60d", + "fsu" + ], + "type": "string" +} - added
Input schema / properties / exposedAdded value: +{ + "description": "The exposure branch for bod: 1 publicly exposed (default), 0 internal", + "enum": [ + "0", + "1" + ], + "type": "string" +} - added
Input schema / properties / ssvcAdded value: +{ + "description": "Whether this dataset holds a CISA SSVC assessment for the CVE", + "enum": [ + "0", + "1" + ], + "type": "string" +} - added
Input schema / properties / tiAdded value: +{ + "description": "CISA SSVC Technical impact, for CVEs with a CISA assessment held", + "enum": [ + "total", + "partial" + ], + "type": "string" +} - added
Input schema / properties / triage_flagAdded value: +{ + "description": "CISA's forensic triage flag on the KEV entry (BOD 26-04)", + "enum": [ + "0", + "1" + ], + "type": "string" +}
1 tool update
- Added
table1_read
1 tool update
- Changed
get_chains1 field changed- changed
Input schema / properties / source / descriptionPrevious value: -"Evidence lane: vulncheck_kev, metasploit, sigma, press, research, community, github_poc or exploitdb"New value: +"Evidence lane: vulncheck_kev, metasploit, sigma, press, research, academic, community, github_poc or exploitdb"
1 tool update
- Changed
search_cves2 fields changed- changed
Input schema / properties / chainability / descriptionPrevious value: -"KCV Watch™ tier: a structural pattern (same product, published within 365 days or within 30 days inside the largest products, complementary weakness class) published with its measured rate; a tier is not a confirmed chain"New value: +"On KCV Watch™: the CVE carries at least one chain candidate, a same-product pair whose extracted exploit capabilities connect, derived from exploit-capability analysis; a candidate is not a confirmed chain" - changed
Input schema / properties / chainability / enumPrevious value: -[ - "1", - "2", - "3" -]New value: +[ + "0", + "1" +]
1 tool update
- Changed
search_cves1 field changed- changed
Input schema / properties / chainability / descriptionPrevious value: -"KCV Watch™ tier: a structural pattern (same product, published within 30 or 90 days, complementary weakness class) published with its measured rate; a tier is not a confirmed chain"New value: +"KCV Watch™ tier: a structural pattern (same product, published within 365 days or within 30 days inside the largest products, complementary weakness class) published with its measured rate; a tier is not a confirmed chain"
1 tool update
- Changed
search_cves1 field changed- changed
Input schema / properties / chainability / descriptionPrevious value: -"Chainability™ watch tier: a structural pattern (same product, published within 30 or 90 days, complementary weakness class) published with its measured rate; a tier is not a confirmed chain"New value: +"KCV Watch™ tier: a structural pattern (same product, published within 30 or 90 days, complementary weakness class) published with its measured rate; a tier is not a confirmed chain"
3 tool updates
- Added
get_chains - Changed
get_updates1 field changed- changed
Input schema / properties / type / enumPrevious value: -[ - "first_published", - "kev_added", - "detection_added", - "remediation_added", - "first_sighted" -]New value: +[ + "first_published", + "kev_added", + "detection_added", + "remediation_added", + "first_sighted", + "chain_added" +]
- Changed
search_cves2 fields changed- added
Input schema / properties / chainabilityAdded value: +{ + "description": "Chainability™ watch tier: a structural pattern (same product, published within 30 or 90 days, complementary weakness class) published with its measured rate; a tier is not a confirmed chain", + "enum": [ + "1", + "2", + "3" + ], + "type": "string" +} - added
Input schema / properties / chainedAdded value: +{ + "description": "In a known exploit chain: a cited source reports the CVE was used together with another CVE in one exploit chain", + "enum": [ + "0", + "1" + ], + "type": "string" +}
1 tool update
- Changed
search_cves2 fields changed- added
Input schema / properties / malwareAdded value: +{ + "description": "A published source ties a named malware family, tool, campaign or ransomware group to the CVE", + "enum": [ + "0", + "1" + ], + "type": "string" +} - added
Input schema / properties / watchAdded value: +{ + "description": "On KEV Watch at tier 1 or 2: reported as exploited by trackers other than CISA, outside CISA KEV", + "enum": [ + "0", + "1" + ], + "type": "string" +}
3 tool updates
- Added
get_sightings - Changed
get_updates1 field changed- changed
Input schema / properties / type / enumPrevious value: -[ - "first_published", - "kev_added", - "detection_added", - "remediation_added" -]New value: +[ + "first_published", + "kev_added", + "detection_added", + "remediation_added", + "first_sighted" +]
- Changed
search_cves1 field changed- added
Input schema / properties / sightedAdded value: +{ + "description": "Field sighting window in days: a named sensor network recorded the CVE within the last 7 or 30 days", + "enum": [ + "7", + "30" + ], + "type": "string" +}
Related MCP Connectors
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
CVE search, vulnerability database, EPSS exploit prediction, KEV, IP reputation & threat feed.
Is a CVE exploited? CISA KEV, FIRST EPSS, CVSS and SSVC with a patch-first verdict. Free, no key.
Read-only vulnerability intelligence: CVEs, exploitation evidence, fixes and product matches.
101
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides CVE lookup, search, and exploit intelligence from public vulnerability sources (NVD, CISA KEV, EPSS) for AI agents to produce remediation guidance without consuming LLM tokens for data fetching.1MIT
- AlicenseNot gradedqualityDmaintenanceProvides unified access to vulnerability data from NVD, MITRE, and GitHub Security Advisories for cybersecurity intelligence.10 npm19MIT
- AlicenseNot gradedqualityDmaintenanceProvides multi-source vulnerability intelligence for AI-powered security operations, combining NVD CVSS, CISA KEV, and EPSS scores without requiring an API key.1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.