Skip to main content
Glama

nist-nvd-mcp-server

Get CVE Change History

nvd_get_cve_history
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cveIdYesCVE identifier to retrieve history for (e.g., "CVE-2021-44228").
limitNoMaximum number of change events to return (default 20, max 2000).
orderNoWhich 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
offsetNoZero-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

TableJSON Schema
NameRequiredDescriptionDefault
cveIdNoThe CVE ID for which history was retrieved.
errorNoPresent when the call failed. Absent on success.
orderNoWhich end of the history this page was anchored to.
noticeNoGuidance 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.
offsetNoPage offset used in this query.
changesNoCVE change events ordered to match the requested order — newest first by default, oldest first when order="oldest".
returnedNoNumber of change events returned in this response.
totalCountNoTotal change events on record for this CVE.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context: newest-first default ordering, the ability to request oldest order, and a performance warning about the endpoint being slower without an API key. None of this contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences with no filler. The purpose is front-loaded, and each subsequent sentence adds distinct value: use cases, ordering behavior, alternative tool, and performance/API guidance. Every sentence 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?

Given the presence of a full output schema and a comprehensive input schema, the description covers the essential operational context: what the tool returns (change history types), when to use it, how to control ordering, and a critical performance caveat. Nothing an agent needs to call it correctly is missing.

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%, and the schema itself already provides rich descriptions for every parameter, including the order enum's cost implications and the offset anchoring. The description repeats the newest-first default but adds little beyond the schema. Since the schema carries the semantic load, a baseline 3 is appropriate.

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-resource pair ('Retrieve the change history for a single CVE') and enumerates the concrete change types (CVSS revisions, reference additions, status transitions, CPE updates). It also distinguishes itself from the sibling nvd_get_cve by explicitly directing agents to that tool for the current record, so there is no ambiguity.

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 gives explicit use cases ('tracking a CVE's escalation or investigating when a score changed') and an explicit exclusion ('For the current record, call nvd_get_cve instead'). It also adds operational guidance (set NVD_API_KEY due to endpoint slowness), which informs when to use it versus alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.