nist-nvd-mcp-server

The nist-nvd-mcp-server is a standalone MCP server from cyanheads that connects security tooling with the National Vulnerability Database operated by the National Institute of Standards and Technology. The submitted product page at https://nist-nvd.caseyjhand.com/mcp identifies a production Streamable HTTP deployment and points to the public repository at https://github.com/cyanheads/nist-nvd-mcp-server. Smithery lists the same cyanheads/nist-nvd-mcp-server source and gives the remote deployment endpoint https://nist-nvd-mcp-server--cyanheads.run.tools. The product page, deployment identity, and provider repository therefore establish a traceable and durable product boundary. The NIST NVD attribution is not inferred from the name alone: the provider description explicitly names the National Vulnerability Database, while the official NVD developer pages document the related CVE and CPE APIs.

Purpose and capabilities

According to the provider, the server supports searching and auditing CVEs by keyword, severity, CWE, CISA KEV status, and CPE. Its five documented tools cover retrieving one or more CVE records, searching CVE data, searching CPE names, querying CWE information, and checking CISA KEV status. An MCP client can use these tools to investigate known vulnerabilities affecting a software product, product name, or CPE in a structured way without implementing a separate NVD API integration. The results are research and automation data, not a binding risk classification and not a guarantee of completeness or correctness.

The product page says the server supports both STDIO for local use and Streamable HTTP for a remote deployment. This catalog entry deliberately describes the remote product page and its associated Smithery endpoint, while the repository establishes the standalone source identity. The remote deployment may change or become temporarily unavailable, so production users must check the endpoint, protocol version, and current tool schemas against provider sources before connecting. NVD data is time-sensitive. NVD documentation explains that large collections use offset-based pagination and that API 2.0 interfaces are the preferred method for staying current.

Authorization, privacy, and data sharing

Provider information indicates that an NVD API key may optionally be used for more reliable or less rate-limited queries. Such a key must remain only in the secure configuration of the operator's deployment and is not stored in this catalog. Operators must verify which authentication the selected remote deployment requires, which client identity is transmitted, and whether a local client forwards queries to the remote server. Starting an MCP process locally does not automatically mean that every processing step remains local when a connected model provider receives the tool request and response.

CVE and CPE queries can reveal confidential information about internal products, unpatched systems, or investigations even when the underlying NVD records are public. Search terms, version strings, internal product names, and model-generated context should be minimized. Operators should review retention, logging, storage location, subprocessors, and possible sharing by the remote service and model provider. Rate limits and access restrictions can differ according to NVD rules, deployment configuration, API-key use, and provider operations. The NVD is a relevant authoritative source, but the freshness and coverage of individual records must still be checked against current official NVD documentation.

Security boundaries and possible writes

The documented surface is oriented toward read-only security-data queries. The MCP server should therefore not be granted permission to patch systems, launch scanners, change tickets, or write other external state. If a client exposes additional tools, agent actions, or downstream integrations, they must be authorized separately and require human confirmation before every change. Responses, CVE descriptions, CPE titles, and search parameters are untrusted input and may contain prompt injection or misleading instructions. Clients should allowlist the official endpoint, enforce TLS, apply least privilege, log tool calls, and disable automatic follow-up actions.

The E-E-A-T basis for this entry is, according to the provider, the cyanheads repository and product page together with official NIST NVD documentation for the data source. This supports the attribution and documented scope, but it does not certify remote uptime or the correctness of every response. The server is therefore suitable for traceable research and inventory review, not as the sole basis for a binding security decision. Results should be compared with the operator's assets, vendor advisories, and the current NVD state.

An MCP client supporting STDIO or Streamable HTTP. Remote use requires network access, current provider authorization, and a review of rate limits and data sharing.

For remote use, configure the official endpoint https://nist-nvd-mcp-server--cyanheads.run.tools in the MCP client according to current provider and Smithery documentation. For local use, follow the installation guidance in the cyanheads repository.

https://nist-nvd-mcp-server--cyanheads.run.tools

According to the provider, the deployment may support an NVD API key for more reliable queries. Configure authentication only in the secure client or deployment; never store keys, tokens, or credentials in the catalog.

The documented tools read CVE, CPE, CWE, and KEV data. Queries may disclose internal product and version information. Do not grant write access to systems, scanners, tickets, or other external state.

Before remote use, review whether queries and model context are shared with the service or a model provider, logged, or retained. Minimize data and clarify storage location, subprocessors, deletion, and retention.

CVE text, CPE data, and remote responses are untrusted input and may contain prompt injection. Enforce TLS, endpoint allowlisting, least privilege, logging, and human approval for every downstream change.