Skip to main content
Glama
davidculver

CVE MCP Server

by davidculver
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

CVE MCP Server (Prototype)

A local, containerized Model Context Protocol (MCP) server that provides conversational access to a CVE (Common Vulnerabilities and Exposures) database.

PROTOTYPE: This is a project demonstrating MCP server implementation. It is functional but not production-ready.

Overview

This project enables natural-language queries against a local CVE database using any MCP-compatible client. All data is stored locally for privacy and can be refreshed from public CVE sources.

Related MCP server: CVE MCP Server

Features

  • Fully local - all data on your machine, stdio transport only

  • Refreshable CVE data from GitHub database

  • Runs in Docker

  • Works with MCP Inspector and other MCP clients

  • Three tools: get_cve_details, search_cves, get_statistics

Prerequisites

  • Docker (with docker compose support)

  • Python 3.11+ (for local development)

  • Node.js 18+ (for MCP Inspector)

Installation

New to this project? See INSTALLATION.md for tested, step-by-step installation instructions.

Python Dependencies

# Development
pip install -e ".[dev]"

# Docker/Production
pip install -r requirements.txt

Project uses pyproject.toml for configuration.

Configuration (optional)

Create a .env file to customize paths:

cp .env.example .env
# Edit CVE_REPO_URL, CVE_REPO_PATH, CVE_GITHUB_API_BASE, CVE_DB_PATH

Works fine without any configuration.

Quick Start with Run Scripts (Recommended)

Convenient shell scripts automate the testing workflow:

Docker Testing (Full Workflow)

# 1. Build and start Docker container
./run_docker.sh

# 2. Load CVE data (choose one):
docker exec cve-mcp-server python -m src.data_ingestion.loader --year 2024 --limit 100    # Quick
docker exec cve-mcp-server python -m src.data_ingestion.loader_optimized                  # Full dataset

# 3. Test with MCP Inspector
./run_test_inspector.sh    # Choose option 2 (Docker)

Local Testing (Full Workflow)

# 1. Setup environment
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

# 2. Load CVE data (choose one):
./run_load_limited.sh              # Quick: 100 CVEs from 2024
./run_load_optimized.sh            # Full: ~240K CVEs (6-7 min)
./run_load_optimized.sh 2024 2023  # Specific years only

# 3. Test with MCP Inspector
./run_test_inspector.sh            # Choose option 1 (Local)

Available Run Scripts

Script

Purpose

Usage

run_load_limited.sh

Load small dataset via API

./run_load_limited.sh [year] [limit]

run_load_optimized.sh

Load full/filtered dataset via Git

./run_load_optimized.sh [year1] [year2] ...

run_docker.sh

Build and start Docker container

./run_docker.sh

run_test_inspector.sh

Launch MCP Inspector for testing

./run_test_inspector.sh

Quick Start with Docker (Manual)

For detailed, tested step-by-step instructions, see INSTALLATION.md

1. Clone the Repository

git clone https://github.com/yourusername/cve-mcp-server.git
cd cve-mcp-server

2. Build Docker Image

sudo docker build -t cve-mcp-server .

Note: If you get "permission denied", either use sudo with all docker commands, or add your user to the docker group:

sudo usermod -aG docker $USER
# Log out and log back in

3. Start Container

sudo docker compose up -d

Verify it's running:

sudo docker ps

4. Load CVE Data

sudo docker exec cve-mcp-server python -m src.data_ingestion.loader --year 2024 --limit 100

This downloads ~100 recent CVEs from GitHub (takes 1-2 minutes).

5. Test with MCP Inspector

npx @modelcontextprotocol/inspector

Inspector configuration (if using sudo):

  • Command: sudo

  • Arguments: docker exec -i cve-mcp-server python -m src.mcp_server

  • Environment: PYTHONPATH=/app

Inspector configuration (if in docker group):

  • Command: docker

  • Arguments: exec -i cve-mcp-server python -m src.mcp_server

  • Environment: PYTHONPATH=/app

Note: If connection fails, restart MCP Inspector and try again.

Local Development (Without Docker)

1. Setup Python Environment

# Create virtual environment
python3 -m venv venv
source venv/bin/activate

# Install dependencies
pip install -r requirements.txt

2. Load CVE Data

python -m src.data_ingestion.loader --year 2024 --limit 100

3. Run MCP Server

python -m src.mcp_server

The server will wait for MCP client connections via stdio.

4. Test Locally with MCP Inspector

In a new terminal:

npx @modelcontextprotocol/inspector

Configuration:

  • Command: python

  • Arguments: -m src.mcp_server

  • Environment: PYTHONPATH=/path/to/cve-mcp-server

5. Run Unit Tests

# Test database operations
python tests/test_database.py

# Test MCP tools directly
python tests/test_tools.py

Available Tools

get_cve_details

Get detailed information about a specific CVE.

Parameters:

  • cve_id (string): CVE identifier like "CVE-2024-0001"

Example:

{
  "cve_id": "CVE-2024-0001"
}

Response:

{
  "cve_id": "CVE-2024-0001",
  "description": "A critical vulnerability in Apache HTTP Server...",
  "severity": "CRITICAL",
  "cvss_score": 9.8,
  "published_date": "2024-01-15",
  "modified_date": "2024-01-20",
  "references": ["https://..."]
}

search_cves

Search CVEs by keyword.

Parameters:

  • keyword (string): Search term

  • limit (integer): Max results, default 10

Example response:

{
  "query": "remote code execution",
  "count": 5,
  "results": [
    {
      "cve_id": "CVE-2024-0015",
      "severity": "HIGH",
      "cvss_score": 8.5,
      "description": "Remote code execution...",
      "published_date": "2024-01-10"
    }
  ]
}

get_statistics

Get database stats.

No parameters.

{
  "database_info": {
    "total_cves": 95,
    "date_range": {
      "oldest": "2024-01-05",
      "newest": "2024-02-15"
    },
    "last_update": "2025-01-18T14:32:00.123456"
  }
}

Data Management

Using Run Scripts (Recommended)

Local development:

# Quick test with limited data
./run_load_limited.sh              # Default: 100 CVEs from 2024
./run_load_limited.sh 2023 50      # Custom: 50 CVEs from 2023

# Full dataset or specific years
./run_load_optimized.sh            # All ~240K CVEs (6-7 min)
./run_load_optimized.sh 2024 2023  # Only 2024 and 2023

Docker:

# Quick test
docker exec cve-mcp-server python -m src.data_ingestion.loader --year 2024 --limit 100

# Full dataset
docker exec cve-mcp-server python -m src.data_ingestion.loader_optimized

# Specific years
docker exec cve-mcp-server python -m src.data_ingestion.loader_optimized --years 2024 2023

Manual Commands

Load More CVE Data (Local):

# Limited dataset via API
python -m src.data_ingestion.loader --year 2024 --limit 500

# Full dataset via Git clone
python -m src.data_ingestion.loader_optimized
python -m src.data_ingestion.loader_optimized --years 2024 2023

Load More CVE Data (Docker):

# Load 500 CVEs from 2024
docker exec cve-mcp-server python -m src.data_ingestion.loader --year 2024 --limit 500

# Load from different year
docker exec cve-mcp-server python -m src.data_ingestion.loader --year 2023 --limit 200

Performance & Benchmarks

Based on systematic benchmarking:

  • Full dataset load time: ~6-7 minutes (240,000 CVEs)

  • Database size: ~190 MB

  • Loading speed: 2,700+ CVEs/second (using optimized loader)

Load Full Dataset

# Using optimized loader (recommended)
python -m src.data_ingestion.loader_optimized

# Or in Docker
docker exec cve-mcp-server python -m src.data_ingestion.loader_optimized

See benchmarks/BENCHMARK_RESULTS.md for detailed analysis.

Check Database Status

# Using Docker
docker exec cve-mcp-server python -c "
import sys
sys.path.insert(0, '/app')
from src.database.db import init_db, get_stats
print(get_stats(init_db()))
"

# Using local Python
python -c "
import sys
from pathlib import Path
sys.path.insert(0, str(Path.cwd() / 'src'))
from database.db import init_db, get_stats
print(get_stats(init_db()))
"

Project Structure

cve-mcp-server/
├── src/
│   ├── mcp_server/           # MCP server implementation
│   │   ├── server.py         # Server and tool definitions
│   │   ├── tools.py          # Tool implementation logic
│   │   └── __main__.py       # Entry point
│   ├── database/             # Database layer
│   │   └── db.py             # SQLite schema and queries
│   ├── data_ingestion/       # CVE data pipeline
│   │   ├── loader.py         # GitHub API CVE fetcher
│   │   └── loader_optimized.py  # Git clone CVE fetcher
│   └── config.py             # Configuration management
├── data/                     # SQLite database (Docker volume)
├── tests/                    # Unit tests
│   ├── test_database.py      # Database operation tests
│   └── test_tools.py         # Tool logic tests
├── run_load_limited.sh       # Quick data load script (API)
├── run_load_optimized.sh     # Full data load script (Git)
├── run_docker.sh             # Docker build and start script
├── run_test_inspector.sh     # MCP Inspector testing script
├── Dockerfile                # Container image definition
├── docker-compose.yml        # Container orchestration
├── pyproject.toml            # Project configuration (PEP 621)
├── requirements.txt          # Python dependencies
├── .env.example              # Configuration template
├── CLAUDE.md                 # Architecture documentation
├── TESTING.md                # Testing guide
└── README.md                 # This file

Technologies Used

  • Python 3.11: Core language

  • MCP SDK: Model Context Protocol implementation

  • SQLite: Local database with full-text search capability

  • Docker: Containerization and deployment

  • GitHub CVE Database: Data source (CVEProject/cvelistV5)

  • pyproject.toml: Modern Python project configuration (PEP 621)

Testing

Quick Testing with Run Script (Recommended)

Use the convenient testing script that handles both local and Docker deployments:

./run_test_inspector.sh

The script will:

  1. Ask if you want to test Local or Docker deployment

  2. Validate prerequisites (virtual environment, container running, database exists)

  3. Display the correct MCP Inspector configuration

  4. Launch MCP Inspector automatically

Manual Testing with MCP Inspector

MCP Inspector provides an interactive UI to test all tools:

  1. Start the server (Docker or local)

  2. Run npx @modelcontextprotocol/inspector

  3. Configure connection (see Quick Start sections above)

  4. Test each tool with various inputs

For detailed testing procedures, see TESTING.md.

Unit Testing

# Database operations
python tests/test_database.py

# Tool implementations
python tests/test_tools.py

Troubleshooting

Docker Issues

Container won't start:

docker logs cve-mcp-server
docker compose down
docker compose up -d

No CVE data loaded:

./scripts/docker_load_data.sh

Rebuild after code changes:

docker compose down
docker build -t cve-mcp-server .
docker compose up -d

MCP Inspector Connection Issues

Connection fails with "unknown shorthand flag" error:

  • Restart MCP Inspector completely (Ctrl+C and rerun npx @modelcontextprotocol/inspector)

  • If using sudo for docker, set Command to sudo and Arguments to docker exec -i cve-mcp-server python -m src.mcp_server

  • If in docker group, set Command to docker and Arguments to exec -i cve-mcp-server python -m src.mcp_server

Connection fails:

  • Verify container is running: sudo docker ps

  • Check exact command: sudo docker exec -i cve-mcp-server python -m src.mcp_server

  • Ensure container name matches: cve-mcp-server

  • Ensure PYTHONPATH environment variable is set to /app

Tools not appearing:

  • Check server logs for import errors

  • Verify PYTHONPATH is set correctly in Inspector environment variables

Local Development Issues

Import errors:

  • Ensure virtual environment is activated

  • Check PYTHONPATH includes project root

  • Verify all dependencies installed: pip install -r requirements.txt

Database not found:

  • Check data/cve.db exists

  • Run data loader: python -m src.data_ingestion.loader

Limitations

  • Local only (stdio transport)

  • Basic keyword search, no FTS5 yet

  • Manual data refresh

  • No auth/security (local use only)

TODO

Things that would be nice to add:

  • SSE transport for network access

  • SQLite FTS5 for better search

  • Filter by CVSS score/severity/date ranges

  • Automated data refresh (cron job?)

  • Example UI with Streamlit or something

  • Maybe a REST API wrapper

  • CVE monitoring/alerts

  • Export to PDF/CSV

  • Stats dashboard

Contributing

Prototype project. PRs welcome for bug fixes, docs, or features from TODO list.

License

MIT - see LICENSE file

Credits

Note: This is a prototype. For production use you'd want proper security, auth, error handling, etc.

Available Tools

3 tools
get_cve_detailsA

Get detailed information about a specific CVE by its ID. Returns severity, CVSS score, description, and references.

ParametersJSON Schema
NameRequiredDescriptionDefault
cve_idYesThe CVE identifier (e.g., 'CVE-2024-0001')

TDQS

A3.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. While it mentions the return data (severity, CVSS score, etc.), it lacks information about error handling, rate limits, authentication requirements, or whether this is a read-only operation. The description adds some value but leaves significant behavioral gaps.

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 appropriately sized and front-loaded, consisting of two concise sentences that efficiently convey the tool's purpose and return values without any wasted words. Every sentence earns its place by providing essential information.

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

Completeness3/5

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

Given the tool's moderate complexity (single parameter, no output schema), the description is somewhat complete but lacks details on behavioral aspects like error handling or operational constraints. It covers the basic purpose and return data but does not fully compensate for the absence of annotations, leaving room for improvement in context.

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

Parameters3/5

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

The schema description coverage is 100%, with the parameter 'cve_id' fully documented in the schema. The description does not add any additional meaning or syntax details beyond what the schema provides, such as format examples or validation rules, so it meets the baseline for high schema coverage.

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

Purpose5/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 with a specific verb ('Get detailed information') and resource ('about a specific CVE by its ID'), and distinguishes it from sibling tools like 'get_statistics' and 'search_cves' by focusing on individual CVE details rather than aggregated statistics or search functionality.

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

Usage Guidelines4/5

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

The description implicitly suggests usage when detailed information about a specific CVE is needed, but does not explicitly state when to use this tool versus alternatives like 'search_cves' or provide exclusions. It provides clear context for retrieving details by CVE ID.

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

get_statisticsB

Get database stats (count, date range, last update)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/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 retrieves statistics but doesn't describe how it behaves—e.g., whether it's a read-only operation, if it requires authentication, potential rate limits, or what happens on errors. For a tool with zero annotation coverage, this is a significant gap in transparency.

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 a single, efficient sentence that front-loads the purpose ('Get database stats') and lists the specific statistics in parentheses. Every word earns its place, with no redundancy or unnecessary details, making it highly concise and well-structured.

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

Completeness3/5

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

Given the tool has 0 parameters, no annotations, and no output schema, the description is complete enough for a simple read operation. It specifies what statistics are retrieved, but lacks details on output format, error handling, or behavioral traits. For a tool of this complexity, it's minimally adequate but leaves gaps in context.

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

Parameters4/5

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

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it does specify the types of statistics returned (count, date range, last update), which provides context beyond the empty schema. Baseline for 0 parameters is 4, as it adequately handles the lack of parameters.

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 action ('Get') and resource ('database stats'), and specifies the types of statistics returned (count, date range, last update). It distinguishes itself from sibling tools (get_cve_details, search_cves) by focusing on database statistics rather than CVE data. However, it doesn't explicitly mention what database or system it refers to, keeping it from a perfect score.

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 doesn't mention prerequisites, such as needing access to the database, or compare it to sibling tools (get_cve_details, search_cves) for context. The usage is implied by the purpose but lacks explicit when/when-not instructions.

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

search_cvesB

Search CVEs by keyword in description

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYesSearch term to look for in CVE descriptions
limitNoMaximum number of results (default: 10, max: 50)

TDQS

B3.1/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 mentions searching by keyword but doesn't describe critical behaviors such as response format, pagination, error handling, rate limits, or authentication requirements. This is a significant gap for a search tool with no structured safety or operational hints.

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 a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for a simple search tool, making it easy for an agent to parse quickly.

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

Completeness3/5

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

Given the tool's moderate complexity (search with two parameters) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but fails to address behavioral aspects like result format or error conditions, leaving gaps that could hinder correct tool invocation by an agent.

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

Parameters3/5

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

Schema description coverage is 100%, with clear documentation for both parameters ('keyword' and 'limit'). The description adds minimal value beyond the schema, as it only reiterates that searching is by keyword in descriptions without providing additional syntax, examples, or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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 with a specific verb ('Search') and resource ('CVEs'), specifying it searches by keyword in descriptions. It distinguishes from sibling 'get_cve_details' (which likely retrieves specific CVE details) and 'get_statistics' (which likely provides aggregated data), though it doesn't explicitly mention these distinctions.

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 like 'get_cve_details' or 'get_statistics'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.

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. Dates show when Glama detected each change.

  1. 3 tool updates
    • First observedget_cve_details
    • First observedget_statistics
    • First observedsearch_cves
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: get_cve_details retrieves specific CVE data, get_statistics provides database metrics, and search_cves finds CVEs by keyword. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: get_cve_details, get_statistics, and search_cves. The naming is predictable and readable, with no deviations in style.

Tool Count3/5

With only 3 tools, the server feels thin for a CVE database server, as it lacks operations like filtering by severity, date, or CVSS score, or updating/listing capabilities. However, the core functions are present, making it borderline appropriate.

Completeness3/5

The server covers basic retrieval (get details, search) and statistics, but there are notable gaps: no create, update, or delete operations for managing CVEs, and no advanced querying options. This limits functionality but allows for core lookup tasks.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • CVE MCP Server

    CrypKaChu
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables CVE vulnerability lookup and search using the National Vulnerability Database (NVD), allowing users to retrieve detailed information about specific CVEs and search for vulnerabilities by keyword.
    -

  • vuln-intel-mcp

    rohanrajnist
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides CVE lookup, search, and exploit intelligence from public vulnerability sources (NVD, CISA KEV, EPSS) for AI agents to produce remediation guidance without consuming LLM tokens for data fetching.
    1
    MIT

  • vulnerability-registry-mcp

    feldboy
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables security analysts and risk managers to query a legacy CVE registry via natural language, providing tools for searching vulnerabilities, retrieving details, and obtaining statistics.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidculver/cve-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server