Skip to main content
Glama

ZEN SecDB

by cloud.nttzen.secdb

sightings_search

Search real-world vulnerability sightings in SecDB.

What this tool does

Retrieves information about where and how a vulnerability appears in the real world, including:

  • Exploit-DB, Metasploit modules, PoCs

  • Scanner plugins (Nessus, OpenVAS/Greenbone)

  • Vendor advisories

  • Social/media references (Reddit, Mastodon, Bluesky)

  • MISP threat-intel sightings

When to use this tool

Use this tool when the user asks:

  • "Is this CVE exploited in the wild?"

  • "Is there a PoC or exploit available?"

  • "Does Nessus or OpenVAS have a plugin for this CVE?"

  • "Is this vulnerability being discussed online?"

  • "Show me all advisories/exploits for this CVE/product."

Inputs

Any of the following may be used:

  • cve_id: search by specific CVE

  • query: full-text search (name, product, advisory ID, exploit reference, etc.)

  • category: filter sightings by type (e.g., exploit, nasl, advisory, scanner, poc, social, misp)

  • status: filter by sighting state (exploited, mitigated, seen, confirmed, etc.)

Outputs

Returns an array of sightings, typically containing:

  • cve_id

  • status

  • category

  • reference

  • details (object with additional structured data)

LLM usage guidelines

  • Use cve_id when the question targets a specific vulnerability.

  • Use query for broad or exploratory searches.

  • Only use valid enum values for category and status.

  • Use this tool instead of assuming exploitation, PoCs, or plugin availability.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoFull-text-search for vulnerability name, CVE ID or Advisory ID, categories, etc.
cve_idNoCVE identification (CVE-YYYY-NNNN)
statusNoSighting status
categoryNoSighting category (scanner, exploit, advisory, nasl, etc.)

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description fully discloses the tool's read-only character implicitly, enumerates the sources it covers, describes the output shape (array with cve_id, status, category, reference, details), and gives operational guidance about valid enum values. It doesn't mention rate limits or pagination, but otherwise provides rich behavioral context beyond minimal expectations.

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 description is long but tightly structured with headers (What, When, Inputs, Outputs, LLM usage guidelines) and front-loads the core purpose in the first sentence. No filler or repetition; every section contributes actionable detail, though it could be slightly trimmed without losing clarity.

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 search tool with four optional parameters and no output schema, the description covers purpose, use cases, parameter semantics, output structure, and usage heuristics. It even includes example queries and enum guidance, leaving little ambiguity for an agent about when and how to invoke it.

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?

Input schema already documents all four parameters at 100% coverage, and the description reinforces this by defining each parameter with examples (e.g., 'category' values like exploit, nasl, advisory, scanner, poc, social, misp) and providing heuristics for choosing between cve_id and query. The description adds contextual meaning beyond the schema descriptions.

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 a clear verb+resource statement ('Search real-world vulnerability sightings in SecDB') and enumerates specific content types (Exploit-DB, Metasploit, scanner plugins, advisories, social media, MISP) that clearly distinguish it from sibling tools like vulnerability_info or vulnerability_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to use this tool' section lists concrete user questions that should trigger this tool, and the LLM usage guidelines advise using cve_id for targeted queries and query for broad searches. It stops short of naming sibling alternatives or explicitly saying when not to use it, so not a full 5.

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