Skip to main content
Glama
Sign In

ZEN SecDB

by cloud.nttzen.secdb
OverviewDiscussionsAdmin

package_info

Read-onlyIdempotent

List the security advisories known for a package, with the affected and fixed versions.

What this tool does

Returns the advisories of a package across all its versions, most recent first. This covers more ecosystems than purl_audit, for example github, cpan, apache, and freebsd.

When to use this tool

Use this tool when the user asks:

  • "Which vulnerabilities has this package had?"

  • "Which version fixes this vulnerability?"

  • "Which version should I upgrade to?"

To check whether a specific version is vulnerable, use purl_audit or linux_audit: this tool does not evaluate versions.

Inputs

  • purl: Package URL. The version is ignored. For Linux packages, add the distro qualifier to limit the results to one release, for example pkg:deb/ubuntu/curl?distro=noble.

  • limit: maximum number of advisories to return (default 25, maximum 100).

  • page: page of results to return (default 1).

Outputs

  • total_results, total_pages, current_page: advisories for the package across all pages

  • advisories: each with advisory_id, title, severity, published, cves, status, affected, fixed_versions

    • affected: version ranges, each with versions and, for Linux packages, distro

    • fixed_versions: each with version and, for Linux packages, distro. A version is either reported as fixed by the advisory or the exclusive upper bound of an affected range

LLM usage guidelines

  • When total_results is 0, say that SecDB has no advisories for this package name, not that the package is safe. Names must match exactly.

  • To recommend an upgrade, consider all the advisories and check the resulting version with purl_audit when its ecosystem is supported.

  • status can include malicious: tell the user to remove the package instead of upgrading it.

  • If fixed_versions is empty, say that no fix is known. Do not guess a version.

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": {
      "purl": "<purl>"
    },
    "name": "package_info"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage of results
purlYesPackage URL (PURL)
limitNoMaximum advisories

Output Schema

NameRequiredDescriptionDefault
advisoriesYesAdvisories, with the affected and fixed versions
total_pagesYesPages of results
current_pageYesPage returned
total_resultsYesTotal advisories for the package

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedOutput schema / properties / current_page
      Added value: +{
+  "description": "Page returned",
+  "type": "integer"
+}
    • removedOutput schema / properties / total
      Removed value: -{
-  "description": "Total advisories for the package",
-  "type": "integer"
-}
    • addedOutput schema / properties / total_pages
      Added value: +{
+  "description": "Pages of results",
+  "type": "integer"
+}
    • addedOutput schema / properties / total_results
      Added value: +{
+  "description": "Total advisories for the package",
+  "type": "integer"
+}
    • changedOutput schema / required
      Previous value: -[
-  "total",
-  "advisories"
-]New value: +[
+  "total_results",
+  "total_pages",
+  "current_page",
+  "advisories"
+]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds substantial operational context: results are most recent first, the purl version is ignored, ecosystem coverage is broader than purl_audit, and edge cases like zero results and malicious advisories are explained. It also clarifies that fixed_versions may be an exclusive upper bound rather than an explicit advisory fix.

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?

Well front-loaded with clear section headers and short scannable bullets. The Inputs block largely repeats schema defaults and maximums, and the Outputs block restates much of the output schema, but the sections remain useful for guiding the agent's interpretation and the description is not bloated.

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?

Complete for a paginated advisory-list tool: it covers input qualifiers, pagination fields, ecosystem scope, result semantics, and important edge cases such as empty advisories, empty fixed_versions, and malicious packages. With an output schema present, the description need not do more.

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 coverage is 100%, so defaults and maximums for limit and page are already documented. The description nevertheless adds real meaning beyond the schema: the purl version component is ignored and Linux users can add a distro qualifier, with a concrete example. That extra semantics lifts it above the baseline 3.

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 — list security advisories for a package with affected and fixed versions — and explicitly distinguishes itself from purl_audit and linux_audit, which evaluate specific versions. An agent can route correctly without opening 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?

Provides explicit when-to-use triggers with example user questions, names the alternative tools for version evaluation, and adds LLM usage rules for zero results, malicious status, and empty fixed_versions. The when-not condition is unambiguous.

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

All ZEN SecDB toolsInspect
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