Skip to main content
Glama

PG1 Sovereign Threat Intelligence

get_cve_batch

PG1 Sovereign Threat Intelligence: looks up multiple CVE identifiers in a single call, each enriched with NVD description/CVSS and CISA KEV status (plus the FIRST.org EPSS score when this server serves EPSS in paid responses) — same enrichment as get_cve_details, batched. Payment required: $0.01 via x402, sent in params._meta['x402/payment'] (the PAYMENT-SIGNATURE header is also accepted), or a valid Gumroad license key (X-API-KEY header). SIBLING DIFFERENTIATION: Use for looking up several known CVE ids at once (e.g. from an SBOM or scan report). Do NOT use for a single CVE (use get_cve_details, lower overhead) or for discovering CVEs by vendor/product (use get_cve_by_product). BEHAVIOR: Accepts up to 20 ids per call; malformed or not-found ids are reported per-entry rather than failing the whole batch.

Input Schema

NameRequiredDescriptionDefault
cve_idsYesArray of CVE identifiers, each formatted 'CVE-YYYY-NNNN'. Max 20 per call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations to lean on, the description carries the full burden and does so: payment is required ($0.01 via x402 in params._meta['x402/payment'], alternative PAYMENT-SIGNATURE header, or Gumroad license key in X-API-KEY), the batch cap is 20 ids, and malformed/not-found ids degrade per-entry rather than failing the whole batch. It also flags a conditional capability (EPSS only in paid responses), which prevents a wrong expectation about 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?

Front-loaded with purpose and enrichment, then segmented into payment, sibling differentiation and behavior, so an agent can stop reading once it has what it needs. It is somewhat long and the all-caps section labels add bulk, but every sentence carries information.

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?

No output schema and no annotations, yet the description covers what is returned (per-entry enrichment and per-entry error reporting), what it costs and how to pay, the input ceiling, and how it differs from siblings. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% – the cve_ids array, its 'CVE-YYYY-NNNN' format and the 20-per-call cap are already documented in the schema. The description restates the batch context but adds no format, ordering, or error semantics beyond what the schema provides, so the baseline 3 applies.

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 (looks up) and resource (multiple CVE identifiers in one call) and explicitly frames the scope as a batched version of get_cve_details. It also names the exact enrichment returned (NVD description/CVSS, CISA KEV, EPSS), so the agent knows what it gets without opening a 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?

Explicitly prescribes when to use it (several known CVE ids at once, e.g. from an SBOM or scan report) and when not to, naming the two correct alternatives (get_cve_details for a single id, get_cve_by_product for vendor/product discovery) with the selecting condition for each.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.