Skip to main content
Glama

cve-intelligence

by com.cve-security
OverviewDiscussionsAdmin

get_cve

Read-onlyIdempotent

Full intelligence record for one CVE: per-scorer CVSS, EPSS, CISA KEV/ransomware/SSVC, four remote-detection modalities (the checks that work over the network) plus a host-check tier (self-contained Nuclei templates and Metasploit local modules that run on the system itself) and the Sigma log-detection layer, both kept out of scannable coverage, per-product fixed versions (fixed = first patched build; affected_through = the last vulnerable build, so upgrade past it), news/community coverage, intelligence summary, and bod_26_04: the BOD 26-04 Table 1 read on both exposure branches (CISA's row numbers and timelines from KEV status and CISA's SSVC Automatable and Technical impact) with CISA's KEV due date, forensic triage flag and the KEV entry's action text (kev_required_action, CISA's requiredAction field); the agency's exposure tag decides the row. other_databases lists the CVE's records in ENISA's EUVD, BDU (FSTEC of Russia), CNVD (CNCERT/CC) and JVN iPedia (JPCERT/CC and IPA) with the address of each. products lists the vendor and product pairs the page lists and the CPE entries NVD's configurations name: with cpes_source nvd_configurations, configurations carries them as NVD writes them (each entry's vulnerable flag, AND and OR operators, negate and the version bounds verbatim, up to 100 matches here, configurations_cap for more), and cpes their names; with nvd_cpe_list, cpes holds the first 25 names in sort order our NVD ingest stores, flagged by cpes_may_be_incomplete. No key required over MCP; an API key on the HTTP request (Authorization: Bearer cvs_live_…) is honored for attribution. Absence semantics: a null field means this dataset holds no such record. The source may still hold one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesCVE id, such as CVE-2024-3400
configurations_capNoHow many of NVD's configuration matches products.configurations carries (default 100; 0 to 500). GET /api/cve/{id} carries up to 500.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / configurations_cap
      Added value: +{
+  "description": "How many of NVD's configuration matches products.configurations carries (default 100; 0 to 500). GET /api/cve/{id} carries up to 500.",
+  "maximum": 500,
+  "minimum": 0,
+  "type": "integer"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"CVE id, e.g. CVE-2024-3400"New value: +"CVE id, such as CVE-2024-3400"
  3. First observed

TDQS

A3.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true. The description adds substantial behavioral context beyond annotations: absence semantics ('a null field means this dataset holds no such record'), auth details ('No key required over MCP; an API key ... is honored'), and the configurations_cap default/range and scannable coverage exclusion. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely long and dense single block of text with nested clauses and parentheticals. While the first sentence front-loads the purpose, the remainder is not concise and lacks structure (no bullets, very long sentences). Every detail may be useful given no output schema, but the presentation is inefficient.

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?

Given the absence of an output schema and the tool's high complexity (many nested fields), the description comprehensively explains return contents, field meanings, and edge cases like absence semantics and caps. It covers what an agent needs to interpret the response, so it is complete for this context.

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 coverage is 100%; both parameters (id and configurations_cap) are fully described in the schema. The description repeats some of this ('up to 100 matches here, configurations_cap for more') but adds no new syntax or constraints beyond the schema. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Full intelligence record for one CVE'. It clearly identifies the resource (single CVE) and scope (full record). However, it does not explicitly name or differentiate from sibling tools like search_cves or table1_read, so it falls short of a 5.

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

Usage Guidelines2/5

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

No explicit when-to-use guidance or alternatives are provided. The description is purely descriptive of contents; it never says when to choose this tool over search_cves or table1_read. Implied usage exists (retrieve full record for a known CVE), but no exclusions or routing.

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

All cve-intelligence 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