Skip to main content
Glama
enesjakozh
marcoeg

mcp-nvd

by marcoeg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

NVD 데이터베이스 MCP 서버

PyPI - 버전

API를 통해 NIST 국가 취약성 데이터베이스(NVD)를 쿼리하기 위한 모델 컨텍스트 프로토콜 서버 구현. https://nvd.nist.gov/

필수 조건으로 NVD API 키가 필요합니다. ( 여기서 요청하세요 )

상태

stdio 와 sse 전송을 모두 사용하는 Claude Desktop 앱 및 기타 MCP 호환 호스트와 클라이언트와 함께 작동합니다.

Related MCP server: MCP NVD Server

특징

  • 자세한 취약성 데이터를 사용하여 ID로 특정 CVE를 쿼리합니다.

  • 사용자 정의 가능한 결과 옵션을 사용하여 키워드로 NVD 데이터베이스를 검색하세요.

  • 실시간 통신을 위해 SSE(Server-Sent Events) 전송을 지원합니다.

  • Claude Desktop과 같은 MCP 호환 클라이언트와 호환됩니다.

도구

서버는 NVD 데이터베이스를 쿼리하기 위해 다음 도구를 구현합니다.

  • 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 (정수, 기본값 10 ): CVE 레코드의 최대 수(1-2000).

    • 반환 : 총 개수와 일치하는 CVE 목록입니다.

구성

  1. 다음 위치에 있는 Claude Desktop 구성 파일을 만들거나 편집하세요.

    • macOS의 경우: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows의 경우: %APPDATA%/Claude/claude_desktop_config.json

  2. 다음을 추가합니다.

지엑스피1

  1. /path/to/uvx``uvx 실행 파일의 절대 경로로 바꾸세요. 터미널에서 which uvx 명령이 실행되는 경로를 찾으세요. 이렇게 하면 서버를 시작할 때 올바른 버전의 uvx 사용됩니다.

  2. 변경 사항을 적용하려면 Claude Desktop을 다시 시작하세요.

개발

설정

  1. 필수 조건 :

  2. 저장소 복제 :

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

  1. 환경 변수 설정 :

    • 프로젝트 루트에 .env 파일을 만듭니다.

      NVD_API_KEY=your-api-key

    • your-api-key NVD API 키로 바꾸세요.

  2. 종속성 설치 :

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 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 .

다음은 docker-compose.yaml 이나 README.md 와 같은 파일에 포함하기에 적합한 코드 블록 내의 마크다운 주석 형식으로 요약한 것입니다.

테스트를 위해 Docker Compose 사용

tests/ 디렉터리에 있는 이 docker-compose.yaml 파일은 미리 빌드된 Docker 이미지를 사용하여 MCP-NVD 서버를 테스트하는 서비스를 정의합니다. 이 파일은 clickhouse 와 같은 독립형 서비스와 유사한 테스트 사용 사례용으로 설계되었으며, 이미지가 매번 다시 빌드되는 대신 미리 빌드된다고 가정합니다.

가정

  • 미리 빌드된 이미지 : 이 서비스는 로컬 또는 레지스트리에서 사용할 수 있는 mcp-nvd:test 태그가 지정된 미리 빌드된 이미지를 사용합니다. 이미지는 상위 디렉터리의 Dockerfile 기반으로 하며, 이 파일은 MCP-NVD 서버를 uv 로 설정하고 9090 포트에서 SSE 모드로 실행합니다.

이미지를 구축하는 방법

mcp-nvd:test 이미지를 생성하려면:

  1. 프로젝트 루트로 이동합니다.

    cd ./mcp-nvd

  2. 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 )를 실행하려면:

  1. 서비스 시작 : docker-compose up 통해 mcp-nvd 서비스가 실행 중인지 확인합니다.

  2. 컨테이너로 실행 :

    • 컨테이너 이름(예: 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 . 사용하여 루트에서 이미지를 다시 빌드합니다.

  3. 대안 : 컨테이너화된 서비스에 대해 로컬로 테스트를 실행합니다.

    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
NameRequiredDescriptionDefault
cve_idYes
conciseNo

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
NameRequiredDescriptionDefault
keywordYes
exact_matchNo
conciseNo
resultsNo

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.

  1. 2 tool updates
    • 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 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

Related MCP Connectors

Related MCP Servers

  • cve-search_mcp

    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.
    6
    107
    MIT

  • MCP NVD Server

    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.
    1
    7
    Apache 2.0

  • MCP Vulnerability Checker

    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.
    8
    9
    MIT

Appeared in Searches