webdata-tools-mcp

Search CVE vulnerabilities (NVD, CISA KEV, EPSS)

search_vulnerabilities

Read-onlyIdempotent

Search new and updated CVEs with CVSS, CWE, affected vendors/products, CISA KEV and EPSS data to support patch triage and security alerts; filter by vendor, severity, or CVE ID.

Instructions

New and updated vulnerabilities from the NVD with CVSS score and severity, CWE, affected vendors and products, references, CISA known-exploited status (date added, due date, ransomware use) and the EPSS exploit likelihood. Filter by vendor, product, keyword, severity, CVSS or EPSS, or look up CVE ids. Use for patch triage and security alerts. Runs the Apify Actor tacps126/cve-feed on your Apify account (about $0.003 per CVE; spend per call is capped at $0.5).

Input Schema

Name	Required	Description	Default
`source`	No	nvd: CVEs published or modified in the window; kev: CVEs CISA added to its known-exploited catalog.	nvd
`cve_ids`	No	Look up these CVEs instead, e.g. ["CVE-2024-3400"].
`vendors`	No	Affected vendors, e.g. ["microsoft", "cisco"].
`keywords`	No	Words in the description, e.g. "remote code execution".
`min_cvss`	No	Minimum CVSS base score.
`min_epss`	No	Minimum probability of exploitation in the next 30 days (0-1).
`products`	No	Affected products, e.g. ["exchange server"].
`max_items`	No	Maximum results to return (default 100, max 2000). Cost scales with this.
`severities`	No	Empty = all.
`extra_input`	No	Advanced: extra Actor input fields, merged over the defaults.
`within_days`	No	Look-back window in days (about 600-900 CVEs a day on NVD).
`known_exploited_only`	No	Only CVEs in the CISA known-exploited catalog.

Output Schema

Name	Required	Description
`tool`	Yes	Name of the tool that produced the result.
`count`	Yes	Number of records the Actor returned.
`items`	Yes	The records. Long text fields are shortened to 600 characters.
`shown`	Yes	Number of records included in `items` (can be lower than count when the result is long).
`truncated`	Yes	True when records were left out to keep the result short; ask for fewer items.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.16.0Nov 3, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds information the annotations cannot: the tool runs the Apify Actor tacps126/cve-feed on the caller's own Apify account, costs roughly $0.003 per CVE, and enforces a $0.5 spend cap per call. Those cost/account details are exactly the behavioral context an agent needs before choosing a result limit.

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?

Four sentences ordered sensibly: what it returns, how to filter, when to use it, then cost/execution model. No filler, though the returned-field enumeration and the filter list overlap slightly and could be tightened.

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?

With an output schema present and all 12 parameters documented, the description only needs to cover purpose, usage and cost — all of which it does. Minor gaps remain: nothing about result ordering or how the default two-day window behaves, though the schema hints at daily volume.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented with examples, ranges and defaults, and the description largely restates the filter axes (vendor, product, keyword, severity, CVSS, EPSS, CVE ids). It adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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?

Opens with a specific verb and resource ('New and updated vulnerabilities from the NVD') and enumerates the payload dimensions returned: CVSS/severity, CWE, vendors/products, references, CISA KEV status and EPSS. The title and first sentence together make clear this is a CVE search/retrieval tool, and no sibling tool in the list covers vulnerability data, so there is no ambiguity to resolve.

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?

States a concrete use case ('Use for patch triage and security alerts') and enumerates the filter axes, including the CVE-id lookup path. It stops short of explicit when-not-to-use guidance or naming alternatives (e.g. when to prefer the kev source vs nvd), but with no competing sibling the routing risk is low.

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

Deploy Server