nist-nvd-mcp-server
Server Details
Search and audit NIST NVD CVEs by keyword, severity, CWE, CISA KEV status, and CPE.
- Status
- Healthy
- Uptime
- 99.9% over 42 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/nist-nvd-mcp-server
- GitHub Stars
- 1
- Server Listing
- nist-nvd-mcp-server
TDQS
Scored across 5 tools
The five tools have largely distinct roles: keyword/severity discovery (nvd_search_cves), ID lookup (nvd_get_cve), change history (nvd_get_cve_history), CPE resolution (nvd_search_cpes), and product-version auditing (nvd_audit_cpe). The main risk is overlap between nvd_search_cves keyword queries and nvd_audit_cpe product matching, but the descriptions explicitly cross-reference each other to steer selection.
All tools share the nvd_ prefix and a clean verb_noun pattern (get_cve, get_cve_history, search_cves, search_cpes, audit_cpe). Minor deviations: the singular/plural split (cpe vs cpes, cve vs cves) and the one-off 'audit' verb break the otherwise uniform convention slightly.
Five tools is a tight, well-scoped surface for read-only NVD access, and each tool occupies a distinct step in the workflow (resolve CPE, audit, search, fetch detail, check history). No redundant or filler tools.
The surface covers the core lifecycle: discovery, full record retrieval, change history, and CPE-based product auditing, which is essentially all a read-only NVD client can offer. Minor gaps exist—no dedicated CWE or vendor dictionary lookup, no aggregation/count query, and large-result pagination depends on brief mode rather than an explicit tool.
Available Tools
5 toolsnvd_audit_cpeAudit CPE for VulnerabilitiesARead-onlyIdempotentInspect
Find all CVEs affecting a specific product and version using CPE (Common Platform Enumeration). Requires either an exact CPE name (cpeName) or a partial match string (virtualMatchString) with optional version range bounds. With cpeName, NVD scopes results to configurations where the product is directly vulnerable, not merely referenced as a dependency. Use nvd_search_cpes first to resolve the correct CPE string for a product. Returns full CVE records including current SSVC assessments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of CVEs to return (default 20; values above 2000 are clamped unless NVD_CLAMP_LIMITS is false). | |
| offset | No | Zero-based page offset for pagination. Page through totalCount with a modest limit rather than raising limit — this tool returns full CVE records, so a large limit is a large response. | |
| cpeName | No | Full CPEv2.3 name (e.g., "cpe:2.3:a:apache:http_server:2.4.51:*:*:*:*:*:*:*"). NVD adds isVulnerable automatically. Mutually exclusive with virtualMatchString. | |
| versionEnd | No | Upper version bound. Requires virtualMatchString. | |
| severityMin | No | Keep CVEs whose highest severity band across all CVSS versions meets this threshold, which can exceed the row headline severity. Applied after NVD returns the page, so only CVEs within limit are evaluated. | |
| allLanguages | No | When true, keeps every localized description NVD supplies on each record. Default keeps English only. | |
| versionStart | No | Lower version bound. Requires virtualMatchString. | |
| versionEndType | No | Whether the upper version bound is inclusive or exclusive. | including |
| versionStartType | No | Whether the lower version bound is inclusive or exclusive. | including |
| includeReferences | No | When false, omits references from each record and its rendered text. | |
| virtualMatchString | No | Partial CPE match pattern (e.g., "cpe:2.3:a:apache:http_server:*"). Use with versionStart/versionEnd for version range audits. Mutually exclusive with cpeName. | |
| includeConfigurations | No | When false, omits configurationNodes from each record and its rendered text. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cves | No | Full CVE records for CVEs affecting the specified product. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance on the shape of this page. When no CVEs came back it distinguishes a target NVD holds no CVEs for from a severityMin filter that dropped everything on the page, from an offset past the result set, from an empty page NVD returned inside a range it says has matches. On a partial page it names the offset that reaches the next one. |
| offset | No | Page offset used in this query. |
| returned | No | Number of CVE records returned. |
| totalCount | No | Total CVEs matched before pagination. |
| auditTarget | No | The CPE name or virtual match string used for this audit. |
| severityMin | No | The client-side minimum severity filter applied. Absent when none was set. |
| filteredCount | No | CVEs below severityMin on every CVSS band, or with no scores, on the page NVD returned. Present whenever severityMin is set; 0 means none were dropped. Bands across all versions are evaluated independently of the row headline; CVEs beyond limit were not evaluated. |
| effectiveLimit | No | Page size or ID count used after clamping. |
| requestedLimit | No | Requested page size or ID count before clamping. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the baseline is lower; the description adds meaningful context beyond them — that cpeName scoping excludes dependency-only references, and that results include SSVC assessments. It doesn't discuss pagination or response size, but the schema covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core purpose, then the input constraint, then the scoping nuance, then the prerequisite pointer. No 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?
An output schema exists and the description still notes what comes back (full CVE records with SSVC). Given the rich schema and annotations, 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 baseline is 3; the description adds the mutual-exclusivity/either-or requirement that the schema itself doesn't enforce (no oneOf), plus the coupling of versionStart/versionEnd to virtualMatchString. That is genuine meaning beyond the field descriptions.
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 ('Find all CVEs affecting a specific product and version using CPE') and names the sibling nvd_search_cpes as the prerequisite resolver. An agent can distinguish this from nvd_search_cves or nvd_get_cve by the CPE-scoped audit semantics.
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 clear context: 'Use nvd_search_cpes first to resolve the correct CPE string,' and states the cpeName-or-virtualMatchString requirement. It does not explicitly say when to prefer nvd_search_cves over this tool, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nvd_get_cveGet CVE DetailsARead-onlyIdempotentInspect
Fetch one or more CVEs by ID from the NIST National Vulnerability Database. Returns CVSS scores across all available versions (v2.0, v3.0, v3.1, v4.0), CWE weakness classifications, affected CPE configurations, CISA KEV fields, current SSVC assessments, and references. Up to 100 CVE IDs per call. For bulk lookups of more than 10 IDs, use brief: true — full records for 100 CVEs can exceed 1MB and exhaust context budgets.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | When true, returns trimmed records (ID, status, top CVSS score, KEV name, published date, and a truncated description) instead of full detail. Recommended for batches of more than 10 IDs. | |
| cveIds | Yes | One CVE ID or an array of CVE IDs; at most 100 are fetched per call. | |
| allLanguages | No | When true, keeps every localized description NVD supplies on each record, and full records render all of them. Default keeps English only, falling back to whatever exists if a record has no English entry. Brief records always carry a single truncated description. | |
| includeReferences | No | When false, omits the references array to reduce response size. | |
| includeConfigurations | No | When false, omits configurationNodes from full records and their rendered text. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cves | No | CVE records — full detail by default, trimmed rows when brief is true. |
| brief | No | Whether brief or full records were returned. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Explains when the requested ID count was clamped. |
| returned | No | Number of CVE records returned. |
| requested | No | Number of CVE IDs processed in this call. |
| missingIds | No | CVE IDs requested but not found in NVD. Absent when all IDs matched. |
| effectiveLimit | No | Page size or ID count used after clamping. |
| requestedLimit | No | Requested page size or ID count before clamping. |
| unprocessedIds | No | IDs beyond the processed prefix, deduplicated in request order and excluding IDs already attempted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only and idempotent, and the description adds value beyond them: the 100-ID cap per call, the excess-ID behavior interaction, and the size/context-budget risk of full records. That is exactly the operational context annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each loading-bearing: what it does, what it returns, and the guardrail for large batches. The most actionable constraint is front-loaded at the end where an agent scanning for cost limits will find it.
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 needn't be explained, yet the description still summarizes the payload shape (CVSS across versions, CWE, CPE, KEV, SSVC, references). Combined with the batch cap and size warning, an agent has everything needed to invoke 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%, so the baseline is 3; the description still adds the payoff of `brief` (trimmed vs full records) tied to a batch-size threshold, which is a usage heuristic beyond the schema's field text. It does not mention allLanguages/includeReferences/includeConfigurations, though those are well documented in the schema.
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 ('Fetch one or more CVEs by ID from the NIST National Vulnerability Database') and the ID-keyed retrieval makes it distinguishable from the sibling nvd_search_cves without opening either schema. It also enumerates the record contents returned, so the agent knows exactly what a call yields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete when-to-change-behavior rule ('For bulk lookups of more than 10 IDs, use brief: true') with the reason (1MB, context budgets). It does not explicitly route to the alternative sibling (nvd_search_cves) when the agent lacks IDs, but the 'by ID' framing implies the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nvd_get_cve_historyGet CVE Change HistoryARead-onlyIdempotentInspect
Retrieve the change history for a single CVE — CVSS score revisions, reference additions, status transitions (e.g., "Received" → "Analyzed"), and CPE configuration updates. Use when tracking a CVE's escalation or investigating when a score changed. Events are returned newest-first by default; pass order="oldest" for the CVE's earliest events. For the current record, call nvd_get_cve instead. The NVD history endpoint is significantly slower than other NVD endpoints, especially without an API key — set NVD_API_KEY for reliable operation.
| Name | Required | Description | Default |
|---|---|---|---|
| cveId | Yes | CVE identifier to retrieve history for (e.g., "CVE-2021-44228"). | |
| limit | No | Maximum number of change events to return (default 20; values above 2000 are clamped unless NVD_CLAMP_LIMITS is false). | |
| order | No | Which end of the history to page from. Default "newest" returns the most recent events first, which is what escalation and re-score questions need. "oldest" returns NVD's native order (the CVE's first events first) and costs one upstream request, or two when the offset overruns the history; "newest" costs up to two on any history longer than limit. | newest |
| offset | No | Zero-based offset for paginating through change events, counted from whichever end order anchors to: offset 0 is the newest event under the default order="newest", and the oldest event under order="oldest". |
Output Schema
| Name | Required | Description |
|---|---|---|
| cveId | No | The CVE ID for which history was retrieved. |
| error | No | Present when the call failed. Absent on success. |
| order | No | Which end of the history this page was anchored to. |
| notice | No | Guidance on the shape of this page. When no events came back it distinguishes an offset past the end of the history, from an empty page NVD returned inside a range it says has events, from a CVE NVD holds no history for — the last of which covers both a record it has never revised and a CVE ID it does not hold. On a partial page it names the offset that reaches the next one, counted from the same end order anchors to. |
| offset | No | Page offset used in this query. |
| changes | No | CVE change events ordered to match the requested order — newest first by default, oldest first when order="oldest". |
| returned | No | Number of change events returned in this response. |
| totalCount | No | Total change events on record for this CVE. |
| effectiveLimit | No | Page size or ID count used after clamping. |
| requestedLimit | No | Requested page size or ID count before clamping. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds real context on top: the history endpoint is markedly slower than other NVD endpoints and needs NVD_API_KEY for reliable operation, which is operationally actionable. It stops short of describing error or truncation behavior when the history is enormous, keeping it at 4 rather than 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, then usage, ordering, sibling alternative, and the operational caveat. Each sentence carries distinct information; nothing is redundant with the title or with 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?
An output schema exists so return values need no explanation. Given four documented parameters, the description covers everything an agent needs: what it returns, when to choose it over the sibling, ordering semantics, and the auth/performance caveat.
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 schema already documents all four parameters thoroughly, setting a baseline of 3. The description reinforces only the order default ("newest-first by default; pass order=\"oldest\" for the CVE's earliest events") and adds no detail on cveId, limit, or offset beyond what the schema states.
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?
Specific verb+resource ("Retrieve the change history for a single CVE") plus an enumeration of what the history contains (CVSS revisions, reference additions, status transitions, CPE config updates). It is clearly distinguished from the sibling nvd_get_cve, which returns the current record rather than the delta trail.
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?
Explicit when-to-use ("tracking a CVE's escalation or investigating when a score changed") and an explicit alternative with its selection condition ("For the current record, call nvd_get_cve instead"). The default-order versus order="oldest" split is also tied to intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nvd_search_cpesSearch CPE DictionaryARead-onlyInspect
Search the NVD CPE (Common Platform Enumeration) dictionary by product keyword or partial match string. Returns CPE names, human-readable titles, and deprecation status. Use before nvd_audit_cpe to resolve the correct CPE name for a product — CPE strings are precise identifiers (e.g., cpe:2.3:a:apache:http_server:2.4.51:::::::*) and must match exactly to audit the right product.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of CPE entries to return (default 20; values above 10000 are clamped unless NVD_CLAMP_LIMITS is false). | |
| offset | No | Zero-based page offset for pagination. When totalCount exceeds offset + returned, raise offset to reach the rest — a vendor-level keyword has nothing left to narrow toward. | |
| keyword | No | Product name or vendor keyword (e.g., "apache http server", "openssl", "nginx"). At least one of keyword or cpeMatchString is required. | |
| cpeMatchString | No | Partial CPEv2.3 pattern (e.g., "cpe:2.3:a:apache:http_server"). At least one of keyword or cpeMatchString is required. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cpes | No | Matching CPE dictionary entries. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when no CPEs matched, the offset ran past the result set, NVD returned an empty page inside a range it says has matches, or entries remain beyond this page. |
| offset | No | Page offset used in this query. |
| returned | No | Number of entries returned in this response. |
| totalCount | No | Total matching CPE entries before the limit was applied. |
| effectiveLimit | No | Page size or ID count used after clamping. |
| requestedLimit | No | Requested page size or ID count before clamping. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered; the description adds that deprecation status is surfaced and that results are identifiers requiring exact matching. It omits rate limiting and pagination behavior, though the schema covers pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it does, what it returns, then the workflow rationale. Front-loaded with the search purpose and zero redundant restatement of the name or title.
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, full parameter documentation, and safety annotations already present, the only gap left for the description is cross-tool workflow — which it supplies. 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 coverage is 100%, so keyword, cpeMatchString, limit, and offset are already fully documented in the schema. The description reinforces how CPE strings look and why they matter but adds no format or syntax detail beyond the schema's own examples, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (NVD CPE dictionary) and explicitly names the fields returned: CPE names, titles, deprecation status. It also distinguishes the tool from the sibling nvd_audit_cpe by framing this as the resolution step that precedes auditing.
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 explicit sequencing guidance — 'Use before nvd_audit_cpe to resolve the correct CPE name' — and explains why the resolution step is necessary (CPE strings must match exactly). This is exactly the when-to-use framing an agent needs before picking among four siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nvd_search_cvesSearch CVEsARead-onlyInspect
Search CVEs by keyword, severity, CWE, date range, or CISA KEV status. The primary discovery tool for vulnerability surveillance and triage workflows. pubDays and lastModDays expand to date pairs; values over 120 days are clamped to the NVD maximum and reported in the response enrichment. Returns brief summaries — call nvd_get_cve for full detail on specific IDs. At least one filter is recommended; omitting all filters returns CVEs in default NVD index order (oldest first by CVE ID). Blank string filters are omitted with a notice; nonblank strings are trimmed.
| Name | Required | Description | Default |
|---|---|---|---|
| cweId | No | Filter by CWE weakness ID (e.g., "CWE-79", "NVD-CWE-Other"). | |
| limit | No | Maximum number of results to return (default 20; values above 2000 are clamped unless NVD_CLAMP_LIMITS is false). | |
| offset | No | Zero-based page offset for pagination. | |
| kevOnly | No | When true, filters results to CVEs in the CISA Known Exploited Vulnerabilities catalog. | |
| keyword | No | Full-text search across CVE descriptions (AND-semantics across words). | |
| pubDays | No | CVEs published in the last N days (max 120; values over 120 are clamped). Mutually exclusive with pubStartDate/pubEndDate. | |
| severity | No | Filter to CVEs in exactly this CVSS severity band — NVD matches the one band, not a floor. Covering several bands (e.g. HIGH and CRITICAL) takes one call per band. | |
| noRejected | No | When true (default), excludes CVEs with REJECT/Rejected status. | |
| pubEndDate | No | ISO 8601 datetime for publication range end. Both pubStartDate and pubEndDate required together. | |
| exactPhrase | No | When true, keyword matches as an exact phrase rather than ANDing its words independently. Requires keyword. | |
| lastModDays | No | CVEs last modified in the last N days (max 120; values over 120 are clamped). Mutually exclusive with lastModStartDate/lastModEndDate. | |
| pubStartDate | No | ISO 8601 datetime for publication range start. Both pubStartDate and pubEndDate required together. Mutually exclusive with pubDays. | |
| lastModEndDate | No | ISO 8601 datetime for last-modified range end. Both required together. | |
| severityVersion | No | CVSS version to use for the severity filter. Default: v3 (maps to cvssV3Severity). | v3 |
| lastModStartDate | No | ISO 8601 datetime for last-modified range start. Both required together. Mutually exclusive with lastModDays. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cves | No | Matching CVE summaries. Call nvd_get_cve for full detail on specific IDs. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Ignored blank filters and paging guidance: distinguishes no matches, an exhausted offset, and an inconsistent empty upstream page; on a partial page, names the next offset. |
| offset | No | Page offset used in this query. |
| returned | No | Number of CVEs returned in this response. |
| totalCount | No | Total matching CVEs in NVD before pagination. |
| datesClamped | No | Entries for any pubDays/lastModDays values that exceeded 120 and were auto-clamped. Absent when no clamping occurred. |
| effectiveLimit | No | Page size or ID count used after clamping. |
| filtersApplied | No | The non-default filters this query actually applied — the ones that can account for an empty or unexpectedly narrow result set. Absent when the query ran unfiltered, which is itself the answer when a result set is unexpectedly broad. |
| requestedLimit | No | Requested page size or ID count before clamping. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnly/openWorld annotations by disclosing clamping of pubDays/lastModDays at 120 days, reporting of clamping in response enrichment, blank-string filters being dropped with a notice, and trimming of nonblank strings. These are non-obvious behaviors an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the capability and purpose, then progressively adds behavioral detail with no filler sentences. It is somewhat dense across six sentences, but each carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter read-only search with a full output schema, everything needed to call it correctly is present: default ordering, filter-omission behavior, clamping limits, and the handoff to nvd_get_cve. Return-value detail is correctly deferred to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: pubDays/lastModDays expand into date pairs and interact with the explicit start/end parameters, and blank strings are silently omitted. It does not clarify severity band semantics (one band not a floor) or mutual exclusions, which remain schema-only.
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 CVEs') plus the exact filter dimensions it supports (keyword, severity, CWE, date range, KEV). It explicitly positions itself against the sibling nvd_get_cve, so an agent can distinguish discovery from detail retrieval 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?
It names itself the 'primary discovery tool' for surveillance and triage and routes detail lookups to nvd_get_cve. It also gives explicit fallback behavior when no filter is supplied ('returns CVEs in default NVD index order, oldest first'), covering the when-not case.
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.
5 tool updates
- Changed
nvd_audit_cpe13 fields changed- added
Input schema / properties / includeConfigurationsAdded value: +{ + "default": true, + "description": "When false, omits configurationNodes from each record and its rendered text.", + "type": "boolean" +} - added
Input schema / properties / includeReferencesAdded value: +{ + "default": true, + "description": "When false, omits references from each record and its rendered text.", + "type": "boolean" +} - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of CVEs to return (default 20, max 2000)."New value: +"Maximum number of CVEs to return (default 20; values above 2000 are clamped unless NVD_CLAMP_LIMITS is false)." - changed
Input schema / properties / limit / maximumPrevious value: -2000New value: +9007199254740991 - changed
Input schema / properties / severityMin / descriptionPrevious value: -"Filter out CVEs below this severity level. Applied after NVD returns the page, so it can only drop CVEs within limit — raise limit to widen what it sees."New value: +"Keep CVEs whose highest severity band across all CVSS versions meets this threshold, which can exceed the row headline severity. Applied after NVD returns the page, so only CVEs within limit are evaluated." - changed
Output schema / properties / cves / items / descriptionPrevious value: -"Full CVE record for one vulnerability affecting the product."New value: +"CVE record for one vulnerability affecting the product; configurations and references can be omitted by caller selectors." - added
Output schema / properties / cves / items / properties / ssvcAdded value: +{ + "description": "Current SSVC assessments in upstream order.", + "items": { + "additionalProperties": false, + "description": "One current SSVC assessment.", + "properties": { + "decisionPoints": { + "description": "Ordered option objects; repeated keys remain separate.", + "items": { + "additionalProperties": { + "anyOf": [ + { + "description": "Decision-point value.", + "type": "string" + }, + { + "description": "Decision-point values.", + "items": { + "description": "One decision-point value.", + "type": "string" + }, + "type": "array" + } + ], + "description": "One string or ordered list of strings." + }, + "description": "Decision-point names and values.", + "propertyNames": { + "description": "Decision-point name.", + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "role": { + "description": "Assessment role.", + "type": "string" + }, + "source": { + "description": "Contributor name or original source identifier.", + "type": "string" + }, + "timestamp": { + "description": "Assessment timestamp when provided.", + "type": "string" + }, + "version": { + "description": "SSVC decision-tree version.", + "type": "string" + } + }, + "required": [ + "source", + "role", + "version", + "decisionPoints" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / cves / items / requiredPrevious value: -[ - "cveId", - "vulnStatus", - "published", - "lastModified", - "descriptions", - "cvssScores", - "weaknesses", - "configurationNodes" -]New value: +[ + "cveId", + "vulnStatus", + "published", + "lastModified", + "descriptions", + "cvssScores", + "weaknesses" +] - added
Output schema / properties / effectiveLimitAdded value: +{ + "description": "Page size or ID count used after clamping.", + "type": "number" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `missing_cpe_input`: Neither cpeName nor virtualMatchString was provided. `conflicting_cpe_inputs`: Both cpeName and virtualMatchString were provided simultaneously. `version_range_without_match_string`: versionStart or versionEnd was provided without virtualMatchString. `invalid_cpe_format`: cpeName or virtualMatchString does not start with \"cpe:2.3:\", or NVD rejected it as a malformed CPE parameter — cpeName rejects anything short of a complete CPEv2.3 name, virtualMatchString only genuinely malformed characters. `rate_limited`: NVD returned HTTP 403 indicating the rate limit was exceeded. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `nvd_invalid_response`: NVD returned an invalid response. `nvd_request_blocked`: NVD blocked the request. `missing_cpe_input`: Neither cpeName nor virtualMatchString was provided. `conflicting_cpe_inputs`: Both cpeName and virtualMatchString were provided simultaneously. `version_range_without_match_string`: versionStart or versionEnd was provided without virtualMatchString. `invalid_cpe_format`: cpeName or virtualMatchString does not start with \"cpe:2.3:\", or NVD rejected it as a malformed CPE parameter — cpeName rejects anything short of a complete CPEv2.3 name, virtualMatchString only genuinely malformed characters. `rate_limited`: NVD explicitly reported that the rate limit was exceeded. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "missing_cpe_input", - "conflicting_cpe_inputs", - "version_range_without_match_string", - "invalid_cpe_format", - "rate_limited" -]New value: +[ + "nvd_invalid_response", + "nvd_request_blocked", + "missing_cpe_input", + "conflicting_cpe_inputs", + "version_range_without_match_string", + "invalid_cpe_format", + "rate_limited" +] - changed
Output schema / properties / filteredCount / descriptionPrevious value: -"CVEs dropped by the severityMin filter from the page NVD returned. Present whenever severityMin is set; 0 means the filter dropped nothing, so a narrow result reflects totalCount and limit instead. This is not totalCount minus returned — CVEs beyond limit were never fetched and so were never evaluated against the filter."New value: +"CVEs below severityMin on every CVSS band, or with no scores, on the page NVD returned. Present whenever severityMin is set; 0 means none were dropped. Bands across all versions are evaluated independently of the row headline; CVEs beyond limit were not evaluated." - added
Output schema / properties / requestedLimitAdded value: +{ + "description": "Requested page size or ID count before clamping.", + "type": "number" +}
- Changed
nvd_get_cve11 fields changed- changed
Input schema / properties / cveIds / anyOfPrevious value: -[ - { - "description": "A single CVE ID (e.g., \"CVE-2021-44228\").", - "type": "string" - }, - { - "description": "An array of CVE IDs — at least 1, up to 100 per call.", - "items": { - "type": "string" - }, - "maxItems": 100, - "minItems": 1, - "type": "array" - } -]New value: +[ + { + "description": "A single CVE ID (e.g., \"CVE-2021-44228\").", + "type": "string" + }, + { + "description": "An array of CVE IDs — at least 1. The first 100 are processed; excess IDs are reported unless NVD_CLAMP_LIMITS is false, which rejects them.", + "items": { + "description": "One CVE ID.", + "type": "string" + }, + "minItems": 1, + "type": "array" + } +] - changed
Input schema / properties / cveIds / descriptionPrevious value: -"One CVE ID or an array of up to 100 CVE IDs to fetch."New value: +"One CVE ID or an array of CVE IDs; at most 100 are fetched per call." - added
Input schema / properties / includeConfigurationsAdded value: +{ + "default": true, + "description": "When false, omits configurationNodes from full records and their rendered text.", + "type": "boolean" +} - added
Output schema / properties / cves / items / properties / ssvcAdded value: +{ + "description": "Current SSVC assessments in upstream order.", + "items": { + "additionalProperties": false, + "description": "One current SSVC assessment.", + "properties": { + "decisionPoints": { + "description": "Ordered option objects; repeated keys remain separate.", + "items": { + "additionalProperties": { + "anyOf": [ + { + "description": "Decision-point value.", + "type": "string" + }, + { + "description": "Decision-point values.", + "items": { + "description": "One decision-point value.", + "type": "string" + }, + "type": "array" + } + ], + "description": "One string or ordered list of strings." + }, + "description": "Decision-point names and values.", + "propertyNames": { + "description": "Decision-point name.", + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "role": { + "description": "Assessment role.", + "type": "string" + }, + "source": { + "description": "Contributor name or original source identifier.", + "type": "string" + }, + "timestamp": { + "description": "Assessment timestamp when provided.", + "type": "string" + }, + "version": { + "description": "SSVC decision-tree version.", + "type": "string" + } + }, + "required": [ + "source", + "role", + "version", + "decisionPoints" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / effectiveLimitAdded value: +{ + "description": "Page size or ID count used after clamping.", + "type": "number" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_cve_id_format`: One or more CVE IDs fail format validation (NVD returns HTTP 404 for malformed IDs). `cve_not_found`: A valid-format CVE ID returns no results — the ID is well-formed but does not exist in NVD. `rate_limited`: NVD returned HTTP 403 indicating the rate limit was exceeded. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `nvd_invalid_response`: NVD returned an invalid response. `nvd_request_blocked`: NVD blocked the request. `invalid_cve_id_format`: One or more CVE IDs fail format validation (NVD returns HTTP 404 for malformed IDs). `cve_not_found`: A valid-format CVE ID returns no results — the ID is well-formed but does not exist in NVD. `rate_limited`: NVD explicitly reported that the rate limit was exceeded. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_cve_id_format", - "cve_not_found", - "rate_limited" -]New value: +[ + "nvd_invalid_response", + "nvd_request_blocked", + "invalid_cve_id_format", + "cve_not_found", + "rate_limited" +] - added
Output schema / properties / noticeAdded value: +{ + "description": "Explains when the requested ID count was clamped.", + "type": "string" +} - changed
Output schema / properties / requested / descriptionPrevious value: -"Number of CVE IDs requested."New value: +"Number of CVE IDs processed in this call." - added
Output schema / properties / requestedLimitAdded value: +{ + "description": "Requested page size or ID count before clamping.", + "type": "number" +} - added
Output schema / properties / unprocessedIdsAdded value: +{ + "description": "IDs beyond the processed prefix, deduplicated in request order and excluding IDs already attempted.", + "items": { + "description": "Normalized CVE ID not attempted.", + "type": "string" + }, + "type": "array" +}
- Changed
nvd_get_cve_history6 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of change events to return (default 20, max 2000)."New value: +"Maximum number of change events to return (default 20; values above 2000 are clamped unless NVD_CLAMP_LIMITS is false)." - changed
Input schema / properties / limit / maximumPrevious value: -2000New value: +9007199254740991 - added
Output schema / properties / effectiveLimitAdded value: +{ + "description": "Page size or ID count used after clamping.", + "type": "number" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_cve_id_format`: The CVE ID fails format validation (NVD returns HTTP 404 for malformed IDs). `rate_limited`: NVD returned HTTP 403 indicating the rate limit was exceeded. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `nvd_invalid_response`: NVD returned an unusable response. `nvd_request_blocked`: The NVD security layer blocked the request. `invalid_cve_id_format`: The CVE ID fails format validation (NVD returns HTTP 404 for malformed IDs). `rate_limited`: NVD explicitly reported that the rate limit was exceeded. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_cve_id_format", - "rate_limited" -]New value: +[ + "nvd_invalid_response", + "nvd_request_blocked", + "invalid_cve_id_format", + "rate_limited" +] - added
Output schema / properties / requestedLimitAdded value: +{ + "description": "Requested page size or ID count before clamping.", + "type": "number" +}
- Changed
nvd_search_cpes6 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of CPE entries to return (default 20, max 10000)."New value: +"Maximum number of CPE entries to return (default 20; values above 10000 are clamped unless NVD_CLAMP_LIMITS is false)." - changed
Input schema / properties / limit / maximumPrevious value: -10000New value: +9007199254740991 - added
Output schema / properties / effectiveLimitAdded value: +{ + "description": "Page size or ID count used after clamping.", + "type": "number" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `missing_search_input`: Neither keyword nor cpeMatchString was provided. `invalid_cpe_format`: The cpeMatchString does not start with \"cpe:2.3:\", or NVD rejected it as a malformed CPE parameter. A merely truncated prefix is a legitimate partial match and returns an empty page instead. `rate_limited`: NVD returned HTTP 403 indicating the rate limit was exceeded. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `nvd_invalid_response`: NVD returned an unusable response. `nvd_request_blocked`: The NVD security layer blocked the request. `missing_search_input`: Neither keyword nor cpeMatchString was provided. `invalid_cpe_format`: The cpeMatchString does not start with \"cpe:2.3:\", or NVD rejected it as a malformed CPE parameter. A merely truncated prefix is a legitimate partial match and returns an empty page instead. `rate_limited`: NVD explicitly reported that the rate limit was exceeded. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "missing_search_input", - "invalid_cpe_format", - "rate_limited" -]New value: +[ + "nvd_invalid_response", + "nvd_request_blocked", + "missing_search_input", + "invalid_cpe_format", + "rate_limited" +] - added
Output schema / properties / requestedLimitAdded value: +{ + "description": "Requested page size or ID count before clamping.", + "type": "number" +}
- Changed
nvd_search_cves11 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (default 20, max 2000)."New value: +"Maximum number of results to return (default 20; values above 2000 are clamped unless NVD_CLAMP_LIMITS is false)." - changed
Input schema / properties / limit / maximumPrevious value: -2000New value: +9007199254740991 - added
Output schema / properties / effectiveLimitAdded value: +{ + "description": "Page size or ID count used after clamping.", + "type": "number" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `exact_phrase_without_keyword`: exactPhrase was set without a keyword. It selects how keyword matches and has nothing to modify on its own; NVD rejects the underlying flag on the same grounds. `mutually_exclusive_params`: Both pubDays and pubStartDate/pubEndDate provided, or both lastModDays and lastModStartDate/lastModEndDate. `missing_date_pair`: Only one of pubStartDate/pubEndDate (or lastModStartDate/lastModEndDate) was provided — NVD requires both. `date_range_inverted`: The end date is before the start date. `date_range_exceeds_max`: Explicit pubStartDate/pubEndDate or lastModStartDate/lastModEndDate span more than 120 days. `invalid_date_format`: A date string provided for pubStartDate, pubEndDate, lastModStartDate, or lastModEndDate is not a valid ISO 8601 datetime. `invalid_severity_for_version`: severity=\"CRITICAL\" was specified with severityVersion=\"v2\" — CVSS v2 has no CRITICAL tier. `rate_limited`: NVD returned HTTP 403 indicating the rate limit was exceeded. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `nvd_invalid_response`: NVD returned an unusable response. `nvd_request_blocked`: The NVD security layer blocked the request. `nvd_request_rejected`: NVD rejected a search parameter. `exact_phrase_without_keyword`: exactPhrase was set without a keyword. It selects how keyword matches and has nothing to modify on its own; NVD rejects the underlying flag on the same grounds. `mutually_exclusive_params`: Both pubDays and pubStartDate/pubEndDate provided, or both lastModDays and lastModStartDate/lastModEndDate. `missing_date_pair`: Only one of pubStartDate/pubEndDate (or lastModStartDate/lastModEndDate) was provided — NVD requires both. `date_range_inverted`: The end date is before the start date. `date_range_exceeds_max`: Explicit pubStartDate/pubEndDate or lastModStartDate/lastModEndDate span more than 120 days. `invalid_date_format`: A date string provided for pubStartDate, pubEndDate, lastModStartDate, or lastModEndDate is not a valid ISO 8601 datetime. `invalid_severity_for_version`: severity=\"CRITICAL\" was specified with severityVersion=\"v2\" — CVSS v2 has no CRITICAL tier. `rate_limited`: NVD explicitly reported that the rate limit was exceeded. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "exact_phrase_without_keyword", - "mutually_exclusive_params", - "missing_date_pair", - "date_range_inverted", - "date_range_exceeds_max", - "invalid_date_format", - "invalid_severity_for_version", - "rate_limited" -]New value: +[ + "nvd_invalid_response", + "nvd_request_blocked", + "nvd_request_rejected", + "exact_phrase_without_keyword", + "mutually_exclusive_params", + "missing_date_pair", + "date_range_inverted", + "date_range_exceeds_max", + "invalid_date_format", + "invalid_severity_for_version", + "rate_limited" +] - added
Output schema / properties / filtersApplied / properties / lastModEndDateAdded value: +{ + "description": "Effective last-modified range end sent to NVD.", + "type": "string" +} - added
Output schema / properties / filtersApplied / properties / lastModStartDateAdded value: +{ + "description": "Effective last-modified range start sent to NVD.", + "type": "string" +} - added
Output schema / properties / filtersApplied / properties / pubEndDateAdded value: +{ + "description": "Effective publication range end sent to NVD.", + "type": "string" +} - added
Output schema / properties / filtersApplied / properties / pubStartDateAdded value: +{ + "description": "Effective publication range start sent to NVD.", + "type": "string" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when no CVEs were returned — distinguishes a query nothing matched from an offset past the result set from an empty page NVD returned inside a range it says has matches — or, on a partial page, the offset that reaches the next one."New value: +"Ignored blank filters and paging guidance: distinguishes no matches, an exhausted offset, and an inconsistent empty upstream page; on a partial page, names the next offset." - added
Output schema / properties / requestedLimitAdded value: +{ + "description": "Requested page size or ID count before clamping.", + "type": "number" +}
5 tool updates
- First observed
nvd_audit_cpe - First observed
nvd_get_cve - First observed
nvd_get_cve_history - First observed
nvd_search_cpes - First observed
nvd_search_cves
Related MCP Connectors
Look up CVEs, CISA KEV, EPSS and open-source package vulnerabilities, including malicious packages.
Defensive vulnerability intelligence search across public CVE/NVD and GitHub advisory APIs with CVSS
CVE, KEV, EPSS, SBOM and advisory lookups; per-CVE exposure from Shodan data (© Shodan). Keyless.
CVE & vulnerability search: 365k+ CVEs/NotCVEs, CVSS, EPSS, CISA KEV, exploits, patches, versions.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables searching the NIST NVD for CVEs, retrieving full CVE details, checking software for known vulnerabilities, and searching the CPE database.1MIT
- FlicenseNot gradedqualityDmaintenanceEnables CVE vulnerability lookup and search using the National Vulnerability Database (NVD), allowing users to retrieve detailed information about specific CVEs and search for vulnerabilities by keyword.-
- AlicenseNot gradedqualityBmaintenanceEnables querying CVE vulnerability data from the NIST National Vulnerability Database, including CVE lookup, product/version search via CPE filters, CVSS severity scores, and recent high-severity disclosures.394 npmMIT
- AlicenseAqualityDmaintenanceEnables users to retrieve and display CVE vulnerability information from the National Vulnerability Database (NVD) with support for keyword search and detailed lookup.283 npm4MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.