Skip to main content
Glama
enesjakozh
marcoeg

mcp-nvd

by marcoeg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Servidor MCP de base de datos NVD

PyPI - Versión

Una implementación de servidor de Protocolo de Contexto Modelo para consultar la Base de Datos Nacional de Vulnerabilidades (NVD) del NIST a través de su API. https://nvd.nist.gov/

Como requisito previo, se requiere una clave API NVD. ( Solicitar aquí ).

Estado

Funciona con la aplicación Claude Desktop y otros hosts y clientes compatibles con MCP utilizando los transportes stdio y sse .

Related MCP server: MCP NVD Server

Características

  • Consulta CVE específicos por ID con datos de vulnerabilidad detallados.

  • Busque en la base de datos NVD por palabra clave con opciones de resultados personalizables.

  • Admite el transporte de eventos enviados por el servidor (SSE) para la comunicación en tiempo real.

  • Compatible con clientes compatibles con MCP como Claude Desktop.

Herramientas

El servidor implementa las siguientes herramientas para consultar la base de datos NVD:

  • get_cve :

    • Descripción : Recupera un registro CVE por su ID.

    • Parámetros :

      • cve_id (str): El ID de CVE (por ejemplo, CVE-2019-1010218 ).

      • concise (bool, predeterminado False ): si es True , devuelve un formato más corto.

    • Devuelve : información CVE detallada que incluye puntuaciones, debilidades y referencias.

  • search_cve :

    • Descripción : Busca en la base de datos NVD por palabra clave.

    • Parámetros :

      • keyword (str): término de búsqueda (por ejemplo, Red Hat ).

      • exact_match (bool, predeterminado False ): si es True , requiere una coincidencia de frase exacta.

      • concise (bool, predeterminado False ): si es True , devuelve registros CVE más cortos.

      • results (int, predeterminado 10 ): número máximo de registros CVE (1-2000).

    • Devuelve : Lista de CVE coincidentes con recuento total.

Configuración

  1. Cree o edite el archivo de configuración de Claude Desktop ubicado en:

    • En macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • En Windows: %APPDATA%/Claude/claude_desktop_config.json

  2. Añade lo siguiente:

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

  1. Reemplace /path/to/uvx con la ruta absoluta al ejecutable uvx . Busque la ruta con which uvx en una terminal. Esto garantiza que se use la versión correcta de uvx al iniciar el servidor.

  2. Reinicie Claude Desktop para aplicar los cambios.

Desarrollo

Configuración

  1. Prerrequisitos :

  2. Clonar el repositorio :

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

  1. Establecer variables de entorno :

    • Cree un archivo .env en la raíz del proyecto:

      NVD_API_KEY=your-api-key

    • Reemplace your-api-key con su clave API de NVD.

  2. Instalar dependencias :

uv sync
uv pip install -e .

Ejecutar con el inspector MCP

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

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

Luego abra el navegador en la URL indicada por el Inspector MCP, normalmente http://localhost:8077?proxyPort=8078

Cambie libremente entre los tipos de transporte stdio y sse en el inspector.

Pruebas con el cliente SSE

Ejecutar el servidor:

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

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

  • Se ejecuta con transporte SSE en el puerto 9090 de forma predeterminada.

Ejecutar el cliente:

Prueba get_cve :

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

Prueba search_cve (10 resultados predeterminados):

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

Prueba search_cve (coincidencia exacta, 5 resultados):

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

Configuración de Docker

Construir

docker build -t mcp-nvd:latest .

Correr

Con .env :

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

Con variable de entorno:

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

Puerto personalizado:

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

Verificar

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

Prueba:

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

Notas

  • Asegúrese de que .env tenga NVD_API_KEY=your-key o use -e .

  • Puerto predeterminado: 9090 .

Aquí está el resumen formateado como comentarios Markdown dentro de un bloque de código, adecuado para su inclusión en un archivo como docker-compose.yaml o README.md :

Uso de Docker Compose para pruebas

Este docker-compose.yaml , ubicado en el directorio tests/ , define un servicio para probar el servidor MCP-NVD mediante una imagen de Docker precompilada. Está diseñado para un caso de uso de prueba, similar a un servicio independiente como clickhouse , y asume que la imagen se compila previamente en lugar de reconstruirse cada vez.

Suposiciones

  • Imagen precompilada : El servicio utiliza una imagen precompilada etiquetada como mcp-nvd:test , disponible localmente o en el registro. La imagen se basa en el Dockerfile del directorio principal, que configura el servidor MCP-NVD con uv y lo ejecuta en modo SSE en el puerto 9090.

Cómo construir la imagen

Para crear la imagen mcp-nvd:test :

  1. Vaya a la raíz del proyecto:

    cd ./mcp-nvd

  2. Construya la imagen usando el Dockerfile:

    docker build -t mcp-nvd:test .

    • Esto crea la imagen con todas las dependencias de pyproject.toml y el módulo mcp_nvd/ , configurando el comando predeterminado para ejecutar el servidor.

Ejecución del servicio

Desde el directorio tests/ :

cd tests
docker-compose up

  • Acceso : El servidor se ejecuta en http://localhost:9090 .

  • Detener : docker-compose down .

  • Entorno : asegúrese de que NVD_API_KEY esté en ../.env o use docker-compose --env-file ../.env up .

Ejecución test_tools.py en el escenario de Docker Compose

Para ejecutar las pruebas unitarias ( test_tools.py ) dentro del entorno Docker:

  1. Iniciar el servicio : asegúrese de que el servicio mcp-nvd se esté ejecutando mediante docker-compose up .

  2. Ejecutar en el contenedor :

    • Identifique el nombre del contenedor (por ejemplo, mcp-nvd-mcp-nvd-1 ) con:

      docker ps

    • Ejecute las pruebas dentro del contenedor:

      docker exec -it mcp-nvd-mcp-nvd-1 python /app/tests/test_tools.py

    • Nota : Se asume que test_tools.py se copia en la imagen en /app/tests/ . De lo contrario, modifique el Dockerfile para incluir:

      COPY tests/ ./tests/

      Luego reconstruya la imagen con docker build -t mcp-nvd:test . desde la raíz.

  3. Alternativa : ejecutar pruebas localmente contra el servicio en contenedor:

    cd tests
python test_tools.py

    • Esta prueba se realiza contra http://localhost:9090 mientras se ejecuta el servicio.

Detalles clave

  • Puerto : 9090 está expuesto para acceso SSE.

  • Registros : se almacenan en un volumen log-data (opcional).

  • Imagen : debe compilarse una vez y etiquetarse como mcp-nvd:test antes de ejecutar docker-compose .

Créditos a @sidharthrajaram por su patrón de trabajo para clientes y servidores MCP basados en SSE: 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