KernelScan

get_product_vex

Return the VEX MANIFEST for one of the caller's products — metadata, not the document.

    Multi-megabyte CycloneDX documents (up to 8,000+ vulnerability entries)
    are not safe model-context payloads, so this tool returns a bounded
    manifest: CycloneDX format/spec version, product id, generated/expires
    timestamps, the VEX hash and the composite ETag identity, the
    uncompressed size in bytes, total + per-status vulnerability counts,
    and the authenticated REST download path. Reads from the 24h
    ProductVexCache; if the cache is empty/expired the next call to
    ``get_product`` (or the REST endpoint) will regenerate it.

    The MANIFEST carries the same ``kernelscan.io:exploit_maturity`` /
    ``kernelscan.io:kev`` overlay identity as the REST download
    (backend#337), so ETags compare across transports.

    To inspect the entries themselves, use ``list_product_vex_entries``.
    To retrieve the COMPLETE CycloneDX document, use the authenticated
    REST endpoint ``GET /api/products/{product_id}/vex`` (same ks_live_
    key) — that is the canonical way to retrieve the full artifact; no
    MCP tool returns it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`product_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedJun 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so thoroughly: it explains the 24h ProductVexCache read path, when the cache regenerates (next get_product call), why the payload is bounded (multi-megabyte documents unsafe for model context), and the cross-transport ETag identity. This is exactly the operational context an agent needs for a caching, size-bounded read.

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?

Front-loaded with the core purpose and the metadata-vs-document distinction, then layers rationale, cache behavior, and sibling routing. It is longer than average, but every block earns its place by supplying information the agent cannot get from the schema or annotations. Slightly dense, not padded.

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?

With no output schema and no annotations, the description fully enumerates the manifest fields (spec version, product id, timestamps, VEX hash, composite ETag, uncompressed size, total and per-status counts, REST download path), so the agent knows what it will receive. Combined with cache and retrieval guidance, nothing material is missing.

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 0% for the single product_id parameter, so the schema adds nothing. The description partially compensates by scoping it to 'one of the caller's products,' implying ownership and lookup semantics, but it does not state the id format or where to obtain it (e.g., list_products). Adequate but not fully compensating for the coverage gap.

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 and resource ('Return the VEX MANIFEST for one of the caller's products') and immediately disambiguates scope with 'metadata, not the document.' It distinguishes itself from sibling list_product_vex_entries and from get_product without the agent needing to open any schema.

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?

Explicitly routes the agent: use list_product_vex_entries to inspect entries, use the authenticated REST endpoint for the complete document, and states plainly that no MCP tool returns the full artifact. This is a clear when-to-use/when-not-to-use with named alternatives.

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?