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., "@vulnscan-mcp what are the latest critical CVEs from the past week?"
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.
Vulnerability Intelligence MCP Server — an enterprise-grade Model Context Protocol server providing AI agents with real-time, correlated vulnerability intelligence.
vulnscan-mcp unifies data from four intelligence sources into a single normalized data fabric:
NIST NVD 2.0 — CVE details, CVSS scores, CWE classifications, CPE patterns
CISA KEV — Known Exploited Vulnerabilities catalog with active exploitation status
FIRST.org EPSS — Exploit Prediction Scoring System probability scores
MITRE ATT&CK — Adversary tactic and technique mappings
Related MCP server: CVE Intelligence MCP Server
🔍 5 MCP Tools for vulnerability search, CVE details, critical CVE tracking, KEV monitoring, and EPSS scoring
🔄 Automated Background Sync — NVD delta (2h), CISA KEV (12h), EPSS batch (24h) via APScheduler
💾 SQLite + FTS5 — Full-text search with 67K+ pre-loaded CVE records
🚀 Triple Transport — stdio for local IDE agents, sse + streamable-http on port 8001 for network agents
🐳 Docker Ready — Multi-stage build with non-root user
Python 3.11+
uv package manager
# Clone and install
git clone <repo-url> vulnscan-mcp
cd vulnscan-mcp
cp .env.example .env
# Edit .env with your NVD API key
uv sync# stdio mode (for Claude Desktop, Claude Code)
uv run vulnscan-mcp --transport stdio
# Network mode on port 8001 — serves both SSE and Streamable HTTP simultaneously
uv run vulnscan-mcp --transport sse --port 8001When running in network mode, the server exposes:
SSE at /sse (+ /messages for POST)
Streamable HTTP at /mcp
Health check at /
docker compose up -d
# SSE endpoint: http://localhost:8001/sse
# Streamable HTTP endpoint: http://localhost:8001/mcpTool | Description |
| Search CVEs by keyword, severity, date range, KEV status |
| Deep 360° enriched profile for a specific CVE |
| Recently published critical vulnerabilities |
| Top actively exploited vulnerabilities from CISA KEV |
| EPSS exploitation probability for one or more CVEs |
{
"mcpServers": {
"vulnscan": {
"command": "uv",
"args": [
"--directory", "/path/to/vulnscan-mcp",
"run", "vulnscan-mcp",
"--transport", "stdio"
],
"env": {
"NVD_API_KEY": "your_key_here"
}
}
}
}docker run -d -p 8001:8001 -v $(pwd)/data:/app/data --env-file .env vulnscan-mcp:latestConnect to: http://localhost:8001/sse
The server supports Streamable HTTP transport at the /mcp endpoint, which is the protocol used by ChatGPT and the OpenAI Responses API.
ChatGPT Plugin:
Add as a remote MCP server in ChatGPT settings using the URL:
https://your-domain.com/mcpOpenAI Responses API:
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(
model="gpt-4o",
tools=[
{
"type": "mcp",
"server_label": "vulnscan",
"server_description": "Vulnerability Intelligence MCP Server",
"server_url": "https://your-domain.com/mcp",
"require_approval": "never",
},
],
input="What are the latest critical CVEs from the past 7 days?",
)
print(resp.output_text)Note: ChatGPT requires your server to be reachable over HTTPS. For local/private servers, use OpenAI's Secure MCP Tunnel to expose your server without making it publicly accessible.
Variable | Default | Description |
| — | NVD API key for higher rate limits |
|
| Transport: |
|
| Network server port (serves both SSE and Streamable HTTP) |
|
| NVD delta sync interval |
|
| CISA KEV sync interval |
|
| EPSS batch enrichment interval |
MIT
Retrieve a comprehensive, deeply enriched 360-degree security profile for a CVE.
Returns NVD CVSS scores, CISA KEV active exploitation status, FIRST.org EPSS exploitation probability, MITRE ATT&CK tactics/techniques, and risk assessment.
Args: cve_id: Standardized CVE identifier (e.g., 'CVE-2021-44228', 'CVE-2024-3094').
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the data sources and enrichment layers returned, which is the key behavioral trait. However, it says nothing about read-only/non-mutating behavior, external API dependencies, rate limits, latency, caching, or failure modes (e.g., unknown CVE IDs), which are relevant for a tool aggregating multiple upstream feeds.
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 front-loaded with the purpose and return contents, followed by a compact Args block. Phrasing like 'comprehensive, deeply enriched 360-degree security profile' is slightly marketing-flavored, but the enumerated data sources keep it informative rather than bloated.
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?
An output schema exists, so return values need not be fully specified, and the description still summarizes them well. Given a one-parameter, read-style lookup with a defined output schema, the description is sufficient, though it could add a note on identifier format tolerance or failure behavior for unknown CVEs.
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 0%, so the description must compensate, and it does reasonably: it names the parameter and defines it as a 'Standardized CVE identifier' with concrete format examples ('CVE-2021-44228', 'CVE-2024-3094'). It stops short of noting validation behavior or case sensitivity, but the format guidance materially exceeds the bare 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 uses a specific verb ('Retrieve') with a clearly defined resource (a CVE security profile) and enumerates the exact data returned: NVD CVSS, CISA KEV, FIRST.org EPSS, MITRE ATT&CK, and risk assessment. This differentiates it from siblings like get_epss_score (single-signal) and search_vulnerabilities (discovery-oriented), making the distinct role of this lookup tool obvious.
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?
Usage is only implied: the tool takes a single cve_id and returns a comprehensive profile, suggesting it is for deep-dive lookup once an identifier is known, versus the sibling search/browse tools. There is no explicit 'use this when...' statement, no exclusions, and no mention of when a lighter sibling (e.g., get_epss_score) would suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query EPSS real-time exploitation probability scores for one or more CVEs.
Checks local cache first, then fetches from FIRST.org EPSS API for cache misses.
Args: cve_ids: List of CVE identifiers (e.g., ['CVE-2023-34362', 'CVE-2024-21887']).
| Name | Required | Description | Default |
|---|---|---|---|
| cve_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It usefully reveals cache-first lookup and FIRST.org EPSS API fetching for cache misses, but omits rate limits, auth needs, and error behavior.
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?
Front-loads the purpose, then briefly covers cache behavior and the argument. No redundant text; every sentence contributes useful 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?
Output schema exists, so return values need not be described. For a one-parameter tool, the description covers purpose, data source, and parameter meaning. The main gap is missing usage routing relative to sibling tools, but overall it is complete enough to call correctly.
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 0%, so the description carries full burden for the single parameter. It defines cve_ids as a list of CVE identifiers and provides concrete examples, adding meaningful semantics beyond the bare array schema. It could specify count limits or validation, but is sufficient for invocation.
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?
States a specific verb and resource: query EPSS real-time exploitation probability scores for CVEs. It clearly differentiates from siblings like get_cve_details and get_top_kevs by naming the exact data type.
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?
No explicit when-to-use or when-not-to-use guidance relative to siblings. The purpose implies usage, but the description gives no conditions, prerequisites, or alternatives for choosing this tool over get_cve_details or search_vulnerabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch newly published critical vulnerabilities from the synchronized database.
Args: days: Past calendar days to search (1-90, default: 7). min_cvss: Minimum base CVSS score threshold (7.0-10.0, default: 9.0). limit: Number of records to retrieve (1-50, default: 10).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| min_cvss | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only offers the vague phrase 'synchronized database.' It does not state auth requirements, rate limits, sort order, or whether this is read-only (implied by 'Fetch' but unconfirmed). Return format is covered by the output schema, so that omission is acceptable.
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?
One front-loaded purpose sentence followed by a compact, conventional Args block; nothing is redundant. Slightly more value could be added within the same footprint, but there is no wasted text.
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?
With an output schema present, return values need not be described, and all three parameters are fully documented with ranges and defaults. The main gap is the absence of behavioral context (source freshness, ordering, permissions) for an unannotated tool, but the core calling contract is complete.
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 0%, so the description must compensate, and it does: it documents all three parameters with meaning, valid ranges (days 1-90, min_cvss 7.0-10.0, limit 1-50) and defaults beyond what the bare schema shows. Only minor interpretive detail (e.g., what 'critical' implies relative to min_cvss) is missing.
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?
States a specific verb and resource with scope: 'Fetch newly published critical vulnerabilities from the synchronized database.' Combined with the name, an agent understands this returns recent high-severity CVEs, distinct in spirit from get_cve_details (single CVE) and get_top_kevs (KEV catalog), though it never explicitly names or contrasts those siblings.
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?
Usage is only implied: the 'newly published' framing plus the days parameter signals a recency-scan use case, but there is no explicit when-to-use, when-not-to-use, or routing guidance versus search_vulnerabilities or get_top_kevs. An agent must infer when this beats a general search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch actively exploited vulnerabilities from the CISA KEV catalog.
Returns KEV entries ordered by recent addition or EPSS threat probability.
Args: limit: Number of KEV items to return (1-50, default: 10). sort_by: Sort order — 'date_added' for newest or 'epss_score' for highest exploitation probability.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sort_by | No | date_added |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results are KEV entries and how they are ordered, but says nothing about permissions, rate limits, or freshness/staleness of the catalog. An output schema exists, which reduces the need to explain return values, keeping this at a middling score.
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?
Front-loaded with the core action and source in the first sentence, followed by return ordering and a compact Args block. Every sentence carries information an agent needs; no filler.
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 two-parameter read tool with an output schema, the description covers purpose, return ordering, and both parameters adequately. The remaining gap is routing guidance against the four sibling tools, which the description never addresses.
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 0% and the schema lacks ranges or enums, yet the description supplies the missing semantics: limit is 1-50 with a default of 10, and sort_by takes 'date_added' or 'epss_score' with their meanings spelled out. This fully compensates for the empty schema descriptions.
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?
States a specific verb and resource ('Fetch actively exploited vulnerabilities from the CISA KEV catalog') and pins the exact data source, which is more specific than generic vulnerability search. It does not, however, explicitly contrast itself with siblings like search_vulnerabilities or get_epss_score, so the differentiation is left to inference.
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 scope ('actively exploited vulnerabilities' from CISA KEV) implies when the tool is appropriate, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer that this is the KEV-listing tool rather than the general search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter vulnerabilities across local storage and synchronized feeds.
Search by keyword (CVE ID, component, vendor, description), filter by severity (LOW/MEDIUM/HIGH/CRITICAL), publication date range, and CISA KEV status.
Args: keyword: Search term matching CVE ID, component, vendor, or description. severity: Filter by CVSS severity: LOW, MEDIUM, HIGH, or CRITICAL. pubStartDate: Start publication date in ISO-8601 format (e.g., '2024-01-01'). pubEndDate: End publication date in ISO-8601 format (e.g., '2024-12-31'). hasKev: If True, filters for CVEs in the CISA Known Exploited Vulnerabilities catalog. limit: Maximum records to return (1-50, default: 20).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| hasKev | No | ||
| keyword | No | ||
| severity | No | ||
| pubEndDate | No | ||
| pubStartDate | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does add useful behavioral context: results span local storage plus synchronized feeds, and the limit is bounded 1-50 with a default of 20. It does not disclose result ordering, pagination beyond limit, or how local and feed results are merged/ranked, which matters for a 6-parameter query tool.
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?
Front-loaded summary sentence followed by a clean per-argument list; nothing is buried. There is mild duplication between the summary's 'search by keyword (CVE ID, component, vendor, description)' and the Args entry for keyword, but overall the structure is efficient.
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 6-parameter, all-optional tool with 0% schema coverage and an output schema present, the description covers all inputs, their formats, and the data sources. Remaining gaps are secondary behaviors like sort order and result merging, which the output schema does not necessarily convey.
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 0%, so the description must compensate, and it does so for every parameter: keyword match targets, the four severity enum values (not present as enums in the schema), ISO-8601 date format with concrete examples, hasKev semantics referencing the CISA KEV catalog, and the limit range plus default. This is meaningfully additive over the bare 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 states a specific verb pair (search and filter) and resource (vulnerabilities), plus the data scope (local storage and synchronized feeds). It implicitly separates itself from retrieval siblings like get_cve_details and get_top_kevs by being the general query entry point, though it never names those alternatives.
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?
Usage is implied by the filter dimensions (keyword, severity, date range, KEV status) rather than stated: an agent can infer 'use this to find CVEs matching criteria'. There is no explicit when-to-use-this-vs-a-sibling guidance (e.g., why not get_latest_critical_cves or get_top_kevs) and no exclusions or prerequisites.
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.0get_cve_detailsget_epss_scoreget_latest_critical_cvesget_top_kevssearch_vulnerabilitiesScored across 5 tools
Tools have distinct purposes: search_vulnerabilities is broad search, get_cve_details is deep dive for one CVE, get_latest_critical_cves is time-based filter, get_top_kevs is KEV catalog, get_epss_score is EPSS scores. Overlap exists between get_latest_critical_cves and search_vulnerabilities (can achieve similar results via filters), but descriptions clarify each tool's niche.
All tool names consistently follow a verb_noun pattern (search_vulnerabilities, get_cve_details, get_latest_critical_cves, get_top_kevs, get_epss_score), with clear action verbs and descriptive nouns. No deviations in style (all snake_case).
5 tools is well-scoped for a vulnerability scanning server, covering search, detail retrieval, critical alerts, KEV catalog, and EPSS scores without redundancy. Each tool earns its place.
Coverage is strong: search, details, latest criticals, KEV list, and EPSS scores. However, there's no tool for CVE enumeration by vendor/component or bulk export/update, which might be needed for full lifecycle. Minor gaps but core use cases are covered.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
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.
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
