cve-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port when TRANSPORT=http (default 3000, bound to 127.0.0.1). | 3000 |
| TRANSPORT | No | Transport mode: 'stdio' (default) or 'http'. | stdio |
| NVD_API_KEY | No | NVD API key to raise rate limits (request one at https://nvd.nist.gov/developers/request-an-api-key). | |
| GITHUB_TOKEN | No | GitHub personal access token to raise GitHub API limits for advisories and PoC fetching. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cve_get_detailsA | Retrieve complete, authoritative details for a single CVE from the NIST NVD, enriched with real-time exploitation signals. Combines: NVD description, CVSS v2/v3.1/v4 base scores + vectors, CWE weakness types, affected-product CPE strings, and reference URLs — plus (by default) CISA KEV actively-exploited status and the EPSS exploitation-probability score. Args:
Returns (json): { id, published, lastModified, vulnStatus, descriptions, cvss[], cwes[], references[], cpe[], kev, epss }. Examples:
Errors:
|
| cve_searchA | Search the NIST NVD for CVEs by keyword, affected product (CPE), severity, KEV status, and publication date range. Args:
Returns (json): { total, count, offset, has_more, next_offset, results[] } where each result is a full CVE detail object. Examples:
Errors:
|
| cve_recentA | List CVEs published within a recent look-back window — for real-time monitoring of newly disclosed vulnerabilities. Args:
Returns (json): { total, count, offset, has_more, next_offset, results[] }, newest first by publish date. Examples:
|
| cve_get_pocsA | Discover public proof-of-concept (PoC) and exploit references for a CVE. Aggregates the nomi-sec "PoC-in-GitHub" index (public GitHub repos tagged to the CVE, ranked by stars) and, by default, Exploit-DB / exploit-tagged references from the NVD record. Returns links and metadata only — use cve_fetch_poc_code to retrieve a specific repo's contents. Intended for authorized defensive testing, detection engineering, and vulnerability triage. Args:
Returns (json): { cve_id, count, pocs: [ { source, name, url, description, stars, createdAt, updatedAt } ] }. Examples:
Notes:
|
| cve_fetch_poc_codeA | Fetch the actual proof-of-concept material from a GitHub repository: its top-level file listing plus the decoded README (bounded in size). Use after cve_get_pocs to inspect a specific PoC. Intended for authorized security research and defensive validation. Set GITHUB_TOKEN to raise rate limits and access more repos. Args:
Returns (json): { fullName, htmlUrl, files[], readme, readmeTruncated }. Examples:
Errors:
|
| cve_get_exploit_toolingA | Find packaged, ready-to-run exploit and scan tooling for a CVE: Metasploit Framework modules (Rapid7) and Nuclei templates (ProjectDiscovery). This is distinct from cve_get_pocs (raw proof-of-concept repos). For an operator, packaged tooling is usually more actionable: a Metasploit exploit module is point-and-shoot ( Intended for authorized penetration testing, detection engineering, and vulnerability triage. Args:
Returns (json): { cveId, metasploit: [ { fullname, name, type, rank, rankLabel, disclosureDate, hasCheck, sourceUrl } ], nuclei: [ { id, name, severity, cvssScore, filePath, sourceUrl } ] }. Metasploit rank: 0 Manual, 100 Low, 200 Average, 300 Normal, 400 Good, 500 Great, 600 Excellent. Type "exploit" is weaponized; "auxiliary" is typically a scanner/check. Examples:
Notes:
|
| cve_get_kevA | Query the CISA Known Exploited Vulnerabilities (KEV) catalog — the authoritative list of CVEs confirmed to be actively exploited in the wild. Two modes:
Args:
Returns (single): a KEV entry object, or a "not listed" message. Returns (list, json): { catalogVersion, dateReleased, total, count, startIndex, entries[] }. Examples:
|
| cve_get_epssA | Retrieve EPSS (Exploit Prediction Scoring System, by FIRST.org) scores for one or more CVEs. EPSS estimates the probability (0-100%) that a CVE will be exploited in the wild within the next 30 days, plus a percentile ranking across all scored CVEs. Useful for prioritizing patching beyond raw CVSS severity. Args:
Returns (json): { count, scores: [ { cve, epss, percentile, date } ] } (epss/percentile as fractions 0-1). Examples:
|
| cve_get_advisoriesA | Retrieve GitHub Security Advisories (GHSA) that reference a CVE — the best source for package-level impact (ecosystem, affected version ranges, first patched version). Args:
Returns (json): array of { ghsaId, summary, severity, cveId, htmlUrl, publishedAt, vulnerabilities: [ { ecosystem, packageName, vulnerableVersionRange, firstPatchedVersion } ] }. Examples:
Notes:
|
| cve_triageA | Produce a single prioritization verdict for a CVE by fusing every exploitation signal: CVSS severity, EPSS 30-day exploitation probability, CISA KEV (confirmed in-the-wild use / ransomware), and public proof-of-concept availability. Answers "should I drop everything for this, or can it wait?" — the judgment call an analyst otherwise makes by hand across four tools. Priority levels: ACT NOW (KEV / score ≥85) > HIGH (≥70) > ELEVATED (≥50) > MODERATE (≥30) > LOW. KEV membership always pins to ACT NOW. Score (0-100): CVSS up to 50, EPSS up to 40, and exploit availability up to 15 (weaponized Metasploit exploit module 15 > other packaged tooling 12 > public PoC 10). Args:
Returns (json): { cve_id, priority, score, rationale[], signals{ cvssScore, cvssSeverity, epss, epssPercentile, kevListed, kevRansomware, kevDueDate, pocCount, msfModuleCount, nucleiTemplateCount, weaponized }, tooling{ metasploit, nuclei }, description }. Examples:
Errors:
|
| cve_batch_triageA | Triage a list of CVEs in a single call and get them back ranked by priority — turn a scan or findings list into an ordered "fix this first" queue without one tool call per CVE. Each CVE is scored exactly as cve_triage does (CVSS + EPSS + CISA KEV + optional PoC/tooling), then results are sorted highest-priority first. EPSS is fetched for the whole batch in one request; unknown IDs are reported separately rather than failing the call. Args:
Returns (json): { requested, triaged, not_found[], results[] } where each result is { cve_id, priority, score, signals, description } sorted by score descending. Examples:
Errors:
|
| cve_watchlistA | Monitor a vendor or product for new and known-exploited vulnerabilities in one call — a digest that fuses NVD recent-publications with the CISA KEV catalog. Answers "what's new and what's on fire for right now?" without running cve_recent, cve_search, and cve_get_kev separately and cross-referencing by hand. Args:
Returns (json): { vendor, window_days, since, recent: { total, count, results[] }, kev: { total, entries[] }, kev_in_window }. Each recent result carries a kev_listed flag. Examples:
Errors:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool has a clear, distinct purpose: details, search, recent, PoCs, exploit tooling, KEV, EPSS, advisories, triage, batch triage, and vendor watchlist are all separated by explicit intent. Even potentially overlapping tools like cve_get_pocs vs cve_get_exploit_tooling are carefully delineated.
All tools share the cve_ prefix and mostly follow a verb_noun pattern. Minor deviations exist: cve_recent and cve_watchlist are noun/adjective-style rather than verb-led, and cve_batch_triage modifies cve_triage rather than using a uniform verb. Overall still highly predictable.
12 tools is well-scoped for a CVE intelligence server. Each tool covers a distinct aspect of vulnerability lookup, enrichment, and prioritization without redundancy, and the count feels appropriate for the domain.
The surface covers the full CVE workflow: discovery (search, recent, watchlist), detail retrieval (get_details, advisories), enrichment (KEV, EPSS, PoCs, tooling), and action (triage, batch triage). No significant gap in the stated purpose of providing comprehensive CVE intelligence and prioritization.