KernelScan

list_product_vex_entries

Page through the VEX vulnerability entries of one of the caller's products.

    Returns COMPLETE CycloneDX vulnerability objects for one bounded page
    — never the root document, never all entries — plus ``returned``,
    ``total_matching``, and a ``next_cursor`` to continue with. Every
    result is bounded to 256 KiB: the page stops before the byte limit and
    returns a cursor when necessary. Entries are ordered by CVE id
    (ascending) and carry the same live ``kernelscan.io:exploit_maturity``
    / ``kernelscan.io:kev`` properties as the REST download (backend#337).

    Filters (all optional, combinable):
    - ``statuses``: ``affected`` / ``not_affected`` / ``in_triage``
    - ``severities``: ``critical`` / ``high`` / ``medium`` / ``low`` / ``none``
    - ``kev``: true/false — CISA KEV listing only / non-KEV only
    - ``exploit_maturity``: ``poc`` / ``weaponized``
    - ``cve_ids``: exact-match list of CVE ids

    ``limit`` defaults to 25, maximum 100. ``cursor`` is the opaque
    continuation token from a previous page — it is tied to the product,
    the active filters, AND the current document + threat-overlay
    revision: changing filters, a regenerated cache, or a KEV/PoC signal
    that moved since the last page invalidates it (start a fresh page
    without a cursor — re-using a stale one is rejected, never silently
    re-applied). Within one revision, concatenating all pages yields
    each matching CVE exactly once.

    The COMPLETE multi-megabyte CycloneDX document is served by the
    authenticated REST endpoint ``GET /api/products/{product_id}/vex``
    (same ks_live_ key) — the canonical way to retrieve the full artifact.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kev`	No
`limit`	No
`cursor`	No
`cve_ids`	No
`statuses`	No
`product_id`	Yes
`severities`	No
`exploit_maturity`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so richly: 256 KiB page bound, CVE-id ascending ordering, live exploit_maturity/kev properties, cursor invalidation on filter/cache/revision change, stale cursors rejected rather than silently re-applied, and the each-CVE-exactly-once guarantee across pages.

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?

Long but front-loaded, with the core action, return shape, and filters ordered sensibly and no filler sentences. It is denser and longer than strictly necessary, but each block carries operational 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?

No output schema exists, and the description supplies the return contract (complete CycloneDX vulnerability objects plus returned, total_matching, next_cursor) along with pagination, ordering, and staleness behavior. Nothing needed to invoke or iterate 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 description coverage is 0%, so the description must compensate and does: it enumerates every filter with its allowed values (statuses, severities, kev, exploit_maturity, cve_ids), documents limit default/max (25/100), and gives precise semantics for the opaque cursor including its binding to product, filters, and document revision.

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?

States a specific verb (page through) and resource (VEX vulnerability entries of one of the caller's products), and explicitly contrasts with the full-document route ('never the root document, never all entries'), which distinguishes it from siblings like get_product_vex.

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?

Gives clear conditions for using this paged listing vs the full CycloneDX artifact served by the REST /vex endpoint, and explains how to continue with a cursor. It stops short of naming the sibling tool get_product_vex explicitly as the alternative, so it is clear context without a fully explicit tool-to-tool mapping.

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

All KernelScan 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?