Skip to main content
Glama
Sign In

Distributed Risk

by com.distributedrisk
OverviewDiscussionsAdmin

New vulnerabilities: GitHub, NVD and CISA KEV

list_new_vulnerabilities
Read-onlyIdempotent

What is new across the three vulnerability feeds, exploited first, then by severity, then newest: GitHub's reviewed advisories (the affected package range and the first patched version), NVD's newly published CVE records (software no package ecosystem carries, with NIST's scoring), and the CVEs CISA added to its Known Exploited Vulnerabilities catalog. A KEV addition keeps its own date: it is CISA saying this one is being exploited now, often long after the CVE was published. A CVE that GitHub and NVD both published in the window appears once, from GitHub. For CISA's alerts and joint advisories rather than vulnerabilities, use list_cyber_advisories.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_new_vulnerabilities"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNoWords to find: NVD searches its records, GitHub and KEV entries are matched on summary, package, vendor and product.
sinceNoDated on or after this day (YYYY-MM-DD). Default 7 days ago.
untilNoDated on or before this day. Default today.
sourceNoWhich feeds to read. Default all three. A source that cannot honour a filter is skipped and named in the answer.
ai_stackNotrue: only entries that name AI or agent software. false: only entries that do not.
severityNoThis severity band only. GitHub and NVD; KEV, which does not rate severity, is skipped when it is set.
ecosystemNoOne package ecosystem, as GitHub names it. GitHub only; NVD and KEV are skipped when it is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuine behavior beyond them: deduplication (a CVE published by both GitHub and NVD appears once, from GitHub), KEV's own date semantics differing from CVE publication, and cross-feed ordering (exploited first, then severity, then newest). It stops short of covering pagination or result size, but the added value is substantial.

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 opening clause front-loads the ordering policy and the feed enumeration, and most of the detail is load-bearing. It is dense but slightly long, with the KEV-date sentence and the dedup sentence competing for attention after the alternative-routing line.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description takes on the burden of explaining what comes back and does so for each feed (package range and first patched version for GitHub, NIST scoring for NVD), plus ordering and dedup rules. What is missing is the concrete return shape or per-entry field list, which leaves some inference for an agent parsing results.

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 88%, so the schema does most of the work, including per-parameter notes on query matching per feed and which feeds get skipped for severity/ecosystem. The description adds only indirect meaning (KEV dating, dedup across feeds) and says nothing about limit, since, or until beyond what the schema states. Baseline 3 is appropriate.

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?

Opens with a specific verb+resource and scope: 'What is new across the three vulnerability feeds,' then enumerates exactly which feeds (GitHub reviewed advisories, NVD new CVEs, CISA KEV additions) and what each contributes. This is distinguishable from every sibling at a glance.

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?

Explicitly routes a nearby case away ('For CISA's alerts and joint advisories rather than vulnerabilities, use list_cyber_advisories'), which is a real alternative. However, it never mentions list_ai_stack_vulnerabilities or search_kev, both of which overlap partly with this tool's ai_stack and KEV coverage, so alternative routing is incomplete.

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

All Distributed Risk 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