EchelonGraph CVE & Exposure

Search CVEs

search_cves

Read-onlyIdempotent

Search/list CVEs from EchelonGraph's CVE feed (NVD + MITRE-CNA pre-NVD + CISA-KEV + EPSS + GitHub GHSA, each polled on a schedule). Filter by severity, minimum CVSS, free text, and sort; page with limit and offset. Returns cves, each with cve_id, severity, cvss_v3_score, echelongraph_score and score_assessed (whether EchelonGraph has scored it), epss_score and kev_listed where the record has them, and the list's total, total_counted (false: the matches were not counted, so total is not a count), total_is_lower_bound (true: at least total), search_relaxed (true: a phrase was relaxed to all of its words), limit and offset. echelongraph_score, echelongraph_severity and echelongraph_risk are EchelonGraph's score only when score_assessed is true. With score_assessed false the CVE is NOT YET SCORED, not scored 0: any of those three it carries (0, NONE, 0) is a placeholder, not a rating, and does not mean the CVE is harmless; the API may leave them out instead, score_confidence is NONE, and score_unassessed_reason says why (a rejected record, withdrawn by its numbering authority, is never scored, and the note says NOT SCORED). The note labels each such CVE NOT YET SCORED: report it that way, never as a score of 0. An answer with no score_assessed (an API older than that field) does not say whether the CVE was scored, the note says so, and a 0 there is not a rating either. Its structured result carries state (measured), measured_at, method, coverage, freshness (null: the feed serves no poll-completion time) and notes, with data equal to the API's JSON; the result's last text block repeats it without data (the first text block) and without the note's sentences (the text block before it), with which notes ends. coverage repeats total, total_counted, total_is_lower_bound, search_relaxed, limit and offset, and gives returned, the rows in this page. Past 30,000 characters of JSON, the first text block holds data cut to fit, and the note says what the cut leaves out and where to read it (TEXT CUT); data in the structured result always holds it whole. Cut, each row keeps at least the fields named above and the first 200 characters of its description (100 on a page too long for that), or rows are left out and the note gives the offset to call next.

Input Schema

TableJSON Schema

Name	Required	Description
`sort`	No	sort order (default: published)
`limit`	No	page size (default 20, max 50)
`offset`	No	rows to skip (default 0)
`search`	No	free-text search (product, vendor, or keyword, e.g. 'tomcat')
`min_cvss`	No	minimum CVSS score
`severity`	No	filter to one severity

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 4, 2026

addedInput schema / properties / offset

Added value: +{
+  "description": "rows to skip (default 0)",
+  "maximum": 10000,
+  "minimum": 0,
+  "type": "integer"
+}

First observedOct 4, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already establish the safe read-only, idempotent, open-world profile, and the description goes well beyond them: it explains score_assessed semantics (a false value is NOT YET SCORED, not 0), search_relaxed, lower-bound totals, truncated text past 30,000 characters, and the fallback page/offset behavior for cut rows. This is unusually rich disclosure of return-shape and edge-case behavior.

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?

The description is enormously oversized: the score_assessed/NOT-YET-SCORED caveat is restated three or four times, and text-truncation behavior is re-explained at length. The first sentence is well front-loaded, but most of the body is repetitive rather than each sentence earning its place.

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 search tool with six optional params and an existing output schema, the description is more than complete: it documents result fields, scoring caveats, coverage counts, and truncation fallbacks beyond what the schema provides. Nothing an agent needs to call 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%, so the schema already documents all six parameters (sort, limit, offset, search, min_cvss, severity). The description restates the same filters without adding format or syntax detail, so a 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?

States a specific verb and resource ('Search/list CVEs from EchelonGraph's CVE feed') and names the five underlying sources (NVD, MITRE-CNA, CISA-KEV, EPSS, GHSA). An agent can distinguish it from siblings like get_cve or cve_summary since this is the list/search entry point.

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

Usage Guidelines3/5

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

The description covers how to filter and page ('Filter by severity, minimum CVSS, free text, and sort; page with limit and offset'), which implies usage, but never states when to prefer this tool over siblings such as cve_intel or get_cve. No explicit alternatives or when-not-to-use conditions are given.

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

All EchelonGraph CVE & Exposure tools Inspect

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.