cve-mcp-server: A Model Context Protocol Server for CVE Triage in Claude
Production-grade MCP server giving Claude 27 security intelligence tools across 21 APIs — CVE lookup, EPSS scoring, CISA KEV, MITRE ATT&CK, Shodan, VirusTotal, and more.
At a glance
- What is it?
- A Python MCP server that gives Claude 27 security intelligence tools across 21 APIs, fronted by a triage_cve orchestrator that fans out to NVD, EPSS, CISA KEV and other sources. Useful if you already live in Claude Desktop or Claude Code and want correlated vulnerability data without opening a dozen tabs.
- Who is it for?
- Adopt cve-mcp-server if your vulnerability triage already happens inside Claude Desktop or Claude Code and you want the fan-out to NVD, EPSS and CISA KEV done in one call rather than by hand. Do not adopt it if your workflow lives in a ticketing system, a SIEM, or a CI pipeline that cannot speak MCP over stdio, or if you need an air-gapped triage path.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 42 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The tab-juggling problem this server is built to replace
The README frames the pain directly: triaging one CVE means pulling CVSS from NVD, exploitation probability from EPSS, active-exploitation status from CISA KEV, patch references from GitHub, and malware associations from VirusTotal, then correlating all of it by hand. The stated cost is an entire day for 50 CVEs. That is the problem statement, and it is a fair one for anyone who has done vulnerability triage at volume.
The intended user is a security analyst or DevSecOps engineer who already uses Claude as a working surface. The server does not try to be a standalone dashboard or a scanner. It assumes an MCP client is on the other end, so the value depends on Claude being where your triage conversation already happens. If your triage output has to land in a ticket, a chat channel, or a report template, the server gets you the correlated evidence but does not deliver it anywhere on its own.
triage_cve as the single entry point, and what it fans out to
Version 0.2.0 added triage_cve, described in the README as a one-call orchestrator. The documented behaviour: it fans out NVD, EPSS, and CISA KEV concurrently, plus a public proof-of-concept lookup when depth is not set to quick, computes a composite risk score, and applies what the README calls a CISA KEV hard override. At depth="deep" it also emits an SSVC v2 gated decision. The example given is triage_cve("CVE-2021-44228", depth="deep").
The fallback path is worth noting. When NIST NVD is throttled, the orchestrator falls back to VulnCheck NVD++. That is a real operational detail: NVD rate limits are a known friction point, and the project has chosen a specific second source rather than simply failing. Whether the fallback produces identical field coverage is not stated in the material, so treat that as something to confirm against your own results.
The remaining 26 tools are individual lookups. The catalog groups them into vulnerability intelligence (NVD, EPSS/FIRST, CISA KEV, OSV.dev, GitHub GHSA, MITRE ATT&CK), network intelligence (AbuseIPDB, GreyNoise v3, Shodan, CIRCL PDNS), and threat intelligence (VirusTotal, MalwareBazaar, ThreatFox, Ransomwhere, AlienVault, URLScan.io). The README also exposes MCP resources: kev://catalog, epss://scores/{cve_id}, and manifest://tool-hash, the last being a SHA-256 hash over the registered tool surface for tamper detection. Three prompts are registered as well: patch_decision, compare_and_prioritize, and dependency_triage.
Architecture: stdio transport, outbound HTTPS, SQLite cache
The architecture diagram shows Claude Desktop or Claude Code on top, connected to the server over MCP via stdio. Inside the server there are three components: the 27 MCP tools (the diagram says 27 while the catalog header says 28, a small inconsistency in the README), a composite risk engine, and a SQLite cache with an audit log. All outbound calls go through an async httpx client with a rate limiter and a response cache.
The network posture is stated plainly: all traffic is outbound HTTPS only, no inbound ports are opened, API keys come from environment variables and are never logged, and private or internal IP addresses are blocked from all lookup tools. That last point matters if you were hoping to point Shodan or AbuseIPDB lookups at internal ranges. You cannot, by design.
The dependency list is short and conventional for a Python service: FastMCP, httpx, aiosqlite, Pydantic v2, and defusedxml. defusedxml is a deliberate choice for parsing untrusted XML, which is the right instinct when you are pulling vulnerability feeds from third parties.
Installation and the API key surface
The README lists installation, API keys setup, and configuration as separate sections in its table of contents, and the tool catalog marks each tool with whether a key is required. lookup_cve and triage_cve are both marked free with no key required, though a key is recommended for NVD. That means you can get a useful triage path running with zero credentials, which is unusual and worth calling out.
The paid or keyed sources are the ones you would expect: Shodan, VirusTotal, AbuseIPDB, GreyNoise, and the rest of the network and threat intelligence group. The README does not enumerate every environment variable name in the portion available, so the exact config keys are something you will read from the API keys setup section and the repository's configuration files rather than from this article. What is documented is the model: keys live in environment variables, are loaded at startup, and are never logged.
Running tests is its own section in the table of contents, and the project ships a troubleshooting section. Both are signs of a repository that expects users to hit problems, which is honest but also a signal that first-run friction exists.
Where this server is the wrong tool
The transport is stdio and the client target is Claude Desktop or Claude Code. If your triage has to run headless in a CI pipeline, inside a container with no interactive client, or as part of a scheduled job, MCP over stdio is an awkward fit and you would be better served by calling the underlying APIs directly with a script.
There is a second constraint worth stating. The README explicitly says private and internal IP addresses are blocked from all lookup tools. For network intelligence that is correct behaviour, but it also means the server cannot be used to enrich internal asset data. It is an external-intelligence tool, not an internal asset correlator.
A third issue is the licence discrepancy. The repository metadata says Apache-2.0, while the README badge says MIT and the badge links to a LICENSE file. One of those is wrong. This is not a legal opinion, but before you ship anything built on this, open the LICENSE file and confirm which terms actually apply. Apache-2.0 and MIT differ on patent grants and attribution requirements, and a mismatch between a badge and a file is exactly the kind of thing that surfaces during a compliance review.
Finally, the README's own roadmap section is titled Roadmap and known limitations. That is where the maintainers have documented what does not work yet, and it is the first place to read before committing to the project.
How it compares to calling the same APIs from a script
The obvious alternative is a small Python script that hits the NVD, EPSS, and CISA KEV endpoints directly and joins the results. That approach gives you full control over output format, scheduling, and where results land. It also means you own the rate limiting, the retry logic, the NVD throttling fallback, and the caching yourself.
cve-mcp-server packages exactly those concerns. The composite risk engine, the KEV hard override, the SQLite response cache, the rate limiter, and the VulnCheck fallback are the parts you would otherwise write and maintain. The trade is that you get them only inside an MCP client, in the shape the server chose, with the scoring formula the project defined rather than one you tuned.
A second alternative is to keep using the vendor dashboards and the NVD web interface. That is what the project is arguing against, and for 50 CVEs the argument holds. But dashboards give you history, saved views, and export paths that an MCP tool call does not. If your team already has a vulnerability management platform with a working triage queue, the marginal gain here is smaller than the README implies.
Maintenance cost, caching, and what to verify first
Two releases are listed: v0.1.0 in April 2026 and v0.2.0 in June 2026, with the last push to main in August 2026. That is a young project with a short release history. The v0.2.0 notes describe triage_cve plus security hardening, which suggests the security posture was revised after the first release. Expect the tool surface and scoring behaviour to keep moving.
The maintenance burden that falls on you is the API key surface. Twenty-one APIs means twenty-one sets of terms, quotas, and rotation schedules. The server does not remove that work, it consolidates it behind one interface. If a key expires, the affected tools fail while the rest keep working, so partial degradation is the normal failure mode rather than a clean crash.
The SQLite cache and audit log are local state you will need to place, back up, and eventually prune. The README does not state a default retention policy in the material available, so check the configuration section for cache TTL and log rotation before you run this against a production triage queue.
What to verify first, in order: the LICENSE file against the Apache-2.0 metadata claim, the exact environment variable names in the API keys setup section, the cache and audit log paths and their retention defaults, and the contents of the Roadmap and known limitations section. Those four checks will tell you more about fit than the tool count does.
Editorial conclusion
Adopt cve-mcp-server if your vulnerability triage already happens inside Claude Desktop or Claude Code and you want the fan-out to NVD, EPSS and CISA KEV done in one call rather than by hand. Do not adopt it if your workflow lives in a ticketing system, a SIEM, or a CI pipeline that cannot speak MCP over stdio, or if you need an air-gapped triage path. Before installing, verify the actual licence file against the Apache-2.0 metadata, confirm which of the 21 API keys you can supply, and check whether the SQLite cache and audit log paths fit your filesystem and retention rules.
Community notes