Skip to main content
Glama

ZEN SecDB

by cloud.nttzen.secdb

vulnerability_score

Get CVSS and current EPSS score for a specific CVE.

What this tool does

Returns a full risk snapshot for a CVE, including:

  • CVSS version

  • CVSS base score

  • CVSS severity

  • CVSS vector string

  • human-readable explanation of the CVSS vector

  • current EPSS score

The field cvss_explain provides a natural-language interpretation of the CVSS vector (attack conditions, privileges, user interaction, impact breakdown).

Example: For CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, the explanation may read: "The vulnerability can be exploited remotely over the network with low complexity, without authentication and without user interaction. Exploitation may lead to high impact on confidentiality, high impact on integrity, and high impact on availability."

When to use this tool

Use this tool when the user asks:

  • "What is the CVSS/EPSS of this CVE?"

  • "Explain the CVSS vector of this vulnerability."

  • "What is the severity and why?"

  • "Give me the risk profile for this CVE."

For EPSS historical trends, use epss_timeseries.

Inputs

  • cve_id: valid CVE identifier (CVE-YYYY-NNNNN).

Outputs

  • cvss_version

  • cvss_base_score

  • cvss_base_severity

  • cvss_vector_string

  • cvss_explain - human-readable explanation of the CVSS vector

  • epss_score

LLM usage guidelines

  • Never guess CVSS or EPSS values—always call this tool.

  • Use the cvss_explain field directly when the user wants an interpretation of the vector string.

  • If multiple CVEs are referenced, call the tool once per CVE.

  • Combine this tool with sightings_search or ssvc_calculator for more complete risk assessments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cve_idYesCVE identification (CVE-YYYY-NNNNN)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
epss_scoreYesEPSS score
cvss_explainNoExplain CVSS
cvss_versionYesCVSS version
cvss_base_scoreYesCVSS base score
cvss_base_severityYesCVSS base severity
cvss_vector_stringYesCVSS vector string

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses the exact fields returned, provides a natural-language example of the cvss_explain field, and explicitly warns the LLM never to guess CVSS/EPSS values. It does not mention rate limits or failure modes, but for a read-only lookup tool this is strong transparency.

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 section headers: tool purpose, what it does, when to use, inputs, outputs, and LLM usage guidelines. Every section serves a purpose, and the example explanation is illustrative without being redundant.

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 tool's simplicity (one required parameter) and the presence of an output schema, the description is contextually complete. It covers use cases, alternative tools, combination strategies, and critical LLM guidance (never guess, call per CVE).

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?

The input schema already documents cve_id with 100% coverage, so the baseline is 3. The description adds only a 'valid' qualifier (CVE-YYYY-NNNNN) and a call-per-CVE guideline, but no substantive new parameter semantics beyond the 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 a specific verb+resource statement: 'Get CVSS and current EPSS score for a specific CVE.' It clearly differentiates this tool from siblings like epss_timeseries (historical trends) and vulnerability_info/vulnerability_search by focusing on the risk snapshot for a single CVE.

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 'When to use this tool' section gives explicit example user queries, names an alternative tool for EPSS historical trends, and suggests combining with sightings_search or ssvc_calculator for fuller assessments. This goes well beyond implied usage.

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