nist-nvd-mcp-server

Search CVEs

nvd_search_cves

Read-only

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 are convenience shorthands that 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).

Input Schema

TableJSON Schema

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, max 2000).
`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

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark the tool read-only, and the description adds non-obvious behaviors: pubDays/lastModDays expand to date pairs with values over 120 days clamped and reported in response enrichment, and an unfiltered query returns NVD default index order (oldest first). It also discloses that results are brief summaries. No contradiction with readOnlyHint.

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?

Five sentences, each carrying distinct information: scope, role, shorthand behavior, routing to nvd_get_cve, and the unfiltered default order. The content is front-loaded with the main action and doesn't repeat schema or annotation details. No filler.

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 15-parameter tool with a rich schema and output schema, the description covers the high-level purpose, the key parameter behavior (clamping/date-pair expansion), the routing rule, and the unfiltered default. It could add operational details like rate limits and ordering for filtered queries, but the essential call-time behavior is present.

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% with detailed descriptions, defaults, enums, and mutual exclusions for all 15 parameters. The description adds a small amount beyond the schema: pubDays/lastModDays are 'convenience shorthands that expand to date pairs' and clamped values are 'reported in the response enrichment,' which tells the agent where to observe the clamp. This modest addition justifies a slight bump above the high-coverage baseline.

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 object ('Search CVEs') and enumerates the filter dimensions (keyword, severity, CWE, date range, KEV status). It positions the tool as the 'primary discovery tool' and explicitly routes full-detail lookups to nvd_get_cve, distinguishing it from that sibling. The resource focus on CVEs also separates it from nvd_search_cpes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a clear usage context: 'primary discovery tool for vulnerability surveillance and triage workflows.' It also gives an explicit when-not and alternative: since it 'returns brief summaries,' the agent is told to 'call nvd_get_cve for full detail on specific IDs.' The recommendation to use at least one filter and the warning about default index order provide operational guidance.

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

All nist-nvd-mcp-server tools Inspect

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.