overflo.ws

search_cves

Read-onlyIdempotent

Search public CVEs by text, risk signals and affected products. Vendor/product must be NVD CPE names; call find_product first. KEV is the strongest priority signal, then EPSS, then CVSS. A capped total is a lower bound. howExploited names the weakness (MITRE's CWE name) and, when it isn't the network, where an attacker has to be; it isn't evidence of exploitation.

Input Schema

Name	Required	Description
`q`	No	Web-style full-text search (quoted phrases, OR, exclusions), or an exact CVE ID.
`cwe`	No	Weakness ID, e.g. CWE-79 or 79.
`kev`	No	true: known-exploited only; false: exclude KEV; omitted: either.
`page`	No	Page number, starting at 1; capped at the API's maximum offset.
`sort`	No	Descending order: published (default), modified, cvss, epss or kev.
`since`	No	Inclusive publication lower bound, ISO 8601 date/timestamp; dates use UTC midnight.
`until`	No	Inclusive publication upper bound, ISO 8601 date/timestamp; dates use UTC midnight.
`vendor`	No	Vendor CPE name, e.g. microsoft; call find_product first.
`product`	No	Product CPE name, e.g. windows_server_2022; requires vendor. Call find_product first.
`min_cvss`	No	Minimum CVSS score, 0 to 10.
`min_epss`	No	Minimum EPSS probability, 0 to 1 (0.1 means 10%).
`severity`	No	Comma list: CRITICAL,HIGH,MEDIUM,LOW.
`page_size`	No	Results per page, default 10; clamped to 1–50.
`ransomware`	No	true: CISA ransomware-linked only; false/omitted: no ransomware filter.

Output Schema

Name	Required	Description	Default
`link`	Yes
`page`	Yes
`items`	Yes
`total`	Yes
`pageSize`	Yes
`totalCapped`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

addedOutput schema / properties / items / items / properties / howExploited
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

changedOutput schema / properties / items / items / required

Previous value: -[
-  "id",
-  "published",
-  "severity",
-  "cvssScore",
-  "epss",
-  "epssPercentile",
-  "kev",
-  "kevDateAdded",
-  "ransomware",
-  "description",
-  "products",
-  "productCount",
-  "link"
-]New value: +[
+  "id",
+  "published",
+  "kev",
+  "ransomware",
+  "description",
+  "products",
+  "productCount",
+  "link"
+]

First observedOct 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish that this is a read-only, idempotent, non-destructive, open-world search. The description adds useful behavior context beyond annotations: capped totals are lower bounds, and howExploited describes weakness/location rather than evidence of exploitation. It does not cover auth or rate limits, but adds enough relevant operational detail.

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 description is front-loaded and compact: purpose first, then prerequisite, priority ordering, and an output-field caveat. Every sentence contributes, though the final howExploited sentence is slightly dense and references output semantics that the output schema also covers.

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?

Given 14 optional parameters, full schema coverage, rich annotations, and an output schema, the definition provides the key additional context an agent needs: CPE prerequisite handling, risk-signal priority, capped-total meaning, and howExploited interpretation. The main remaining gap is sibling routing against get_cve and cve_highlights.

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

Parameters4/5

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 14 parameters and the baseline is 3. The description adds meaningful semantics beyond the schema by ranking KEV above EPSS above CVSS and by tying vendor/product inputs to CPE names and the find_product prerequisite.

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

Purpose4/5

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

The first sentence clearly states the verb and resource: search public CVEs by text, risk signals, and affected products. It is easy to distinguish from a detail-fetching tool like get_cve, but it does not explicitly contrast with siblings such as cve_highlights or get_cve.

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

Usage Guidelines3/5

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

It gives one explicit prerequisite: vendor/product must be NVD CPE names, so call find_product first. It also ranks KEV, EPSS, and CVSS as priority signals, but it does not state when to use this tool instead of get_cve or cve_highlights, nor when not to use it.

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

All overflo.ws tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?