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, default 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
- your-api-key NVD API キーに置き換えます。
依存関係をインストール:

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 インスペクターによって示された 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

env var の場合:

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 ) を実行するには:

サービスを開始します。docker docker-compose upを実行して、 mcp-nvdサービスが実行されていることを確認します。
コンテナ内で実行:
- コンテナ名 (例: 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としてタグ付けする必要があります。

SSE ベースの MCP クライアントとサーバーの動作パターンを提供してくれた@sidharthrajaramに感謝します: 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`を実行する