cvescout

Overview Schema Source Related Servers Discussions Admin

search_recent_cves

Read-only

Search CVEs published within a recent window or since a date, enriched with EPSS exploit probability, CISA KEV status and risk scores to prioritize patching.

Instructions

Search for CVEs published in the last N days (or since a date), enriched with EPSS exploit probability, CISA KEV membership and a risk score (patch priority).

Args: sort_by: "published" (newest first) or "risk" (highest patch priority first, ranked over all matches). Use "risk" for "what should I patch first", "most dangerous", "top N". reference_urls: Only with source="cvelist": match parts of reference links, OR-ed with keywords/cpes. A product's security advisory page finds CVEs filed under libraries it bundles, e.g. ["nodejs.org/en/blog/vulnerability"] finds a Brotli or OpenSSL CVE that Node.js lists. Use it together with keywords for a product. source: "nvd" (default; NVD API, any date range, CPE filters cover NVD-analyzed CVEs) or "cvelist" (CVEProject CVE List: last 30 days only, no rate limit, CVEs appear about an hour before NVD, includes vendor-supplied affected versions; keywords also match vendor and product names; CPE filters only match where the vendor supplied CPEs). Use "cvelist" for the last hours or days, or when NVD is unavailable or slow. days: Look-back window in days. Use small windows (1-7) for "latest". Ignored when since is set. keywords: Optional free-text filters, OR-ed (one search each), e.g. ["openssl"] or ["node.js", "curl"]. Matches anywhere in the description, so it is broad. since: Optional start date YYYY-MM-DD for historical questions ("since 2020"). Ranges over 120 days require keywords or cpes. cpes: Optional exact products as CPE names, OR-ed: "vendor:product" for applications, "o:vendor:product" for operating systems, e.g. ["nodejs:node.js", "haxx:curl", "o:linux:linux_kernel"]. Use find_cpe_name if unsure. More precise than keywords but only covers CVEs NVD has already analyzed. min_severity: Optional minimum CVSS severity. limit: Maximum number of CVEs to return (1-100). min_score: Optional minimum CVSS base score (0-10), e.g. 8. rce_only: Only remote code execution (code/command injection reachable over the network; heuristic on CWE, description and CVSS vector). match_any: If true, keep items meeting ANY of min_severity/min_score/rce_only/poc_only instead of ALL of them. poc_only: Only items with a public exploit: a PoC repository on GitHub (listed in github_pocs, from nomi-sec/PoC-in-GitHub), a CISA SSVC or CVSS v4 rating of a public PoC (ignored when the CVE links a bug bounty report such as HackerOne), or exploitation in the wild (CISA KEV). A reference NVD tagged "Exploit" alone does not count.

Input Schema

Name	Required	Default
`cpes`	No
`days`	No
`limit`	No
`since`	No
`source`	No	nvd
`sort_by`	No	published
`keywords`	No
`poc_only`	No
`rce_only`	No
`match_any`	No
`min_score`	No
`min_severity`	No
`reference_urls`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Oct 26, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond readOnlyHint/openWorldHint: it discloses that cvelist has no rate limit and publishes about an hour ahead of NVD, that NVD CPE filters only cover analyzed CVEs, that ranges over 120 days require keywords or cpes, and that keywords match anywhere so they are broad. The poc_only caveats (what does and does not count as a public exploit, HackerOne exclusion) are exactly the kind of behavioral detail annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The length is justified by 13 undocumented parameters and the prose is front-loaded with purpose before the parameter notes. It is dense docstring-style rather than scannable, with some long parenthetical clauses (the reference_urls Node.js example, the poc_only definition), but very little is genuinely wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete on the hard parts: multi-source behavior, date-window constraints, filter interaction, and enrichment contents, with an output schema covering return values. Minor gaps remain: nothing about whether results are truncated or how to page past limit, and no guidance on the overlap with get_recent_exploited.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 13 parameters, so the description carries the full burden and does so: nearly every parameter gets meaning, format examples, OR vs AND interaction (keywords/cpes are OR-ed, match_any flips filter combination) and precedence rules. Only limit (1-100) lacks added nuance beyond its bounds.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb (search), a specific resource (CVEs), a scope (last N days or since a date) and the enrichment payload (EPSS, CISA KEV, risk score / patch priority). That is enough for an agent to tell it apart from get_cve_details (single-CVE lookup) and search_github_advisories (advisories, not CVEs) without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong in-tool routing: sort_by="risk" is tied to concrete intents ("what should I patch first", "most dangerous", "top N"), days 1-7 is prescribed for "latest", source="cvelist" is prescribed for "last hours or days, or when NVD is unavailable or slow", and find_cpe_name is named for uncertain CPEs. It also states exclusions (reference_urls only with source="cvelist", days ignored when since is set). What is missing is routing against siblings such as get_recent_exploited, which overlaps with poc_only=true.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server