Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nvd-mcp Summarize risk for CVE-2021-44228, CVE-2022-22965, and CVE-2023-38545"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that brings NIST National Vulnerability Database (NVD) intelligence directly into Claude. Look up CVEs, search by product, and triage a list of vulnerabilities into a prioritized risk report — all from a natural-language prompt.
Built with FastMCP and the NVD REST API v2 (no API key required).
Tool | Description | Key inputs |
| Full details for a single CVE |
|
| CVEs by product or keyword, sorted by CVSS score |
|
| Severity breakdown + weighted risk score for a set of CVEs |
|
summarize_risk computes a composite risk score using the formula:
score = (CRITICAL×10 + HIGH×5 + MEDIUM×2 + LOW×1) / total_foundScore range: 0 (no risk) → 10 (all CRITICAL).
Related MCP server: NVD MCP Server
git clone <repo-url> nvd-mcp
cd nvd-mcp
uv venv --python 3.13
uv pip install -e ..venv/bin/nvd-mcpYou should see FastMCP start and wait on stdin — that confirms the server is working.
Press Ctrl-C to exit.
Open (or create) ~/Library/Application Support/Claude/claude_desktop_config.json
and add the nvd-mcp entry:
{
"mcpServers": {
"nvd-mcp": {
"command": "/absolute/path/to/nvd-mcp/.venv/bin/nvd-mcp"
}
}
}Replace /absolute/path/to/nvd-mcp with the actual path on your machine
(run pwd inside the project directory to get it).
Restart Claude Desktop. You should see nvd-mcp appear in the tools list.
Look up CVE-2021-44228 and tell me how severe it is.Find the 10 most critical CVEs affecting OpenSSL.Summarize the risk for CVE-2021-44228, CVE-2022-22965, and CVE-2023-38545.
Give me a recommended remediation priority.src/nvd_mcp/
├── server.py # FastMCP app — tool definitions and entry point
├── client.py # Async NVD API v2 HTTP client with retry/backoff
└── models.py # Pydantic v2 models: NVD response parsing + tool output typesThe NVD public API allows 5 requests per 30 seconds without an API key.
summarize_risk staggers its requests automatically. If you need higher throughput,
register for a free NVD API key and set the NVD_API_KEY environment variable
(the server will pick it up via the Authorization header — see client.py).
Note:
NVD_API_KEYsupport is a one-line addition to theNvdClientheaders dict; it is not wired up in this demo to keep the setup keyless.
# Type check
PYTHONPATH=src .venv/bin/pyright
# Run tests
PYTHONPATH=src .venv/bin/pytestLook up full details for a specific CVE by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | The CVE identifier, e.g. ``"CVE-2021-44228"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'look up full details' but does not specify whether the operation is read-only, idempotent, or requires authentication. It also fails to mention any potential errors or limits. With an output schema present, the description could still benefit from clarifying what 'full details' entails.
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?
The description is a single, concise sentence that is front-loaded and contains no unnecessary words. It efficiently conveys the essential purpose without any waste.
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?
Given that an output schema exists (as indicated by context signals), the description does not need to explain return values. For a simple single-CVE lookup tool, the description is sufficiently complete, though it could mention what happens if the CVE is not found.
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?
The input schema has 100% coverage for the single parameter, including a description and example value. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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?
The description clearly states the action ('look up full details') and the resource ('a specific CVE by ID'), making the tool's purpose unambiguous. It also implicitly distinguishes itself from siblings like 'search_cves' (which searches) and 'summarize_risk' (which summarizes).
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?
The description implies the tool is for looking up a single CVE by ID, but it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or typical use cases. The guidance is only implied by the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for CVEs by product name or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Product name or search term, e.g. ``"Apache Log4j"``. | |
| max_results | No | Number of results to return. Clamped to 1–20. Default 10. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears responsibility for behavioral disclosure. It only states 'Search for CVEs by product name or keyword' without revealing any behavioral traits such as rate limits, authentication needs, or pagination behavior.
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?
The description is a single, concise sentence that communicates the core functionality without any redundant or extraneous 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?
While the description covers the basic purpose and the schema documents parameters, it lacks additional context like search scoping, result ordering, or explanation of CVEs. An output schema exists, so return value details are assumed covered.
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?
The input schema has 100% coverage, with both parameters (keyword and max_results) described. The description's keyword mention adds no new meaning beyond the schema, warranting a baseline score of 3.
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?
The description clearly states 'Search for CVEs by product name or keyword.' It uses a specific verb ('Search') and resource ('CVEs') and distinguishes itself from siblings like 'lookup_cve' (likely single CVE lookup) and 'summarize_risk' (risk summary).
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?
The description implies usage for searching CVEs but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate a risk summary for a list of CVE IDs.
Fetches each CVE from NVD, computes a weighted composite risk score, and returns a severity breakdown with prioritized remediation guidance.
Risk score formula: (CRITICAL×10 + HIGH×5 + MEDIUM×2 + LOW×1) / total_found
Score range: 0 (no risk) → 10 (all CRITICAL).
| Name | Required | Description | Default |
|---|---|---|---|
| cve_ids | Yes | 1–10 CVE IDs, e.g. ``["CVE-2021-44228", "CVE-2022-22965"]``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavior: fetches from NVD, computes weighted composite score, returns severity breakdown and remediation guidance. Includes the formula and score range. No annotations exist, so description carries full burden, and it provides substantial behavioral details.
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?
Highly concise with no filler. Three short sentences: purpose, process, formula. Front-loaded with the main action. Every sentence adds value.
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 present, the description adequately covers purpose and process. It mentions expected output (severity breakdown, remediation guidance). Lacks detail on error handling or performance, but given simplicity and single parameter, it is fairly complete.
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% with clear description and example for cve_ids. Description adds minimal new meaning beyond the schema (e.g., mentions 'list of CVE IDs' but schema already specifies that). Baseline score applies as schema does the heavy lifting.
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?
Clearly states 'Aggregate a risk summary for a list of CVE IDs' with a specific verb and resource. Distinguishes from siblings lookup_cve (single CVE detail) and search_cves (search) by focusing on multiple CVEs and aggregation.
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?
Implies usage when a list of CVEs is present and an aggregate risk is needed, but does not explicitly state when not to use or provide alternatives to siblings. The description lacks exclusion criteria or comparison with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: lookup a specific CVE, search by keyword, and aggregate risk for multiple CVEs. No overlap in functionality.
All tools use a consistent verb_noun snake_case pattern: lookup_cve, search_cves, summarize_risk.
Three tools is slightly on the low side but appropriate for a focused NVD query and risk assessment domain. Each tool is essential.
The tool set covers the full workflow: finding CVEs (search), getting details (lookup), and summarizing risk (summarize). No obvious gaps for the intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/derrickjudge/nvd-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
