Twenty-eight tools put broad CVE research behind one MCP server
CVE MCP Server exposes 28 tools and a triage_cve orchestrator across 24 named data sources. The useful idea is consolidation: an MCP client can gather NVD details, EPSS probability, CISA KEV status, OSV package findings, public exploit evidence, and selected threat-intelligence records through one local process. The orchestrator runs several of those lookups together and applies a documented risk formula. That can save an analyst repetitive browser work, but the returned score remains a project-defined aid rather than an official remediation rule.
The catalog reaches beyond CVE lookup. It includes IP reputation, passive DNS, malware and indicator searches, ransomware-address checks, dependency scanning, advisory search, report generation, and CVE prioritization. That breadth is the reason to try this project instead of a single-source script. It also raises the review burden: each upstream service has its own coverage, freshness, terms, and rate limits, while the assistant turns mixed evidence into a short answer.
Eight keyless tools are the sensible starting point
The README says 8 tools work without an API key, including EPSS, CISA KEV, OSV.dev, CVSS parsing, CWE lookup, and NVD at a reduced rate. Start there. It is enough to see whether MCP-assisted triage fits the team's workflow before distributing tokens for GitHub, VirusTotal, GreyNoise, Shodan, AbuseIPDB, URLScan, or CIRCL Passive DNS. The server loads those secrets from environment variables and says it excludes them from its local audit log.
Full coverage is much more involved than the basic install. The 24-source table mixes public feeds, free account tiers, authenticated services, and partner-only access. A result can therefore vary with the keys supplied and the limits left on each account. Teams need to record which sources were available for a decision, especially when triage_cve falls back from NVD to VulnCheck or when an enrichment tool returns no data.
What happened when we ran it
Our sandbox installed commit d666bac in 49 seconds, adding 77 packages and occupying 73 MB. The build completed in 9 seconds. The checkout contained 66 files and about 8,914 lines of source, with 3 CI workflow files, a Dockerfile, and a tests directory. Pip-audit found 0 known vulnerabilities in the installed Python environment. These figures describe our unprivileged Debian container with 3 CPUs and 8 GB of RAM.
Tests did not pass. The 23-second pytest run reported 26 passed and 4 failed out of 30. The failing cases covered tool registration, valid CVSS 3.1 parsing, invalid CVSS input, and the health check. Every failure ended with MCPError(-32000, 'Connection closed', None) inside an exception group. The log tail does not identify why the connection closed, so attributing the result to a package version, transport bug, or sandbox restriction would be guesswork.
That distinction matters because the repository's v0.2.0 release notes describe a passing suite, while our later checkout result is the only test outcome used here. The failure sits on the MCP boundary rather than an external threat feed: even the CVSS and health-check calls lost the connection. A trial should begin by reproducing the full suite in the intended Python environment, then exercising the exact client and transport that will be used in production.
Current dependency and license metadata need local decisions
Open issue 18, filed August 29, reports that fresh installs can resolve the declared mcp[cli]>=1.7.0 dependency to MCP 2.x, where the FastMCP import used by the project changed. The issue provides mcp<2 as a tested workaround. Our install itself succeeded, and the test log does not prove this report caused our 4 failures. Still, an unbounded major dependency on the protocol SDK is enough reason to pin a known working environment before deployment.
The license signals also conflict. GitHub reports Apache-2.0 and the LICENSE file contains Apache License 2.0 text. The README badge, README footer, and pyproject.toml classifier identify MIT. A developer experimenting locally can read the LICENSE file and move on. A company redistributing the package or documenting third-party obligations should ask the maintainer to reconcile those labels instead of copying whichever badge is convenient.
The security controls reduce risk but do not remove data exposure
The project blocks private and reserved IP ranges before network-intelligence lookups, uses defusedxml, keeps an SQLite cache, and writes a rotating audit log. Version v0.2.0 also added streamable HTTP, a non-root Dockerfile, source allowlists, and a statement that the server does not register MCP sampling. Those are useful controls for a tool that handles suspicious indicators and talks to many remote systems.
The privacy boundary is still external. CVE IDs, package names, hashes, domains, public IPs, and submitted URLs go to the corresponding providers. URLScan submission is a write operation even though most tools are lookups. Sensitive internal names should not be pasted into a public scanning service by habit, and HTTP transport should be bound and authenticated according to the surrounding environment rather than exposed because the default port happens to work.
August issue activity is newer than the June release
GitHub showed 1,324 stars and 11 combined issues and pull requests, with the last code push on August 5, 2026. The latest release was v0.2.0 on June 22. Issue activity continued on August 29 with the MCP 2.x compatibility report, so the project is receiving user scrutiny even though that report had no maintainer response when checked. The combined GitHub count should not be read as 11 bugs.
The decision is narrower than the 28-tool catalog suggests. CVE MCP Server is attractive when one analyst already consults several of these feeds and wants a repeatable first pass inside an MCP client. Our 9-second build and 0 known audited vulnerabilities make that trial inexpensive. The 4 connection failures, dependency range, conflicting license labels, and credential sprawl make an unattended rollout premature until the team pins, retests, and documents its actual source set.