ZEN SecDB

kev_list

Read-onlyIdempotent

List the entries of the CISA KEV and EU KEV catalogs of known exploited vulnerabilities, most recent first.

What this tool does

Returns the CVEs in the catalogs, filtered by listing date, catalog, vendor, product, and known use in ransomware campaigns.

When to use this tool

Use this tool when the user asks:

"What was added to KEV this week?"
"Which Fortinet vulnerabilities are known to be exploited?"
"Which KEV entries are used in ransomware campaigns?"

To check CVEs that you already know, use kev_check.

Inputs

since: only return entries listed since then: a period (P7D, P1W, P3M, P1Y) or a date (2026-10-01, included).
catalog: cisa or eu (default: both). It also selects the date used by since and by the order of the results.
vendor: part of the vendor name, for example fortinet.
product: part of the product name, for example fortios.
ransomware: true to only return entries with known use in ransomware campaigns, false for the others.
limit: maximum number of entries to return (default 25, maximum 100).
page: page of results to return (default 1).

Outputs

total_results, total_pages, current_page
entries: each with cve_id, in_cisa, in_eu, vendor, product, vulnerability_name, ransomware, first_listed_date, first_listed_by, cisa_added_date, cisa_due_date, eu_reported_date

LLM usage guidelines

Without catalog, since uses first_listed_date: a CVE already in CISA KEV that has just been added to EU KEV does not appear. To see the recent entries of a catalog, set catalog.
When total_results is greater than the returned entries, say so before drawing conclusions.
An empty list does not mean that nothing is exploited: the catalogs only contain confirmed cases. Use sightings_search for other evidence.
For the score of the CVEs, use vulnerability_score.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "kev_list"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page of results
`limit`	No	Maximum entries
`since`	No	Only entries listed since then: a period (P7D, P1W, P3M, P1Y) or a date (YYYY-MM-DD)
`vendor`	No	Part of the vendor name
`catalog`	No	Catalog (default: both)
`product`	No	Part of the product name
`ransomware`	No	Filter by known use in ransomware campaigns

Output Schema

Name	Required	Description
`entries`	Yes	Entries, most recent first
`total_pages`	Yes	Pages of results
`current_page`	Yes	Page returned
`total_results`	Yes	Entries matching the filters

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety bar is low. The description adds real non-annotation context: the catalog default of both, that `since` falls back to `first_listed_date` and can hide a CVE newly added to EU, and that an empty result is not proof of no exploitation. It stops short of covering pagination behavior or rate limits, but the delta over annotations is meaningful.

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?

Markdown headers make it easy to scan and the purpose and usage examples are front-loaded. Some redundancy remains: the Inputs section largely restates the schema descriptions and the Outputs section restates an existing output schema, adding length without new decision-relevant information.

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?

For a 7-parameter, zero-required list tool with an output schema and full annotation coverage, the description supplies every ambiguity an agent could hit: default catalog scope, date-field selection, truncation awareness (`total_results` vs returned entries), and interpretation of empty results. Nothing needed to call it correctly is missing.

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 coverage is 100%, so the baseline would be 3, but the description explains semantics the schema cannot: `catalog` not only filters but also selects which date `since` compares against and the sort order, and that omitting it causes a re-listed CVE to be missed. It also clarifies partial-match behavior for `vendor`/`product` and the default/max for `limit`.

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 (list entries of the CISA KEV and EU KEV catalogs) plus ordering (most recent first), and explicitly contrasts with the sibling `kev_check` for known CVEs. An agent can distinguish it from `kev_check`, `vulnerability_search`, and `sightings_search` without opening other schemas.

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?

Gives three concrete user-question examples that map to this tool, names the alternative for known CVEs (`kev_check`), and routes elsewhere for non-confirmed exploitation (`sightings_search`) and scoring (`vulnerability_score`). When-to-use and when-not-to-use are both covered.

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

All ZEN SecDB 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?