ZEN SecDB

product_vulnerabilities

Read-onlyIdempotent

List the CVEs of a product by its CPE vendor and product names, with the affected version ranges.

What this tool does

Returns the CVEs whose CPE configuration marks the product as vulnerable, most recent first. Use it for assets that have no Package URL, such as appliances, operating systems, and commercial software.

When to use this tool

Use this tool when the user asks:

"Which CVEs affect FortiOS?"
"What are the latest vulnerabilities of this product?"
"Is this product version affected by a known CVE?"

For open source dependencies, use purl_audit. If the CPE names are not known, use cpe_search first.

Inputs

vendor: CPE vendor name, for example fortinet.
product: CPE product name, for example fortios.
limit: maximum number of CVEs to return (default 25, maximum 100).
page: page of results to return (default 1).

Outputs

total_results, total_pages, current_page: CVEs for the product across all pages
cves: each with cve_id, published, severity, score, description, affected_versions
note: present when no CVE matches

LLM usage guidelines

This tool does not filter by version: compare the user's version with affected_versions, and say that the comparison is yours. An entry of all means that the configuration has no version limits.
When total_results is greater than the returned CVEs, say so before drawing conclusions about a version.
When total_results is 0, do not say that the product is safe: the vendor or product name may differ from the CPE one. Use cpe_search to find it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "vendor": "<vendor>",
      "product": "<product>"
    },
    "name": "product_vulnerabilities"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page of results
`limit`	No	Maximum CVEs
`vendor`	Yes	CPE vendor name
`product`	Yes	CPE product name

Output Schema

Name	Required	Description
`cves`	Yes	CVEs with the affected versions
`note`	No	Present when no CVE matches
`total_pages`	Yes	Pages of results
`current_page`	Yes	Page returned
`total_results`	Yes	Total CVEs for the product

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 5, 2026

addedOutput schema / properties / current_page

Added value: +{
+  "description": "Page returned",
+  "type": "integer"
+}

removedOutput schema / properties / total

Removed value: -{
-  "description": "Total CVEs for the product",
-  "type": "integer"
-}

addedOutput schema / properties / total_pages

Added value: +{
+  "description": "Pages of results",
+  "type": "integer"
+}

addedOutput schema / properties / total_results

Added value: +{
+  "description": "Total CVEs for the product",
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "total",
-  "cves"
-]New value: +[
+  "total_results",
+  "total_pages",
+  "current_page",
+  "cves"
+]

AddedNov 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already establish that this is a safe read-only, idempotent operation. The description adds important behavior beyond annotations: results are most recent first, it does not filter by version, pagination totals are exposed, a note appears when nothing matches, and zero results must not be interpreted as safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is well structured with clear headings, front-loaded purpose, and bulleted usage guidance. Despite its length, every section provides actionable information for selecting and invoking the tool.

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?

The tool has an output schema, but the description still helpfully summarizes output fields and interpretation rules. It covers selection guidance, parameter meaning, output behavior, and important caveats about version comparison and zero results.

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 description coverage is 100%, so the schema already documents all four parameters. The description adds useful examples for `vendor` and `product` (`fortinet`, `fortios`) and explains the version comparison limitation, though it does not add much beyond the schema for `limit` and `page`.

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 states a specific verb and resource: list the CVEs of a product by CPE vendor and product names, with affected version ranges. It explicitly distinguishes this tool from `purl_audit` for open source dependencies and from `cpe_search` when CPE names are unknown.

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?

It gives explicit user-question examples, explains when to use this tool versus alternatives, and names the fallback tool when CPE names are not known. This leaves little ambiguity for an agent choosing among siblings.

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?