ZEN SecDB

cpe_search

Read-onlyIdempotent

Find the CPE vendor and product names that SecDB uses for a product, with the number of CVEs of each one.

What this tool does

Searches the vendor and product names in the CPE configurations of the CVEs, marked as vulnerable. Every result can be passed to product_vulnerabilities. Results go from the most to the least CVEs.

When to use this tool

Use this tool when the user asks:

"What is the CPE name of Apache HTTP Server?"
"Which Fortinet products have known CVEs?"

Use it before product_vulnerabilities when the exact names are not known. For open source dependencies, use purl_audit.

Inputs

query: words to search in the vendor and product names, for example apache http server. Every word must match the vendor or the product.
vendor: exact CPE vendor name, to search only its products.
part: a (application), o (operating system), or h (hardware).
limit: maximum number of results to return (default 25, maximum 100).
page: page of results to return (default 1).

Outputs

total_results, total_pages, current_page
results: each with vendor, product, parts, cve_count
note: present when nothing matches

LLM usage guidelines

When several products match, show them to the user or use the closest one and say which one you chose. Do not merge them.
cve_count shows how many CVEs have the name, not how relevant it is.
No result does not mean that the product has no CVEs: try fewer or different words, or vulnerability_search.

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": {
      "query": "<query>"
    },
    "name": "cpe_search"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page of results
`part`	No	a, o, or h
`limit`	No	Maximum results
`query`	Yes	Words to search in vendor and product names
`vendor`	No	Exact CPE vendor name

Output Schema

Name	Required	Description
`note`	No	Present when nothing matches
`results`	Yes
`total_pages`	Yes	Pages of results
`current_page`	Yes	Page returned
`total_results`	Yes	Vendor and product names found

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses that results are sorted by CVE count descending, that each result can be passed to product_vulnerabilities, and that cve_count is not a relevance signal. It also explains the no-result note and the important caveat that no result does not prove absence of CVEs.

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 definition is well structured with clear sections and front-loaded purpose, and most sentences carry useful operational guidance. It is somewhat long and includes an Outputs section that partly overlaps the output schema, but the length is justified by the tool's search-routing complexity.

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 description covers purpose, alternatives, parameters, output shape, sorting, and failure cases, which is complete for a search tool with an output schema and read-only annotations. Nothing critical for selecting or invoking the tool correctly appears to be 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?

Although schema coverage is already high, the description adds meaningful semantics: every query word must match vendor or product, the vendor parameter requires an exact CPE vendor name, and part values map to application, operating system, and hardware. It also restates pagination defaults and limits in a usable way.

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: search CPE vendor/product names used by SecDB with CVE counts. It clearly distinguishes itself from product_vulnerabilities, purl_audit, and vulnerability_search by explaining when each alternative applies.

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 when-to-use examples, says to call it before product_vulnerabilities when exact names are unknown, and routes open source dependencies to purl_audit. It also provides fallback guidance when no result is found.

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?