NVD/NIST MCP server

Overview Schema Source Related Servers Discussions Admin

Get recently modified CVEs

nvd_get_modified_cves

Read-onlyIdempotent

Retrieve CVEs ordered by last-modified date, descending, to track recently modified vulnerabilities; supports a default 7-day window, filters, and pagination.

Instructions

Return CVEs ordered by last-modified date, newest first (ordering "last_modified_desc"). Defaults to the last 7 days: use days or an explicit start+end window (mutually exclusive, maximum 120 days). All filters are sent to NVD, so totalResults is the exact upstream total. Cached for 5 minutes; paginate by passing pagination.nextCursor back as cursor with the same filters and pageSize - the resolved window travels inside the cursor, so a relative days window stays stable across pages.

Input Schema

TableJSON Schema

Name	Required	Description
`end`	No	ISO-8601 window end (use with `start`)
`cvss`	No	CVSS metric filter; requires at least one of severity or metrics
`days`	No	Relative window in days counted back from now (default 7)
`start`	No	ISO-8601 window start (use with `end`)
`cursor`	No	Opaque signed cursor from the previous page: pass the response's pagination.nextCursor. Never build it by hand; it expires after 30 minutes and is bound to the filters, pageSize and date window.
`cpeName`	No	Optional CPE name filter
`kevOnly`	No	Only CISA KEV entries
`keyword`	No	Optional keyword filter
`pageSize`	No	Page size (default 20, maximum 50)
`noRejected`	No	Exclude rejected CVEs
`vulnStatuses`	No	Vulnerability statuses (Received, Awaiting Analysis, Undergoing Analysis, Analyzed, Modified, Deferred, Rejected). Spaced and camel-case spellings are both canonicalized, and the filter is applied by NVD.

Output Schema

TableJSON Schema

Name	Required	Description
`meta`	Yes	Cache/freshness metadata; warnings carries stale-fallback and truncation notices
`items`	Yes
`pagination`	Yes	Pagination block; nextCursor is null on the last page

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond annotations: notes the 5-minute cache, that filters are pushed upstream so totalResults is exact, that the resolved window is embedded in the cursor so a relative `days` window stays stable across pages, and the 30-minute cursor TTL. This is exactly the kind of pagination/caching contract an agent needs for a read tool.

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?

Front-loaded with return semantics and ordering, then window rules, then caching and pagination. Four dense sentences, no filler, every clause earns its place.

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?

With an output schema present, it needn't describe return values, and it covers the operational hazards (caching, cursor lifetime/binding, window exclusivity, upstream filtering) that an agent would otherwise guess wrong. Complete for an 11-param read 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?

Schema coverage is 100% and the schema already documents most params with enums and constraints. The description still adds non-obvious semantics: cursor binding to filters/pageSize/window and cursor stability with relative days, which the schema only partly conveys.

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 states precisely what the tool returns (CVEs ordered by last-modified date, newest first) and separates it from siblings like nvd_search_cves or nvd_get_cve by its ordering and windowing behavior. An agent can immediately tell this is the 'recently modified' feed.

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 explains the default window (last 7 days), the exclusive `days` vs `start`+`end` choice, and the 120-day cap. It doesn't explicitly say when to prefer a sibling (e.g. search_cves for keyword-driven queries), so it's clear but not fully routing.

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

Deploy Server