Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cve-lookup-mcp Look up CVE-2024-21626"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants live access to CVE data from the National Vulnerability Database (NVD) and FIRST EPSS — no API key required.
Built for use with Claude Code and any other Model Context Protocol compatible client.
Tool | Description |
| Full details for a CVE — CVSS score, description, affected products, EPSS exploitation probability, references |
| Search NVD by keyword with optional severity and year filters |
| Find all HIGH/CRITICAL CVEs for a vendor/product (useful during version fingerprinting) |
Look up CVE-2022-41352Search for critical Zimbra RCE vulnerabilities from 2022Check CVEs for apache strutsRelated MCP server: CVE Intelligence MCP Server
pipx install cve-lookup-mcppip install cve-lookup-mcpgit clone https://github.com/Aashish-32/cve-lookup-mcp
cd cve-lookup-mcp
pip install -e .Add to your ~/.claude.json (Claude Code) or equivalent MCP client config:
{
"mcpServers": {
"cve-lookup": {
"command": "cve-lookup-mcp",
"args": []
}
}
}If installed from source, point directly at the script:
{
"mcpServers": {
"cve-lookup": {
"command": "python3",
"args": ["/path/to/cve-lookup-mcp/src/cve_lookup_mcp/server.py"]
}
}
}Restart your MCP client after adding the config.
Source | What it provides | Rate limit |
CVE details, CVSS scores, affected products | ~5 req/30s (no key), 50 req/30s (with key) | |
Exploitation probability score | None |
Without a key, NVD allows roughly 5 requests per 30 seconds. For heavier use, request a free API key from NVD and set it as an environment variable:
{
"mcpServers": {
"cve-lookup": {
"command": "cve-lookup-mcp",
"env": {
"NVD_API_KEY": "your-key-here"
}
}
}
}git clone https://github.com/Aashish-32/cve-lookup-mcp
cd cve-lookup-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e .Run the server manually (stdio mode):
cve-lookup-mcpTest with a raw JSON-RPC call:
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}' \
| cve-lookup-mcpMIT
Find HIGH and CRITICAL CVEs for a specific vendor/product. Ideal for assessing a detected software version during a security review or penetration test.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | Yes | Vendor or project name, e.g. 'zimbra', 'apache', 'wordpress' | |
| product | No | Product name, e.g. 'collaboration', 'struts', 'woocommerce' (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It transparently discloses that the tool filters by severity (HIGH and CRITICAL), which is a key behavioral trait. No contradictions or misleading information are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description adequately explains purpose and usage context. It could briefly mention the expected return format, but the current level is sufficient for a straightforward search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage with examples for vendor and product. The description adds no new parameter-level information beyond restating 'vendor/product', so it meets the baseline and does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds HIGH and CRITICAL CVEs for a specific vendor/product, using a specific verb ('Find') and resource. It distinguishes from sibling tools like lookup_cve and search_cves by targeting only severe CVEs and requiring vendor identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is ideal for security reviews and penetration tests. However, it does not explicitly exclude use cases or mention alternatives, leaving some ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a specific CVE by ID. Returns CVSS score, severity, description, affected products, EPSS exploitation probability, and references. Data sourced live from NVD and FIRST EPSS.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE identifier, e.g. CVE-2022-41352 or 2022-41352 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It mentions live data sourcing but omits error behavior (e.g., if CVE not found), rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and followed by return data. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup, the description covers input, output data, and data source. However, it lacks error handling details and usage differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the cve_id parameter with formatting examples, achieving 100% coverage. The description adds no further semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a specific CVE by ID and lists the returned data. It distinguishes itself from siblings (check_product_cves, search_cves) by focusing on a single CVE lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a specific CVE ID but does not explicitly state when to use it vs. alternatives like search_cves or check_product_cves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search NVD for CVEs matching a keyword. Useful for finding vulnerabilities in a specific product or technology. Results are sorted by CVSS score descending.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search term, e.g. 'zimbra rce', 'laravel', 'apache log4j' | |
| severity | No | Filter by minimum CVSS v3 severity (optional) | |
| year | No | Restrict results to a specific publication year, e.g. 2023 (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results are sorted by CVSS score descending, but lacks details on rate limits, result limits, or data freshness typical for external API calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and add a key behavior (sorting). No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and absence of output schema or annotations, the description adequately covers purpose, usage, and sorting behavior. It lacks mention of result limits or pagination, which are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add new parameter semantics beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search), resource (NVD for CVEs), and purpose (finding vulnerabilities in a product/technology). It distinguishes from siblings like lookup_cve and check_product_cves by focusing on keyword-based search across NVD.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating it's useful for finding vulnerabilities in a specific product or technology. However, it does not explicitly mention when not to use it or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_product_cveslookup_cvesearch_cvesScored across 3 tools
Each tool has a clearly distinct purpose: check_product_cves for product-specific high/critical CVEs, lookup_cve for a specific ID, and search_cves for keyword searches. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (check_product_cves, lookup_cve, search_cves), making it easy to predict their purpose.
With 3 tools, the set is well-scoped for a CVE lookup server. Each tool serves a distinct and essential function without unnecessary redundancy.
Covers the core use cases: keyword search, ID lookup, and product-based filtering. Missing a time-based or trending CVE lookup, but the essential workflows are complete for most security assessments.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
CVE lookup via NIST NVD, CISA KEV, EPSS, and MITRE ATT&CK. 7 tools.
