Skip to main content
Glama

ZEN SecDB

by cloud.nttzen.secdb

feed_report_catalog

List available public ZEN SecDB feed reports.

What this tool does

Returns the catalog of available ZEN SecDB public feed reports, including their identifiers, descriptions, and supported input parameters.

This tool helps discover which reports can be executed through feed_report.

When to use this tool

Use this tool when:

  • the user asks what public reports are available

  • you need to discover the correct report ID before running a report

  • you need to inspect supported filters or input parameters

  • you are unsure which report best matches the user request

Inputs

This tool does not require any input.

Outputs

  • reports: array of report definitions, each containing:

    • report_id: report identifier

    • title: human-readable report title

    • description: short explanation of what the report returns

    • input_schema: optional JSON schema describing supported input parameters

LLM usage guidelines

  • Use this tool before feed_report whenever the correct report ID or supported parameters are not already known.

  • Do not invent report IDs or parameters not present in the catalog.

  • Prefer the most specific matching report for the user request.

  • When useful, briefly summarize the most relevant available reports before calling feed_report.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
reportsNo

TDQS

A4.7/5.0
Behavior4/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. It clearly indicates a read-only catalog operation ('List','Returns') and describes the output structure. It does not mention auth, rate limits, or side effects, but for a zero-input, non-destructive listing tool, this is sufficient context.

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 markdown sections (What this tool does, When to use, Inputs, Outputs, LLM usage guidelines) and front-loaded purpose. Despite length, every sentence provides actionable guidance with no redundancy.

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 zero-parameter catalog tool, the description fully covers purpose, usage, inputs, outputs, and relationship to the sibling feed_report. The output section describes the report objects, and the guidance on not inventing IDs adds important safety context.

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?

The tool has zero parameters, so schema coverage is 100% and the baseline is 4. The description explicitly reinforces this with 'This tool does not require any input.' This adds clarity beyond the empty schema.

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 opens with 'List available public ZEN SecDB feed reports' and explains it returns a catalog of report identifiers, descriptions, and input parameters. It explicitly distinguishes from the sibling tool feed_report by stating it enables discovery of reports executable through feed_report.

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?

Includes a dedicated 'When to use this tool' section with concrete criteria (e.g., user asks what reports are available, need to discover report ID, inspect filters). LLM usage guidelines add explicit direction: 'Use this tool before feed_report whenever the correct report ID or supported parameters are not already known,' indicating when to use versus the alternative.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (e.g., vulnerability_search for discovery, vulnerability_info for full details, vulnerability_score for CVSS/EPSS, epss_timeseries for history). However, pairs like vulnerability_info vs. vulnerability_score and linux_audit vs. purl_audit have overlapping functionality, though detailed descriptions help differentiate them.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case pattern with a descriptor and an operation noun (e.g., vulnerability_info, linux_audit, sightings_search, ssvc_calculator). No mixed conventions or stylistic deviations are present.

Tool Count5/5

The 11 tools are well-scoped for a vulnerability intelligence server, covering search, details, scoring, trends, audits, reports, and prioritization. The count is within the expected 3-15 range and each tool contributes a distinct capability.

Completeness5/5

The tool surface covers the full vulnerability intelligence lifecycle: discovery (vulnerability_search), detailed lookup (vulnerability_info), risk scoring (vulnerability_score), EPSS history, real-world sightings, SSVC prioritization, audits for both OS packages and application dependencies, and aggregated reports. No obvious dead-end or missing critical operation is apparent.

Resources