ZEN SecDB

feed_report

Run a public ZEN SecDB feed report.

What this tool does

Executes a predefined report on ZEN SecDB public feed data and returns structured results for analytics, trends, distributions, and top-N summaries.

Supported reports can cover public datasets such as:

CVEs
security advisories
EPSS
weaknesses
CPE vendors and products
exploit references
sightings and IOC-related data

Use feed_report_catalog to discover the list of available reports and their supported input parameters.

When to use this tool

Use this tool when the user asks about:

distributions, trends, or counts across public vulnerability data
top CVEs, top weaknesses, top vendors, or similar rankings
timeline-based summaries such as yearly or monthly trends
aggregated views over public SecDB feed data

Do not use this tool when the user asks for details about a single CVE, advisory, or exploit. Use the dedicated lookup tools instead.

Inputs

report_id: identifier of the report to execute
filters: optional object with report-specific filters
limit: optional maximum number of results to return, when supported by the selected report

Outputs

summary: Optional Markdown summary of the report results
report: structured JSON object containing:
- report_id: executed report identifier
- filters: applied filters
- data: structured report rows or aggregated values

LLM usage guidelines

Use feed_report_catalog when you need to discover which public reports are available or which parameters they support.
Do not guess report IDs-use the catalog when uncertain.
Present summary directly to the user-it is already Markdown.
Use report for structured follow-up analysis, comparisons, or tool chaining.
If the selected report does not exist, return a clear not-found error instead of guessing an alternative.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	optional maximum number of results to return, when supported by the selected report
`filters`	No	optional object with report-specific filters
`report_id`	Yes	identifier of the report to execute

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	structured report rows or aggregated values
`filters`	No	optional JSON schema describing supported input parameters
`summary`	No	Optional Markdown summary of the report results
`report_id`	Yes	executed report identifier

TDQS

A5/5.0

Behavior5/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 of behavioral transparency. It discloses the purpose, describes the output structure (summary and report), notes that 'limit' is only applied 'when supported by the selected report,' and specifies error handling: 'If the selected report does not exist, return a clear not-found error instead of guessing an alternative.' This goes beyond the schema in explaining behavior.

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 comprehensive yet efficiently structured with clear sections: 'What this tool does,' 'When to use this tool,' 'Inputs,' 'Outputs,' and 'LLM usage guidelines.' Each section serves a specific purpose, front-loads the core action, and avoids redundant filler.

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 fully equips an agent to decide when to use the tool, how to discover valid report IDs, what parameters are available, what output format to expect, and how to handle missing reports. The presence of an output schema is complemented by the description's explanation of summary vs. report structure, making the context complete for correct invocation.

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?

Schema description coverage is 100%, but the description adds critical usage semantics: it advises using 'feed_report_catalog' to discover supported input parameters, warns not to guess report IDs, and clarifies that the 'limit' parameter is conditional on report support. This adds practical value beyond the raw schema definitions.

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 immediately states 'Run a public ZEN SecDB feed report' and elaborates with 'Executes a predefined report on ZEN SecDB public feed data and returns structured results for analytics, trends, distributions, and top-N summaries.' It clearly distinguishes from siblings by explicitly saying 'Do not use this tool when the user asks for details about a single CVE, advisory, or exploit. Use the dedicated lookup tools instead.'

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?

The description includes a dedicated 'When to use this tool' section with bullet points for appropriate use cases, and a 'Do not use' section pointing to alternatives. It also instructs to use 'feed_report_catalog' for discovering reports and parameters, and warns against guessing report IDs. This provides explicit when-to-use and when-not-to-use guidance.

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

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

Need Help?