ZEN SecDB

advisory_info

Read-onlyIdempotent

Get detailed information about a specific security advisory.

What this tool does

Retrieves a security advisory (for example RHSA, DSA, USN, GHSA) from SecDB, including title, publication date, severity, summary, description, linked CVEs, CVSS metrics, weaknesses, and the affected and fixed packages and products.

When to use this tool

Use this tool when the user asks:

"Give me details about RHSA-2026:1234."
"Which CVEs are fixed by this advisory?"
"Which package versions are affected, and which version fixes them?"

For a CVE, use vulnerability_info. If the exact advisory ID is not known, use vulnerability_search with type set to advisory.

Inputs

advisory_id: exact advisory identifier (e.g. RHSA-2026:1234, GHSA-xxxx-xxxx-xxxx).

Outputs

advisory_id, url (page on SecDB), source, source_url (original advisory), title, summary, description, solution, severity, published, modified, rights
cves: identifiers of the linked CVEs. Use vulnerability_info, vulnerability_score, or kev_check for their details
cvss: each with cve_id, version, score, severity, and vector. An entry with a null cve_id refers to the whole advisory; the others refer to that CVE
cwe: each with id, name, and url
packages: each with purl, status (for example affected or fixed), vers (versions as a VERS range, for example vers:maven/>=2.0.0|<2.0.11), and remediation. It is null when the packages could not be read, which does not mean that no package is affected
products: each with vendor, product, version, fixed_in, status, text, cpe22, and cpe23
tags, impacts

Fields that SecDB does not have for the advisory are null or empty.

LLM usage guidelines

Do not guess advisory IDs: use the IDs returned by other tools or provided by the user.
If the advisory is not found, try vulnerability_search before saying that it does not exist.
An advisory can list packages of other projects that include the vulnerable code: check purl before saying that a package is affected.
Some advisories list thousands of packages or products, so the response can be very large.

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": {
      "advisory_id": "<advisory_id>"
    },
    "name": "advisory_info"
  }
}

Input Schema

Name	Required	Description	Default
`advisory_id`	Yes	Advisory identifier

Output Schema

Name	Required	Description
`cwe`	Yes	Weaknesses
`url`	Yes	Advisory page on SecDB
`cves`	Yes	Linked CVEs
`cvss`	Yes	CVSS metrics
`tags`	Yes	Tags
`title`	No	Title
`rights`	No	Rights
`source`	Yes	Advisory source
`impacts`	Yes	Impacts
`summary`	No	Summary
`modified`	No	Last modification date
`packages`	Yes	Affected and fixed packages
`products`	Yes	Affected and fixed products
`severity`	No	Severity
`solution`	No	Solution
`published`	No	Publication date
`source_url`	No	Original advisory
`advisory_id`	Yes	Advisory identifier
`description`	No	Description

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

addedOutput schema / properties / cvss / items / properties / cve_id
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

changedOutput schema / properties / cvss / items / required

Previous value: -[
-  "version",
-  "score",
-  "severity",
-  "vector"
-]New value: +[
+  "cve_id",
+  "version",
+  "score",
+  "severity",
+  "vector"
+]

AddedNov 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: null/empty fields mean absent data, a null packages list means unreadable rather than unaffected, package lists can include unrelated projects' purls, and responses may be very large. These are caveats an agent could not derive from the schema or annotations and that directly affect interpretation of results.

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?

Headings are front-loaded and well organized, with the action and selection guidance ahead of the detail. The Outputs section is long and partially duplicates the existing output schema (advisory_id, url, source, title, severity, published, etc.), which costs some efficiency, though the nested-field explanations (null cve_id, VERS ranges, null packages) do earn their place.

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 single-parameter read tool with annotations and an output schema, nothing consequential is missing: it covers identification format, fallback behavior, result interpretation caveats, and response-size risk, and it correctly defers CVE-level lookups to sibling tools.

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?

With one required parameter at 100% schema coverage the baseline is 3, but the description adds format guidance the schema lacks, giving concrete ID shapes ('RHSA-2026:1234', 'GHSA-xxxx-xxxx-xxxx') and a prohibition on guessing identifiers. The schema's own label is only 'Advisory identifier', so this is a real, if modest, addition.

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 starts with a specific verb+resource ('Get detailed information about a specific security advisory') and immediately enumerates what is retrieved (title, dates, severity, CVEs, CVSS, packages). It also explicitly distinguishes itself from vulnerability_info (for CVEs) and vulnerability_search, so an agent can route correctly without opening another 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?

It names concrete user questions that should select this tool, gives an explicit alternative for CVEs, and prescribes a fallback path when the advisory ID is unknown. Edge conditions ('do not guess advisory IDs', 'if not found try vulnerability_search before declaring it absent') are spelled out rather than inferred.

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?