Skip to main content
Glama

CVE Search

cve_search
Read-onlyIdempotent

Search CVE database with filters: product/vendor, severity, published date range, EPSS score, CWE, CVSS range, CISA KEV status. Default response is SLIM per-result (cve_id, summary, severity, cvss_v3, cwe_id, epss, kev, total_products, published, modified, sources) — pass include='full' for description, cvss_breakdown, affected_products, references, first_seen_*. Verdict (sources_queried, falsifiable_fields, completeness, data_age) is at the response root — applies to the whole batch, not per-row. Product/vendor filters are EXACT NVD-canonical-token matches (not the common name — e.g. nginx is 'nginx_open_source'/'nginx_plus', vendor 'f5'); a low/zero count for a well-known product means the token differs, so for dependency/package lists use check_dependencies and for a domain's whole stack tech_stack_cve_audit (both auto-normalize tokens). Use for vulnerability discovery by criteria; pass cwe_id (e.g. CWE-79) to enumerate every CVE in our database mapped to a weakness — pair with cwe_lookup for the category description and mitigations. Use cve_lookup for single CVE by ID, kev_detail when kev=true filtering and the agent needs federal patch deadlines per result. Response carries a global hint pointing at cve_lookup — drill into any returned cve_id for full detail and chained pivots (exploit_lookup, kev_detail, cwe_lookup). Free: 30/hr, Pro: 500/hr. Returns {count, total, truncated, offset, summary, results, query_echo, next_offset, verdict, hint}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kevNoIf true, return only CVEs in the CISA Known Exploited Vulnerabilities (KEV) catalog — these are actively exploited in the wild.
sortNoSort order for results. Must be one of: published_desc (newest first), epss_desc (most exploitable first), cvss_desc (most severe first). Omit for newest first (default=published_desc).
limitNoMaximum results to return. Range: 1-200.
cwe_idNoFilter by CWE weakness ID. Exact match, case-insensitive. Common values: CWE-79 (XSS), CWE-89 (SQL injection), CWE-120 (buffer overflow), CWE-78 (command injection). Format: CWE-<number>. Omit to not filter by CWE.
offsetNoSkip N results for pagination. Use with limit to page through results.
vendorNoFilter by vendor name (case-insensitive). When combined with product, both must match the same CPE row — prevents cross-row false matches. Example: vendor=apache, product=struts.
includeNoPer-result detail level. Default (omit) returns slim list items (cve_id, summary, severity, cvss_v3, cwe_id, epss, kev, total_products, published, modified, sources). Pass 'full' to also return description, cvss_breakdown, affected_products, references, first_seen_source, first_seen_at — only do this when the user explicitly wants drill-down on every result. Even with 'full', per-result affected_products and references may be truncated (the per-result total_products/total_references report the honest counts); use cve_lookup for the guaranteed-complete per-CVE lists. For single-CVE detail prefer cve_lookup; slim default keeps token cost ~70% lower on Log4j-class queries. Note: verdict is at the response root, not per-row (was deduplicated to save ~40% payload).
productNoProduct or vendor token to filter by. EXACT match (case-insensitive) against the NVD-canonical CPE product/vendor token — NOT substring/fuzzy, and NOT necessarily the common project name. Common names, vendor renames, and build-tool artifact ids often differ from the canonical token (e.g. modern nginx CVEs are under 'nginx_open_source'/'nginx_plus', vendor 'f5', not 'nginx'; Maven 'log4j-core' maps to 'log4j'). A low or zero count for a well-known product usually means the token differs — do NOT assume coverage is complete. For dependency/package lists prefer check_dependencies, and for a domain's whole tech stack tech_stack_cve_audit (both auto-normalize tokens). A product match means CVEs exist for that product, not that a specific running version is affected — verify the running version is within each CVE's affected range. Omit to search all products.
cvss_maxNoMaximum CVSS v3 base score (0.0-10.0). Default 10.0 = no filter (sentinel, not applied). Set < 10.0 to filter — CVEs with null CVSS are excluded when active. Combine with cvss_min for a range.
cvss_minNoMinimum CVSS v3 base score (0.0-10.0). Default 0.0 = no filter (sentinel, not applied). Set > 0 to filter — CVEs with null CVSS are excluded when active. Use 7.0 for high+critical, 9.0 for critical only.
epss_minNoMinimum EPSS score filter (0.0-1.0). EPSS predicts exploitation probability. 0.5 = top ~5% most likely to be exploited. 0.0 = no filter.
severityNoCVSS severity level. Must be one of: CRITICAL, HIGH, MEDIUM, LOW. Omit for all severities.
published_afterNoInclusive lower bound on publish date as YYYY-MM-DD (UTC). Pick this when the user names a starting point, e.g. 'since 2015' → '2015-01-01', 'after March 2024' → '2024-03-01'. Omit to not bound the lower edge. Combine with published_before for ranges.
published_beforeNoInclusive upper bound on publish date as YYYY-MM-DD (UTC). Pick this when the user names an ending point, e.g. 'before 2020' → '2019-12-31', 'up to 2023' → '2023-12-31'. Omit to not bound the upper edge. Combine with published_after for ranges.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important behaviors: the default SLIM response with include='full' for detail, exact NVD-canonical token matching with examples, the global verdict at the response root, the response hint pointing to cve_lookup, rate limits (30/hr free, 500/hr Pro), and the meaning of low/zero counts. 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.

Conciseness4/5

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

The description is information-dense and front-loaded with the primary purpose and filters. It is long but every sentence contributes a distinct piece of guidance (response format, token matching, alternatives, rate limits). It could be improved with bullet points or more distinct paragraph breaks, but no sentence seems wasted.

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

Completeness5/5

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

Given the tool's complexity (14 parameters, multiple caveats, and several sibling alternatives), the description covers the main use cases, non-obvious token behavior, output shape (with return object listed), and rate limits. The presence of an output schema further reduces the need to explain return values, making this description highly complete.

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%, and the schema already documents all parameters thoroughly, including the exact-token caution, sentinel defaults for cvss_min/max, and include trade-offs. The description repeats this context and adds a condensed warning, but it does not meaningfully extend the parameter semantics beyond what the schema already provides.

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 description opens with a specific verb and resource: 'Search CVE database with filters', then enumerates the filter dimensions. It clearly distinguishes from sibling tools like cve_lookup (single CVE by ID) and kev_detail (KEV federal patch deadlines), so the purpose is unambiguous and differentiated.

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

Usage Guidelines5/5

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

The description gives explicit guidance: 'Use for vulnerability discovery by criteria', 'Use cve_lookup for single CVE by ID', 'kev_detail when kev=true filtering', and 'for dependency/package lists use check_dependencies and for a domain's whole stack tech_stack_cve_audit'. It also mentions pairing with cwe_lookup and cve_lookup for drill-down, making when-to-use and alternatives explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with differences between lookup/search/scan/audit for each domain. However, some overlap exists (e.g., email_mx vs email_security_posture, scan_headers vs contrast_scan) which could cause occasional confusion. Overall, boundaries are well-defined.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern (e.g., cve_lookup, check_headers, bulk_cve_lookup) with all lowercase underscores. Variations like kev_detail or ssl_check are minor and still predictable. No chaotic mixing of conventions.

Tool Count4/5

54 tools is high but justified by the broad cybersecurity scope (CVE, ATLAS, D3FEND, Sigma, domain, email, IOC, scanning). Some redundancy exists (e.g., three email-related tools), but the count is not excessive given the API's comprehensive feature set.

Completeness5/5

The tool set thoroughly covers the threat intelligence and domain investigation lifecycle: CVE/KEV/exploit/CWE, ATLAS/D3FEND/Sigma, DNS/WHOIS/SSL/subdomains, email security, IOC enrichment, and active scanning. No significant gaps are apparent for the stated cybersecurity purpose.