Provides vulnerability intelligence from GitHub, including security advisories with package-level impact (ecosystem, affected version ranges, first patched version) and public proof-of-concept repositories, with the ability to fetch a PoC repository's file listing and README.
Provides packaged Metasploit modules for CVEs, including reliability rank and run strings, to support exploitation testing and defensive triage.
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-mcp-server Triage these CVEs from last night's scan and rank them by priority: CVE-2024-3400, CVE-2023-23397, CVE-2021-44228"
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.
Realtime CVE intelligence over the Model Context Protocol. Gives an LLM one place to look up a vulnerability and get details, exploitation signals, and public proof-of-concepts aggregated from five authoritative sources:
Source | What it provides |
NIST NVD (API v2.0) | Description, CVSS v2/v3.1/v4 scores + vectors, CWE weaknesses, affected-product CPEs, references |
CISA KEV | Confirmed active-exploitation status, remediation due dates, ransomware-use flag |
FIRST.org EPSS | Probability a CVE is exploited in the next 30 days (+ percentile) |
GitHub Security Advisories | Package-level impact: ecosystem, vulnerable version ranges, first patched version |
nomi-sec PoC-in-GitHub + Exploit-DB | Public proof-of-concept repos (ranked by stars) and exploit references, with optional repo-content retrieval |
Metasploit + Nuclei | Packaged, ready-to-run tooling: Metasploit modules (Rapid7, with reliability rank) and Nuclei templates (ProjectDiscovery) referencing the CVE |
Tool | Purpose |
| Prioritization verdict fusing CVSS + EPSS + KEV + PoC into ACT NOW → LOW. |
| Triage up to 25 CVEs in one call, returned ranked by priority (turn a scan/findings list into a fix-first queue). |
| Vendor/product digest: recently published CVEs + that vendor's CISA KEV entries in one call. |
| Full enriched detail for one CVE (NVD + KEV + EPSS, with triage banner). |
| Search NVD by keyword, CPE, severity, KEV status, date range. |
| Recently published CVEs (realtime monitoring, up to 120-day look-back). |
| Discover public PoC / exploit references for a CVE. |
| Fetch a PoC repo's file listing + README. |
| Packaged Metasploit modules + Nuclei templates for a CVE (with run strings). |
| CISA KEV single lookup or catalog browse. |
| EPSS scores for one or many CVEs. |
| GitHub Security Advisories for a CVE. |
All tools are read-only and support response_format: "markdown" (default) or "json".
Related MCP server: Cybersecurity Threat Intelligence MCP
Requires Node.js 18+.
npm install
npm run buildAll are optional but recommended — they raise rate limits and coverage:
NVD_API_KEY — request one here (NVD throttles hard without it).
GITHUB_TOKEN — any GitHub PAT; raises the GitHub API limit for advisories and PoC fetching.
TRANSPORT — stdio (default) or http.
PORT — HTTP port when TRANSPORT=http (default 3000, bound to 127.0.0.1).
claude mcp add cve --env NVD_API_KEY=xxx --env GITHUB_TOKEN=ghp_xxx -- node /home/k4p/cve-mcp-server/dist/index.jsclaude_desktop_config.json){
"mcpServers": {
"cve": {
"command": "node",
"args": ["/home/k4p/cve-mcp-server/dist/index.js"],
"env": {
"NVD_API_KEY": "your-nvd-key",
"GITHUB_TOKEN": "ghp_your_token"
}
}
}
}"Tell me everything about Log4Shell, including whether it's actively exploited."
"What critical CVEs were published this week that are in the CISA KEV catalog?"
"Find public PoCs for CVE-2024-3400 and show me what's in the top repo."
"Is there a Metasploit module or Nuclei template for EternalBlue?"
"Rank CVE-2021-44228, CVE-2023-23397, and CVE-2024-3400 by EPSS exploitation likelihood."
"Here are 12 CVEs from last night's scan — triage them and tell me what to patch first."
"What's new for Fortinet this month, and which of theirs are actively exploited?"
"Which Maven packages does CVE-2021-44228 affect and in what version was it fixed?"
PoC and exploit tools surface already-public security research artifacts and are
intended for authorized defensive testing, detection engineering, and vulnerability
triage. cve_fetch_poc_code retrieves repository contents (file listing + README,
size-bounded) and cve_get_exploit_tooling links to public Metasploit/Nuclei source;
use them only against targets you are authorized to test.
cve_triage (and the banner on cve_get_details) turns four signals into one verdict:
Priority | Trigger |
🔴 ACT NOW | In CISA KEV (confirmed exploited), or composite score ≥ 85 |
🟠 HIGH | Score ≥ 70 |
🟡 ELEVATED | Score ≥ 50 |
🔵 MODERATE | Score ≥ 30 |
⚪ LOW | Score < 30 |
Composite score (0-100): CVSS contributes up to 50, EPSS up to 40, and exploit availability up to 15. Availability is a gradient (strongest signal wins, not additive): a weaponized Metasploit exploit module → 15, other packaged tooling (auxiliary module / Nuclei template) → 12, a public PoC → 10, none → 0. KEV membership hard-pins to 100. Each verdict comes with a plain-English rationale — including an explicit "severe on paper but low real-world signal → deprioritize" note when CVSS is high but EPSS/KEV/PoC/tooling are all cold.
Retries with backoff on 429/502/503/504 and network blips (honors Retry-After) — so
NVD's strict unauthenticated rate limit doesn't fail a triage mid-run.
CVE-detail lookups cached 15 min in-process (the same CVE is queried repeatedly across
cve_get_details / cve_triage / cve_get_pocs).
evals/ holds a 10-question suite (cve-mcp-evals.xml, mcp-builder format) plus a
ground-truth checker that asserts each answer is still retrievable from the live
sources:
npm run verify:evalsSee evals/README.md for details. Answers are chosen to be stable
over time (CVSS/CWE, KEV dates, GHSA patched versions, classic Metasploit paths).
The CISA KEV catalog is cached in-process for one hour to avoid re-downloading the full feed on every call.
The Metasploit metadata (~11 MB) and Nuclei CVE index (~2 MB) feeds are fetched once and cached in-process for six hours, then indexed by CVE for instant lookups.
NVD caps date-range queries at 120 days; cve_recent clamps to that.
Responses are truncated at 25,000 characters; use pagination or json format for more.
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:
cve_ids (string[]): 1-25 CVE identifiers.
check_pocs (boolean, default false): Add public-PoC availability (one extra lookup per CVE).
check_tooling (boolean, default true): Add Metasploit/Nuclei tooling (cached feeds; cheap across a batch).
response_format ('markdown'|'json', default 'markdown').
Returns (json): { requested, triaged, not_found[], results[] } where each result is { cve_id, priority, score, signals, description } sorted by score descending.
Examples:
"Rank these scan findings by what to patch first" -> cve_ids=[...].
"Triage this list but skip the PoC lookups" -> check_pocs=false.
Errors:
Malformed IDs are rejected up front; unresolvable-but-valid IDs come back in not_found[].
| Name | Required | Description | Default |
|---|---|---|---|
| cve_ids | Yes | CVE identifiers to triage in one call (1-25), e.g. a scanner's findings list. | |
| check_pocs | No | Also factor public PoC availability into each verdict (one extra lookup per CVE; off by default to keep batch runs fast). | |
| check_tooling | No | Factor packaged exploit tooling (Metasploit/Nuclei) into each verdict (feeds are cached, so this is cheap across a batch). | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses meaningful behavior: EPSS is fetched once per batch, unknown IDs are returned separately instead of failing, malformed IDs are rejected up front, and results are sorted by priority. This gives an agent an accurate model of how the call behaves and fails.
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 well structured with Args, Returns, Examples, and Errors sections, and the core purpose is front-loaded in the first sentence. Every section adds useful information without unnecessary repetition or 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?
Despite lacking an output schema, the description defines the return shape, sorting behavior, error handling, and example invocations. Combined with safety annotations, this provides everything an agent needs to select and invoke the tool 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 coverage is 100%, so the schema already documents all parameters and defaults. The description mostly paraphrases the schema, though it adds useful context about lookup costs and cached tooling feeds; this is nice but not a substantial semantic addition.
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 action and resource: triage a list of CVEs in a single call and return them ranked by priority. It clearly differentiates from sibling tools by emphasizing batch behavior and explicitly invoking cve_triage as the per-CVE scoring equivalent.
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 makes the batch use case clear with examples like ranking scan findings and skipping PoC lookups, and contrasts with performing one tool call per CVE. It does not explicitly state when to prefer cve_triage for a single CVE, but the context strongly implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
repo (string): 'owner/repo' or a full github.com URL.
response_format ('markdown'|'json', default 'markdown').
Returns (json): { fullName, htmlUrl, files[], readme, readmeTruncated }.
Examples:
cve_fetch_poc_code(repo="kozmer/log4j-shell-poc").
cve_fetch_poc_code(repo="https://github.com/kozmer/log4j-shell-poc").
Errors:
"GitHub rate limit exceeded (429)" — set GITHUB_TOKEN.
"GitHub has no record for that identifier (404)" — repo not found or private.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub repo as 'owner/repo' or a full github.com URL (typically from cve_get_pocs). | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description discloses important runtime behavior: rate-limit errors and the GITHUB_TOKEN remedy, 404 behavior for missing/private repos, bounded README retrieval, and exact return fields. These are meaningful behavioral details an agent needs before invoking.
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 core behavior, then organized into Args, Returns, Examples, and Errors sections. Every section earns its place and there is no filler or repetition of annotation data.
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 two params, 100% schema coverage, and no output schema, the description fully compensates by documenting return fields, error cases, authentication guidance, and concrete examples. Nothing essential for correct invocation is missing.
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 coverage is 100%, so the baseline is 3, but the description adds practical meaning: repo can be 'owner/repo' or a full github.com URL, examples are given for both forms, and the response_format default and behavior are clarified. This goes beyond the schema's property 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?
The description explicitly states the action: fetching top-level file listing plus decoded README from a GitHub repository, which clearly distinguishes it from sibling tools like cve_get_pocs or cve_get_details. It names the exact resource and scope, and even mentions bounded README size.
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 explicitly says 'Use after cve_get_pocs to inspect a specific PoC,' giving clear sequencing against a sibling tool. It also adds intended-use context for authorized security research, though it does not enumerate exclusions for all other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve GitHub Security Advisories (GHSA) that reference a CVE — the best source for package-level impact (ecosystem, affected version ranges, first patched version).
Args:
cve_id (string): CVE identifier, e.g. "CVE-2021-44228".
response_format ('markdown'|'json', default 'markdown').
Returns (json): array of { ghsaId, summary, severity, cveId, htmlUrl, publishedAt, vulnerabilities: [ { ecosystem, packageName, vulnerableVersionRange, firstPatchedVersion } ] }.
Examples:
"Which npm/Maven packages does CVE-2021-44228 affect and when was it fixed?" -> cve_id="CVE-2021-44228".
Notes:
Returns an empty list when no advisory references the CVE. Set GITHUB_TOKEN to raise rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE identifier, e.g. 'CVE-2021-44228'. | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior, and the description adds genuine operational context: empty-list behavior when no advisory references the CVE, the GITHUB_TOKEN rate-limit dependency, and the markdown/json output contract. There is no contradiction with annotations; the only minor ambiguity is that Returns (json) is stated while markdown is the default format.
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 organized into purpose, args, returns, examples, and notes with the key purpose front-loaded. While the returns block is detailed, it earns its place because the tool has no output schema, and there is 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 two-parameter read-only tool with no output schema, the description provides the full return shape, empty-list behavior, rate-limit/auth note, and a working example. Nothing needed to call the tool correctly is missing.
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 coverage is 100%, so the schema documents both parameters. The description adds value by giving a concrete example question tied to cve_id and clarifying what the response_format choices mean operationally. This goes slightly beyond the baseline schema semantics.
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 and resource: Retrieve GitHub Security Advisories that reference a CVE. It also frames its differentiating value as the best source for package-level impact, so an agent can distinguish it from siblings like cve_get_details or cve_get_pocs.
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 opening line and example question clearly signal when to use this tool: when package-level impact (ecosystem, versions, first patched version) is needed. It does not explicitly name alternative tools or give when-not-to-use conditions, but the context is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
cve_id (string): CVE identifier, e.g. "CVE-2021-44228".
include_kev (boolean): Add CISA KEV status (default: true).
include_epss (boolean): Add EPSS score (default: true).
response_format ('markdown' | 'json'): Output format (default: 'markdown').
Returns (json): { id, published, lastModified, vulnStatus, descriptions, cvss[], cwes[], references[], cpe[], kev, epss }.
Examples:
"Tell me everything about Log4Shell" -> cve_id="CVE-2021-44228".
"Is CVE-2023-23397 being exploited?" -> include_kev=true, include_epss=true.
Errors:
"Invalid CVE ID ..." if the ID is malformed.
"No NVD record found for " if the CVE does not exist in NVD.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE identifier, e.g. 'CVE-2021-44228'. | |
| include_kev | No | Enrich with CISA KEV (actively-exploited) status. | |
| include_epss | No | Enrich with the EPSS exploitation-probability score. | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag read-only/idempotent behavior, and the description adds real behavioral detail: NVD as source, optional KEV/EPSS enrichment defaulting to true, two output formats, the full JSON return shape, and expected error strings. It doesn't mention rate limits or auth, but those are not essential given the annotations.
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 structured into purpose, args, returns, examples, and errors, with the purpose front-loaded. It is slightly redundant with the input schema in the Args block, but the return shape and error strings are valuable and not otherwise present.
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 single-record lookup with four parameters and no output schema, this is complete: it defines the required identifier, optional enrichment flags, output format, default behavior, return fields, and failure modes. An agent can call it correctly without additional context.
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 coverage is 100%, so the schema already fully documents all four parameters and defaults. The description restates these in Args and adds illustrative query mappings, but no new parameter-level semantics or constraints beyond what the schema provides.
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?
Opens with 'Retrieve complete, authoritative details for a single CVE from the NIST NVD' – a specific verb, resource, and single-record scope. The combination list (NVD description, CVSS, CWE, CPE, references, KEV, EPSS) clearly differentiates it from focused sibling tools like cve_get_kev or cve_get_pocs.
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 single-CVE scope and examples ('Tell me everything about Log4Shell' -> cve_id; 'Is CVE-2023-23397 being exploited?' -> include flags) make intended use concrete. It does not explicitly name alternatives or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
cve_ids (string[]): 1-100 CVE identifiers.
response_format ('markdown'|'json', default 'markdown').
Returns (json): { count, scores: [ { cve, epss, percentile, date } ] } (epss/percentile as fractions 0-1).
Examples:
"EPSS for CVE-2021-44228" -> cve_ids=["CVE-2021-44228"].
"Rank these three by exploitation likelihood" -> cve_ids=[...].
| Name | Required | Description | Default |
|---|---|---|---|
| cve_ids | Yes | One or more CVE IDs to score (1-100). | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/openWorld/idempotent/destructive behavior. The description adds useful behavioral context: the 30-day exploitation window, percentile ranking, date field, and return values expressed as fractions 0-1. No contradiction with annotations.
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 well-structured with purpose, background, args, return shape, and examples. It is slightly longer than strictly necessary because it duplicates schema details, but it is front-loaded and every section serves a clear purpose.
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 two-parameter read-only tool with no output schema, the description adequately explains the return structure and includes usage examples. It does not cover error behavior or handling of invalid/unknown CVE IDs, which is a minor gap but not blocking.
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 coverage is 100%, and both parameters are already well described in the schema. The description repeats the parameter definitions and adds helpful examples, but it does not add substantial semantic meaning beyond what the schema provides.
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 a specific action: retrieve EPSS scores for one or more CVEs, and explains what EPSS is (exploitation probability and percentile). It does not explicitly contrast itself with sibling tools like cve_get_kev or cve_get_details, so it stops short of full sibling differentiation.
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 gives clear when-to-use context: 'useful for prioritizing patching beyond raw CVSS severity.' It does not name alternatives or state when not to use the tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (use <module>), and a Nuclei template gives repeatable, at-scale detection (nuclei -id <cve> -u <target>). Each module/template comes with its reliability/severity, disclosure date, msfconsole/nuclei run string, and GitHub source link.
Intended for authorized penetration testing, detection engineering, and vulnerability triage.
Args:
cve_id (string): CVE identifier, e.g. "CVE-2021-44228".
response_format ('markdown'|'json', default 'markdown').
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:
"Is there a Metasploit module for Log4Shell?" -> cve_id="CVE-2021-44228".
"Can I scan for CVE-2024-3400 with Nuclei?" -> cve_id="CVE-2024-3400".
Notes:
Returns empty lists (not an error) when no packaged tooling references the CVE.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE identifier, e.g. 'CVE-2021-44228'. | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds valuable behavioral context: it returns empty lists rather than errors when no tooling exists, explains the Metasploit rank scale, and distinguishes weaponized 'exploit' modules from 'auxiliary' scanner/check modules. No contradiction with annotations.
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 core purpose and then organized into labeled sections: Args, Returns, rank explanation, Examples, and Notes. Every section contributes selection or invocation guidance, with 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?
With no output schema present, the description fully compensates by defining the JSON return shape for metasploit and nuclei entries, explaining rank values and exploit type semantics, and noting empty-list behavior. The examples and intended-use note make the tool self-contained for an agent.
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 coverage is 100% for both parameters, so the baseline bar is lower; the description still adds useful examples mapping natural-language requests to cve_id and clarifies response_format values. It mostly repeats the schema, hence 4 rather than 5.
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 opens with a specific verb and resource: 'Find packaged, ready-to-run exploit and scan tooling for a CVE: Metasploit Framework modules ... and Nuclei templates.' It clearly separates itself from cve_get_pocs by stating it returns tooling rather than raw proof-of-concept repos, so an agent can select it with confidence.
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 explicitly names the sibling alternative cve_get_pocs and draws the when-not boundary: 'This is distinct from cve_get_pocs (raw proof-of-concept repos).' It also states intended use cases ('authorized penetration testing, detection engineering, and vulnerability triage') and gives natural-language examples, leaving little ambiguity about when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the CISA Known Exploited Vulnerabilities (KEV) catalog — the authoritative list of CVEs confirmed to be actively exploited in the wild.
Two modes:
Single lookup: pass cve_id to check whether a specific CVE is KEV-listed (with remediation due date and ransomware-use flag).
Catalog list: omit cve_id to browse the catalog, newest additions first, with optional vendor / ransomware filters.
Args:
cve_id (string, optional): Single-CVE lookup.
vendor (string, optional): Vendor/product substring filter (list mode).
ransomware_only (boolean, default false): Only known-ransomware entries (list mode).
limit (1-100, default 25), offset (default 0): Pagination (list mode).
response_format ('markdown'|'json', default 'markdown').
Returns (single): a KEV entry object, or a "not listed" message. Returns (list, json): { catalogVersion, dateReleased, total, count, startIndex, entries[] }.
Examples:
"Is CVE-2024-3400 known-exploited?" -> cve_id="CVE-2024-3400".
"Recent ransomware-linked KEV entries" -> ransomware_only=true.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page when listing (1-100). | |
| cve_id | No | Look up a single CVE's KEV entry. Omit to list the catalog. | |
| offset | No | Pagination offset when listing. | |
| vendor | No | Filter the catalog by vendor or product substring. | |
| ransomware_only | No | List only entries with known ransomware-campaign use. | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: newest-first ordering, the 'not listed' message for single lookup, the exact JSON list structure, and the response_format switch. No contradictions.
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 well organized with a purpose statement first, then modes, args, returns, and examples. It is longer than minimal but every section serves a purpose for a 6-parameter tool with two modes. No fluff.
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?
Without an output schema, the description fully specifies return shapes for both single and list modes, including the JSON structure. Examples clarify exact invocations. An agent has all necessary information to call the tool 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 coverage is 100% and each parameter already has a clear description. The description re-lists all args and adds mode-scoping context (e.g., list mode for vendor and ransomware_only), but this is largely redundant with the schema. It meets the baseline without adding substantial new meaning.
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 exactly what the tool does: queries the CISA Known Exploited Vulnerabilities catalog, the authoritative list of actively exploited CVEs. It clearly describes two modes (single lookup vs catalog list), distinguishing this tool from siblings like cve_search and cve_get_details.
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?
Explicit guidance is given for mode selection: pass cve_id for single lookup, omit it to browse the catalog. Concrete examples map natural-language queries to parameter settings. It does not name sibling tools or state when not to use it, but the mode differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
cve_id (string): CVE identifier, e.g. "CVE-2021-44228".
include_nvd_exploits (boolean): Include NVD exploit references (default: true).
max_results (1-100, default 30): Cap on references returned.
response_format ('markdown'|'json', default 'markdown').
Returns (json): { cve_id, count, pocs: [ { source, name, url, description, stars, createdAt, updatedAt } ] }.
Examples:
"Find PoCs for Log4Shell" -> cve_id="CVE-2021-44228".
"Any exploits for CVE-2024-3400?" -> include_nvd_exploits=true.
Notes:
Returns an empty list (not an error) when no public PoCs are indexed.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE identifier, e.g. 'CVE-2021-44228'. | |
| max_results | No | Maximum PoC references to return (1-100). | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
| include_nvd_exploits | No | Also include Exploit-DB / exploit-tagged references from the NVD record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already include readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds substantial behavioral context: it aggregates two indexes, ranks GitHub repos by stars, returns only links and metadata, and notes that an empty list (not an error) is returned when no PoCs exist. This clarifies the operational behavior well beyond the annotations.
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 long but every section earns its place: purpose, data sources, sibling differentiation, intended use, args, return shape, examples, and an edge-case note. It is well-structured with clear labels and front-loads the core purpose before diving into details. No redundant filler or repetition.
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 description is complete for an agent to correctly call this tool: it defines all parameters, gives the JSON return shape, explains the empty-list edge case, provides examples, and clarifies why it differs from cve_fetch_poc_code. Given the rich annotations and full schema coverage, nothing necessary for correct invocation is missing.
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%, which already documents all four parameters thoroughly. The description adds value with concrete natural-language examples mapping user requests to parameters, such as 'Find PoCs for Log4Shell' -> cve_id='CVE-2021-44228'. This helps the agent infer parameter values from user intent, but otherwise the parameter semantics are already well covered by 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 opens with a specific verb and resource: 'Discover public proof-of-concept (PoC) and exploit references for a CVE.' It goes beyond a simple restatement by naming the exact data sources (nomi-sec PoC-in-GitHub, NVD exploit references) and clearly distinguishes itself from cve_fetch_poc_code by noting it 'returns links and metadata only.' This makes the tool's scope unmistakable even before inspecting the schema.
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 explicitly tells the agent when to use a sibling instead: 'use cve_fetch_poc_code to retrieve a specific repo's contents.' It also frames the intended context ('authorized defensive testing, detection engineering, and vulnerability triage'), giving the agent clear guidance on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List CVEs published within a recent look-back window — for real-time monitoring of newly disclosed vulnerabilities.
Args:
days (1-120, default 7): How far back to look (NVD caps ranges at 120 days).
severity ('LOW'|'MEDIUM'|'HIGH'|'CRITICAL'): Optional severity filter.
kev_only (boolean, default false): Only CVEs in the CISA KEV catalog.
limit (1-50, default 20), offset (default 0): Pagination.
response_format ('markdown'|'json', default 'markdown').
Returns (json): { total, count, offset, has_more, next_offset, results[] }, newest first by publish date.
Examples:
"What critical CVEs dropped this week?" -> days=7, severity="CRITICAL".
"New known-exploited vulns in the last month" -> days=30, kev_only=true.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (1-120; NVD caps ranges at 120 days). | |
| limit | No | Results per page (1-50). | |
| offset | No | Pagination offset. | |
| kev_only | No | Return only recently-modified CVEs in the CISA KEV catalog. | |
| severity | No | Filter by CVSS v3 base severity. | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful runtime context beyond those annotations: results are newest first by publish date, NVD caps look-back at 120 days, and the JSON response shape includes pagination fields like total, has_more, and next_offset. This gives an agent clear expectations without overstating 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 well-structured with a front-loaded purpose statement, a compact Args list, return info, and examples. It includes some redundancy with the schema, but the repetition is acceptable because it makes the definition self-contained. Every section earns its place, and there is no filler or vague prose.
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 tool with six optional parameters and no output schema, the description is quite complete: it documents return fields, ordering, pagination, example queries, and KEV filtering. The only notable gap is the absence of explicit sibling guidance, especially the relationship to cve_get_kev and cve_search, which would make tool selection even more robust. Overall, an agent has enough information to call this tool 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 coverage is 100%, so the schema already documents all six parameters; the baseline is therefore 3. The description adds value by restating the parameters in a compact action-oriented list and, more importantly, providing example mappings from user intent to parameter values, such as 'critical CVEs this week' -> days=7, severity='CRITICAL'. It does not introduce new syntax but does help an agent translate requests into parameters.
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 opens with a specific verb and resource: 'List CVEs published within a recent look-back window.' This clearly distinguishes the tool from detail, search, and exploit-related siblings by emphasizing the time-bounded, monitoring-oriented scope. The phrase 'real-time monitoring of newly disclosed vulnerabilities' makes the intended purpose immediately recognizable.
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?
It provides an explicit use case: real-time monitoring of newly disclosed vulnerabilities, and it gives two natural-language example queries with mapped parameter settings. However, it does not explicitly say when NOT to use this tool versus siblings like cve_search or cve_get_kev, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the NIST NVD for CVEs by keyword, affected product (CPE), severity, KEV status, and publication date range.
Args:
keyword (string): Terms matched against CVE descriptions.
cpe_name (string): CPE 2.3 string to match affected products.
severity ('LOW'|'MEDIUM'|'HIGH'|'CRITICAL'): CVSS v3 severity filter.
kev_only (boolean): Restrict to CISA KEV entries (default: false).
published_after / published_before (ISO-8601): Publication date window (max 120-day span).
limit (1-50, default 20), offset (default 0): Pagination.
response_format ('markdown'|'json', default 'markdown').
Returns (json): { total, count, offset, has_more, next_offset, results[] } where each result is a full CVE detail object.
Examples:
"Critical Apache Struts RCEs" -> keyword="apache struts", severity="CRITICAL".
"Known-exploited Fortinet bugs" -> keyword="fortinet", kev_only=true.
Errors:
"NVD rejected the request (400)" if a date span exceeds 120 days or a filter is invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-50). | |
| offset | No | Pagination offset. | |
| keyword | No | Keyword(s) matched against CVE descriptions, e.g. 'apache struts rce'. | |
| cpe_name | No | CPE 2.3 name to match affected products, e.g. 'cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*'. | |
| kev_only | No | Return only CVEs present in the CISA KEV catalog. | |
| severity | No | Filter by CVSS v3 base severity. | |
| published_after | No | ISO-8601 date; only CVEs published on/after this (max 120-day span with published_before). | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
| published_before | No | ISO-8601 date; only CVEs published on/before this. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavior beyond that: it documents the paginated response shape, the markdown/json default, the 120-day span constraint, and the exact error message for invalid requests.
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 well structured with clear sections: summary, args, returns, examples, and errors. It is appropriately detailed for a 9-parameter search tool, though the Args block partially duplicates schema content rather than strictly adding new 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?
With no output schema present, the description compensates by specifying the exact JSON return shape, pagination fields, result semantics, examples, and error conditions. Combined with the read-only/idempotent annotations, an agent has what it needs to invoke and interpret this tool 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 100%, so the schema already explains every parameter accurately. The description largely restates those facts, though the natural-language examples, CPE 2.3 example, and default-format note add minor practical 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 opening line uses a specific verb and resource: 'Search the NIST NVD for CVEs' by keyword, CPE, severity, KEV status, and publication date. This clearly differentiates it as a general filtered search tool from siblings like cve_get_details or cve_get_kev, which target specific data retrieval.
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 gives clear search context and concrete examples, such as mapping 'Critical Apache Struts RCEs' to keyword+severity and 'Known-exploited Fortinet bugs' to kev_only=true. It does not explicitly say when to prefer sibling tools like cve_recent or cve_get_details, so it stops short of full alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
cve_id (string): CVE identifier, e.g. "CVE-2021-44228".
check_pocs (boolean): Include PoC availability (default: true; one extra lookup).
check_tooling (boolean): Include Metasploit/Nuclei tooling (default: true; one extra lookup).
response_format ('markdown'|'json', default 'markdown').
Returns (json): { cve_id, priority, score, rationale[], signals{ cvssScore, cvssSeverity, epss, epssPercentile, kevListed, kevRansomware, kevDueDate, pocCount, msfModuleCount, nucleiTemplateCount, weaponized }, tooling{ metasploit, nuclei }, description }.
Examples:
"Should we patch CVE-2024-3400 this weekend?" -> cve_id="CVE-2024-3400".
"Triage this from the scan, skip the PoC check" -> check_pocs=false.
Errors:
"No NVD record found for " if the CVE is unknown/unpublished.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE identifier, e.g. 'CVE-2021-44228'. | |
| check_pocs | No | Factor public PoC availability into the verdict (one extra lookup). | |
| check_tooling | No | Factor packaged exploit tooling (Metasploit modules / Nuclei templates) into the verdict. | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite already having readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral detail: exact priority thresholds, the 50/40/15 scoring weights, KEV pinning behavior, conditional extra lookups, the structured return shape, and the expected error message. This gives an agent an unusually complete picture of runtime 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?
The description is long but every section earns its place: decision question, priority levels, scoring formula, arguments, return shape, examples, and errors. It is front-loaded with the core purpose and carefully structured with labels, making complex scoring logic easy for an agent to parse.
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?
Even though there is no output schema, the description explicitly enumerates the JSON return fields, signal sub-object, tooling sub-object, and error string. Given the tool's algorithmic complexity, the description is sufficiently complete for an agent to select and invoke it correctly without guessing.
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 covers all 4 parameters at 100%, so the schema carries the baseline burden. The description adds useful practical value beyond the schema, such as the 'one extra lookup' cost for check_pocs, the default behavior for check_tooling, and a concrete example of using check_pocs=false. That is enough to rise above baseline 3.
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 and resource: 'Produce a single prioritization verdict for a CVE' by fusing exploitation signals. It also differentiates itself from siblings by presenting the tool as the fused judgment call an analyst would otherwise make across four signals, which clearly separates it from cve_get_details, cve_get_epss, cve_get_kev, and similar getter tools.
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 explicitly frames when to use the tool: it answers 'should I drop everything for this, or can it wait?' and gives relatable examples with cve_id. It does not explicitly state exclusions or route the agent to cve_batch_triage for multi-CVE workflows, so it stops short of perfect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
vendor (string): Vendor/product to watch, e.g. "fortinet", "apache struts". Matched against NVD descriptions and KEV vendor/product fields.
days (1-120, default 30): Look-back window for newly published CVEs.
severity ('LOW'|'MEDIUM'|'HIGH'|'CRITICAL'): Optional minimum severity for the recent list.
include_kev (boolean, default true): Also list this vendor's KEV entries (newest first; items added within the window are flagged 🆕).
limit (1-50, default 25): Max recently-published CVEs.
response_format ('markdown'|'json', default 'markdown').
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:
"What's new for Fortinet this month, and what's actively exploited?" -> vendor="fortinet".
"Critical Ivanti CVEs in the last two weeks" -> vendor="ivanti", days=14, severity="CRITICAL".
Errors:
"NVD rejected the request (400)" if filters are invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days for newly published CVEs (1-120; NVD caps ranges at 120). | |
| limit | No | Max recently-published CVEs to return (1-50). | |
| vendor | Yes | Vendor or product to watch, e.g. 'fortinet', 'apache struts', 'cisco ios'. Matched against NVD descriptions and the CISA KEV vendor/product fields. | |
| severity | No | Only include recently-published CVEs at/above this CVSS v3 severity. | |
| include_kev | No | Also surface this vendor's CISA KEV (actively-exploited) entries, newest first. | |
| response_format | No | Output format: 'markdown' (default, human-readable) or 'json' (full structured data). | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation is read-only, open-world, idempotent, and non-destructive. The description goes further by explaining the fusion behavior, the matching mechanism against NVD descriptions and KEV fields, the return JSON structure, the 🆕 flag semantics for in-window KEV entries, and the NVD 400 error case. This adds meaningful behavioral context beyond annotations.
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 well-structured with clear sections: a one-sentence purpose, an alternatives note, Args, Returns, Examples, and Errors. Every section contributes to correct invocation, and the key differentiator is front-loaded. It is detailed without being 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?
For a tool with 6 parameters and no output schema, the description covers the return structure, parameter semantics, error behavior, and usage examples. It also states the NVD 120-day cap and the default values. Nothing essential for selecting or invoking the tool is missing.
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 coverage is 100%, so the schema already documents all parameters. The description adds value by clarifying that severity is a minimum threshold, showing realistic examples tied to parameter values, and noting that KEV entries added within the window are flagged. This goes slightly beyond a bare schema repeat.
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 opens with a specific verb and resource: '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.' It clearly distinguishes itself from siblings by naming cve_recent, cve_search, and cve_get_kev as the alternatives it replaces.
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 explicitly states when to use this tool: to answer 'what's new and what's on fire for <vendor> right now?' and to avoid running cve_recent, cve_search, and cve_get_kev separately. It also provides concrete examples ('Critical Ivanti CVEs in the last two weeks' maps to vendor='ivanti', days=14, severity='CRITICAL'), giving the agent clear decision guidance.
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.
v1.0.0cve_batch_triagecve_fetch_poc_codecve_get_advisoriescve_get_detailscve_get_epsscve_get_exploit_toolingcve_get_kevcve_get_pocscve_recentcve_searchcve_triagecve_watchlistScored 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.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
CVE intelligence: exploitation (KEV/EPSS), detection coverage, fixed versions. All tools keyless.
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
