Skip to main content
Glama

ZEN SecDB

by cloud.nttzen.secdb
OverviewDiscussionsAdmin

ssvc_calculator

Read-onlyIdempotent

Compute CISA SSVC (Stakeholder-Specific Vulnerability Categorization) for a CVE.

What this tool does

Calculates the SSVC decision (Track, Track*, Attend, Act) using:

  • exploitation status

  • technical impact

  • automatable exploitation

  • mission prevalence (user-provided)

  • public well-being impact (user-provided)

This reflects CISA's official SSVC prioritization model.

When to use this tool

Use this tool when the user asks about:

  • how urgently a CVE should be remediated

  • CISA SSVC priority or risk category

  • a structured decision model for remediation

Inputs

  • cve_id: the vulnerability to evaluate (CVE-YYYY-NNNNN)

  • mission_prevalence: M, S, or E (must be provided by the user)

  • public_well_being_impact: M, A, or I (must be provided by the user)

Outputs

  • decision: one of Track, Track*, Attend, Act

  • exploitation

  • technical_impact

  • automatable

  • mission_prevalence

  • public_well_being_impact

  • mission_and_well_being_impact_value

  • vector_string

  • summary: Markdown explanation of the outcome

LLM usage guidelines

  • Always ask the user for mission_prevalence (M/S/E) and public_well_being_impact (M/A/I) before calling.

  • Never guess these values—SSVC depends on user context.

  • Use the summary to explain clearly why the decision was returned.

  • Combine with vulnerability_score or sightings_search if the user needs additional context.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cve_idYesCVE ID
mission_prevalenceYes# Mission Prevalence A mission essential function (MEF) is a function directly related to accomplishing the organization's mission as set forth in its statutory or executive charter. Identifying MEFs is part of business continuity planning or crisis planning. In contrast to non-essential functions, an organization must perform a [MEF] during a disruption to normal operations. The mission is the reason an organization exists, and MEFs are how that mission is realized. Non- essential functions support the smooth delivery or success of MEFs rather than directly supporting the mission. ## Possible values - "M" or "Minimal" Neither support nor essential apply. The vulnerable component may be used within the entities, but it is not used as a mission-essential component, nor does it provide impactful support to mission-essential functions. - "S" or "Support" The vulnerable component only supports MEFs for two or more entities. - "E" or "Essential" The vulnerable component directly provides capabilities that constitute at least one MEF for at least one entity; component failure may (but does not necessarily) lead to overall mission failure. ## Instructions for LLM Ask the user for the "Mission Prevalence" value before calling the tool.
public_well_being_impactYes# Public Well-being Impact ## Possible values - "M" or "Minimal" **Type of Harm -> All**, The effect is below the threshold for all aspects described in material. - "A" or "Material" **Type of Harm -> Physical harm**, Does one or more of the following: - Causes physical distress or injury to system users. - Introduces occupational safety hazards. - Reduces and/or results in failure of cyber-physical system safety margins. **Type of Harm -> Environment**, Major externalities (property damage, environmental damage, etc.) are imposed on other parties. **Type of Harm -> Financial**, Financial losses likely lead to bankruptcy of multiple persons. **Type of Harm -> Psychological**, Widespread emotional or psychological harm, sufficient to necessitate counseling or therapy, impact populations of people. - "I" or "Irreversible" **Type of Harm -> Physical harm**, One or both of the following are true: - Multiple fatalities are likely. - The cyber-physical system, of which the vulnerable component is a part, isl ikely lost or destroyed. **Type of Harm -> Environment**, Extreme or serious externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) are imposed on other parties. **Type of Harm -> Financial**, Social systems (elections, financial grid, etc.) supported by the software are destabilized and potentially collapse. **Type of Harm -> Psychological N/A ## Instructions for LLM Ask the user for the "Public Well-being Impact" value before calling the tool.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
summaryNoSummary
decisionYesDecision
automatableYesAutomatable
exploitationYesState of Exploitation (Evidence of Active Exploitation of a Vulnerability)
vector_stringYesSSVC Vector String
technical_impactYesTechnical Impact (Technical Impact of Exploiting the Vulnerability)
mission_prevalenceYesMission Prevalence (Impact on Mission Essential Functions of Relevant Entities)
public_well_being_impactYesPublic Well-being Impact
mission_and_well_being_impact_valueYesMission and Well-Being Impact Value

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), and the description adds real behavioral context: the tool cannot be called meaningfully without two user-supplied context values, and the summary field should be used to explain the decision. It does not discuss failure modes for unknown CVEs or rate limits, so it stops short of a 5.

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?

Header-delimited and front-loaded, so an agent can scan purpose, triggers, inputs, and outputs quickly. However, the 'Outputs' section enumerates fields that an output schema already provides, and the LLM usage bullets partially duplicate the When-to-use section.

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 three-parameter, deterministic calculator with full schema coverage, an output schema, and rich annotations, nothing an agent needs is missing: purpose, trigger conditions, input provenance requirements, and downstream composition with sibling tools are all present.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds the cve_id format (CVE-YYYY-NNNNN) that the schema omits and reinforces that M/S/E and M/A/I values are user-context inputs rather than derivable. The mission/well-being value explanations largely restate the schema, limiting the gain.

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 and resource ('Compute CISA SSVC ... for a CVE') and names the exact decision categories returned (Track, Track*, Attend, Act). It clearly distinguishes itself from siblings like vulnerability_score and sightings_search, which are explicitly called out as complements rather than alternatives.

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?

Includes a dedicated 'When to use this tool' section listing three concrete user intents (remediation urgency, CISA SSVC priority, structured decision model) plus explicit LLM instructions to always collect mission_prevalence and public_well_being_impact before calling and never guess. It also names sibling tools to combine with.

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
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