get_cve ：
- 描述：通过 ID 检索 CVE 记录。
- 参数：
  - cve_id (str): CVE ID（例如， CVE-2019-1010218 ）。
  - concise （bool，默认为False ）：如果为True ，则返回更短的格式。
- 返回：详细的 CVE 信息，包括分数、弱点和参考。
search_cve ：
- 描述：通过关键字搜索 NVD 数据库。
- 参数：
  - keyword （str）：搜索词（例如， Red Hat ）。
  - exact_match (bool，默认为False )：如果为True ，则需要精确的短语匹配。
  - concise （bool，默认False ）：如果为True ，则返回较短的 CVE 记录。
  - results （int，默认值为10 ）：CVE 记录的最大数量（1-2000）。
- 返回：匹配的 CVE 列表及其总数。

配置

创建或编辑位于以下位置的 Claude Desktop 配置文件：
- 在 macOS 上： ~/Library/Application Support/Claude/claude_desktop_config.json
- 在 Windows 上： %APPDATA%/Claude/claude_desktop_config.json
添加以下内容：

{
  "mcpServers": {
    "mcp-nvd": {
      "command": "/path/to/uvx",
      "args": ["mcp-nvd"],
      "env": {
        "NVD_API_KEY": "your-api-key"
      }
    }
  }
}

将/path/to/uvx替换为uvx可执行文件的绝对路径。在终端中使用which uvx命令查找路径。这可确保启动服务器时使用正确版本的uvx 。
重新启动 Claude Desktop 以应用更改。

发展

设置

先决条件：
- Python 3.10 或更高版本。
- NVD API 密钥（在此处请求）。
- uv包管理器（安装）。
克隆存储库：

git clone https://github.com/marcoeg/mcp-nvd
cd mcp-nvd

设置环境变量：
- 在项目根目录中创建一个.env文件：
  NVD_API_KEY=your-api-key
- 用您的 NVD API 密钥替换your-api-key 。
安装依赖项：

uv sync
uv pip install -e .

使用 MCP 检查器运行

cd /path/to/the/repo
source .env

npx @modelcontextprotocol/inspector uv \
    --directory /path/to/repo/mcp-nvd run mcp-nvd

然后打开浏览器访问 MCP Inspector 指示的 URL，通常是http://localhost:8077?proxyPort=8078

在检查器中自由切换stdio和sse传输类型。

使用 SSE 客户端进行测试

运行服务器：

cd /path/to/the/repo
source .env

uv run mcp-nvd --transport sse --port 9090

默认在端口9090上使用 SSE 传输运行。

运行客户端：

测试get_cve ：

uv run client.py http://localhost:9090/sse CVE-2019-1010218

测试search_cve （默认10个结果）：

uv run client.py http://localhost:9090/sse "search:Red Hat"

测试search_cve （完全匹配，5个结果）：

uv run client.py http://localhost:9090/sse "search:Microsoft Windows:exact:5"

Docker 设置

建造

docker build -t mcp-nvd:latest .

跑步

使用.env ：

docker run -d -p 9090:9090 -v /path/to/.env:/app/.env mcp-nvd:latest

使用环境变量：

docker run -d -p 9090:9090 -e NVD_API_KEY="your-key" mcp-nvd:latest

自定义端口：

docker run -d -p 8080:8080 -v /path/to/.env:/app/.env mcp-nvd:latest uv run mcp-nvd --transport sse --port 8080 --host 0.0.0.0

核实

docker logs <container_id>
# Expect: INFO: Uvicorn running on http://0.0.0.0:9090

测试：

uv run client.py http://localhost:9090/sse CVE-2019-1010218

笔记

确保.env具有NVD_API_KEY=your-key或使用-e 。
默认端口： 9090 。

以下是代码块内格式化为 Markdown 注释的摘要，适合包含在docker-compose.yaml或README.md等文件中：

使用 Docker Compose 进行测试

docker-compose.yaml位于tests/目录中，它定义了一个使用预构建 Docker 镜像测试 MCP-NVD 服务器的服务。它专为测试用例而设计，类似于clickhouse之类的独立服务，并且假定镜像是预先构建的，而不是每次都重新构建。

假设

预构建镜像：该服务使用标记为mcp-nvd:test的预构建镜像，该镜像可在本地或镜像仓库中获取。该镜像基于父目录中的Dockerfile ，该文件使用uv设置了 MCP-NVD 服务器，并在端口 9090 上以 SSE 模式运行它。

如何构建图像

要创建mcp-nvd:test图像：

导航到项目根目录：
```
cd ./mcp-nvd
```
使用 Dockerfile 构建镜像：
```
docker build -t mcp-nvd:test .
```
- 这将使用来自pyproject.toml和mcp_nvd/模块的所有依赖项构建图像，并设置运行服务器的默认命令。

运行服务

从tests/目录：

cd tests
docker-compose up

访问：服务器运行在http://localhost:9090 。
停止： docker-compose down 。
环境：确保NVD_API_KEY在../.env中或使用docker-compose --env-file ../.env up 。

在 Docker Compose 场景中运行`test_tools.py`

要在 Docker 环境中运行单元测试（ test_tools.py ）：

启动服务：确保mcp-nvd服务正在通过docker-compose up运行。
执行到容器中：
- 使用以下命令识别容器名称（例如mcp-nvd-mcp-nvd-1 ）：
  docker ps
- 在容器内运行测试：
  docker exec -it mcp-nvd-mcp-nvd-1 python /app/tests/test_tools.py
- 注意：假设test_tools.py已复制到镜像的/app/tests/下。如果没有，请修改 Dockerfile 以包含以下内容：
  COPY tests/ ./tests/
  然后使用docker build -t mcp-nvd:test .从根目录重建映像。
替代方案：针对容器化服务在本地运行测试：
```
cd tests
python test_tools.py
```
- 这会在服务运行时针对http://localhost:9090进行测试。

关键细节

端口：9090 暴露给 SSE 访问。
日志：存储在log-data卷中（可选）。
图像：在运行docker-compose之前必须构建一次并标记为mcp-nvd:test 。

感谢@sidharthrajaram为基于 SSE 的 MCP 客户端和服务器提供的工作模式： https://github.com/sidharthrajaram/mcp-sse

Available Tools

2 tools

get_cveC

Get a CVE based on the ID and return a formatted string with detailed attributes.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	Yes
`concise`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a 'formatted string with detailed attributes,' which hints at read-only behavior but lacks specifics on permissions, rate limits, error handling, or data sources. For a tool with zero annotation coverage, this is insufficient to inform the agent about key operational traits like safety or performance constraints.

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

Conciseness4/5

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

The description is a single, straightforward sentence that efficiently conveys the core action and output. It's front-loaded with the main purpose and avoids unnecessary words, making it easy to parse. However, it could be slightly more structured by separating usage notes or parameter hints, but overall, it's concise and effective for its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of retrieving CVE data, the lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't address critical aspects like what 'detailed attributes' include, how errors are handled, or dependencies on external databases. For a tool with two parameters and no structured support, more context is needed to ensure reliable agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'based on the ID' and 'concise' (implied by 'formatted string'), but it doesn't explain what 'cve_id' entails (e.g., format like 'CVE-2024-12345') or what 'concise' does (e.g., reduces output detail). With low coverage, the description adds minimal value beyond the schema, failing to compensate for the documentation gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get a CVE based on the ID and return a formatted string with detailed attributes.' It specifies the verb ('Get'), resource ('CVE'), and output format ('formatted string with detailed attributes'), which is specific and actionable. However, it doesn't explicitly differentiate from its sibling tool 'search_cve', which likely searches for CVEs rather than retrieving a specific one by ID, leaving room for improvement in sibling distinction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions retrieving a CVE by ID but doesn't clarify scenarios where this is appropriate compared to 'search_cve' or other potential tools. There's no mention of prerequisites, exclusions, or contextual cues for selection, leaving the agent with minimal usage direction.

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

search_cveC

Search CVEs by keyword and return formatted results matching the get_cve format.

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	Yes
`exact_match`	No
`concise`	No
`results`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that results are 'formatted' to match 'get_cve format,' which adds some context about output behavior. However, it doesn't disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or what happens when no results are found. For a search tool with zero annotation coverage, this is insufficient.

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?

The description is extremely concise—a single sentence that efficiently communicates the core functionality. Every word earns its place: it specifies the action ('Search'), target ('CVEs'), method ('by keyword'), and output characteristic ('formatted results matching the get_cve format'). There's no wasted verbiage or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain parameter meanings, behavioral constraints, or output details beyond referencing another tool's format. For a search function that likely returns structured data, more context is needed about what 'formatted results' entail and how parameters affect the search.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The description only mentions 'keyword' generically and doesn't explain what 'exact_match', 'concise', or 'results' parameters do, their effects, or practical usage. It fails to compensate for the complete lack of schema documentation, leaving parameters largely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search CVEs by keyword and return formatted results matching the get_cve format.' It specifies the verb ('Search'), resource ('CVEs'), and scope ('by keyword'), but doesn't explicitly differentiate from its sibling tool 'get_cve' beyond mentioning the output format. This makes it clear but lacks sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the sibling tool 'get_cve' only in the context of output format, not as an alternative for different use cases. There are no explicit instructions on when to choose search_cve over get_cve or other potential tools, leaving the agent without contextual usage direction.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesDec 9, 2025
- First observedget_cve
- First observedsearch_cve

Deploy Server

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

TDQS

B3/5.0

Scored 2026-04-18 11:00 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: get_cve retrieves a specific CVE by ID, while search_cve finds CVEs by keyword. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on whether it needs a specific item or a broader search.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (get_cve and search_cve), using the same base noun 'cve' and descriptive verbs that clearly indicate their actions. This consistency enhances readability and predictability.

Tool Count2/5

With only 2 tools, the server feels thin for the domain of CVE management, as it lacks essential operations like filtering by date, severity, or vendor, or updating/creating entries. While the tools cover basic retrieval and search, the scope is incomplete for typical security workflows.

Completeness2/5

The tool surface is severely incomplete for CVE management, missing critical operations such as filtering by parameters like date range or CVSS score, handling CVE updates or annotations, and providing bulk operations. This will likely cause agent failures when more complex queries or actions are needed.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Nvd A
io.github.pipeworx-io
NVD MCP — wraps the NIST National Vulnerability Database API.
Security Government Data Open Data
432
EchelonGraph CVE & Exposure A
io.echelongraph
CVE, KEV, EPSS, SBOM and advisory lookups; per-CVE exposure from Shodan data (© Shodan). Keyless.
Security Penetration Testing Open Data
1612
Security Intel MCP A
io.github.selflabbs
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Security Penetration Testing
2
Security Intel MCP A
com.datakoot
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Penetration Testing Security
51

Related MCP Servers

cve-search_mcp
Security Open Data Search
roadwy
A
license
B
quality
D
maintenance
A Model Context Protocol (MCP) server for querying the CVE-Search API. This server provides comprehensive access to CVE-Search, browse vendor and product、get CVE per CVE-ID、get the last updated CVEs.
Updated a year ago (2025-07-26 14:17 UTC)
6
107
MIT
MCP NVD Server
Monitoring Security Documentation Access
gkhays
A
license
B
quality
D
maintenance
A Model Context Protocol server that retrieves CVE information from the National Vulnerability Database, allowing AI models to access up-to-date vulnerability data.
Updated a year ago (2025-05-16 20:56 UTC)
1
7
Apache 2.0
MCP Vulnerability Checker
Security Testing & QA Tools
firetix
A
license
A
quality
D
maintenance
A Model Context Protocol server providing security vulnerability intelligence tools including CVE lookup, EPSS scoring, CVSS calculation, exploit detection, and Python package vulnerability checking.
Updated a year ago (2025-05-23 02:32 UTC)
8
9
MIT
CIRCL CVE SEARCH MCP Server
Security Open Data Research & Data
Cyreslab-AI
A
license
A
quality
C
maintenance
A Model Context Protocol (MCP) server for accessing the CIRCL CVE SEARCH API, providing comprehensive vulnerability and security information.
Updated 23 days ago (2026-09-20 12:01 UTC)
5
11
MIT

Appeared in Searches

MCP server for analyzing CVEs (Common Vulnerabilities and Exposures)

NVD 数据库 MCP 服务器

地位

特征

工具

配置

发展

设置

使用 MCP 检查器运行

使用 SSE 客户端进行测试

运行服务器：

运行客户端：

Docker 设置

建造

跑步

核实

笔记

使用 Docker Compose 进行测试

假设

如何构建图像

运行服务

在 Docker Compose 场景中运行test_tools.py

关键细节

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

cve-search_mcp

MCP NVD Server

MCP Vulnerability Checker

CIRCL CVE SEARCH MCP Server

Appeared in Searches

在 Docker Compose 场景中运行`test_tools.py`