Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@EchelonGraph MCP Server show me the internet exposure footprint for CVE-2021-44228"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CVE and internet-exposure data for Claude, Cursor, Cline, and any MCP client, straight from EchelonGraph's free public feed.
It exposes EchelonGraph's CVE Pulse (NVD + MITRE-CNA pre-NVD + CISA-KEV + EPSS + GitHub GHSA, fused into one score) plus a per-CVE internet-exposure footprint: how many internet-facing services (distinct ip:port) EchelonGraph's KEV-exposure radar has on record running a version that maps to the CVE. Exposure counts are derived from Shodan data. Shodan data is owned by Shodan, which holds its copyright (© Shodan).
Free and keyless: no API key, no auth, read-only. The server makes no request other than the API call a tool needs to answer.
Tool | What it does |
| Counts of active CVEs by severity, and when the feed was last updated. |
| Search/filter CVEs (severity, min CVSS, text, sort) with EchelonGraph scores. |
| Full detail for one CVE (CVSS v3/v4, EG score, EPSS, KEV+ransomware, GHSA, CWE, references). |
| Internet-exposure footprint for a CVE: exposed service count (distinct ip:port, the |
| Aggregate totals across the exposure radars: shadow AI; services running CISA-KEV CVEs; unauthenticated data stores and observability UIs, found through Shodan (LeakIX when Shodan query credits run low) and then confirmed by EchelonGraph's own identified check, which is not a pure read (on Redis it names its client; on ClickHouse its query lands in the server's query log); leaked credentials. |
Every figure is as fresh as the schedule that refreshes it. The CVE feed is polled from its sources on a schedule; each radar refreshes on its own.
cve_exposure countsEvery 12 hours, when Shodan query credits allow, the KEV-exposure radar runs one Shodan query per tracked product, reads up to 100 ip:port services per query, and keeps a service when its banner version matches a CISA-KEV or high-EPSS (>= 0.5) CVE. A service not seen on its port for 21 days is dropped. A count is therefore a banner-version inference over a sample: not an exploit test, and not an internet-wide census.
last_seen is when a service was last seen listening on its port, not when its vulnerable
version was last confirmed. Between searches, a re-check that finds the port still listed by
Shodan InternetDB refreshes last_seen without re-reading the banner, so a patched service can
stay counted while its port stays open.
The unit is a service, not a machine. Shodan returns one banner per port and the radar keys
each observation on ip:port, so a machine answering on two ports counts twice. The API field
keeps its name, exposed_hosts, and so does distinct_hosts in the radar totals.
The radar only looks for its tracked set of CVEs, so a zero means different things:
API answer | What the tool says |
| NOT ASSESSED: outside the radar's tracked set; 0 is not a measurement. |
| A measured zero in the radar's sample: none of the up to 100 services it read per tracked-product query matched. Not an internet-wide zero. |
no | The API did not say whether the CVE is in the tracked set: an older API, or the radar cannot decide (for example a CISA-KEV or high-EPSS CVE in a tracked product with 0 services on record). 0 exposed services on record, with no claim either way. |
HTTP 400, or an id that is not | An error result tagged |
exposure_radar counts shadow AIThe shadow-AI radar's answer mixes numbers that count exposed services with numbers that count
every observation. So exposure_radar regroups it by what each number counts, and its note
labels each one. Only shadow_ai.confirmed_exposed counts exposed services.
Field | What it counts |
| Confirmed exposed: services EchelonGraph's probes found answering without an authentication gate (liveness |
| The same services, by category. |
| Confirmed-exposed services first recorded in the last 24 hours. |
| Every Certificate Transparency or Shodan observation on record, whatever its verification state: observed, not exposed. |
| The same observations, by category. |
| Observations first recorded in the last 24 hours. |
| Observations per UTC day over the last 30 days. |
| Up to ten products, countries and issuers, ranked by observations, not by exposed services. An issuer is the certificate's CA for a Certificate Transparency observation, and the hosting operator Shodan reports for a Shodan one. |
| When the latest observation was recorded. |
| Observations where a probe observed an authentication gate: a 401/403, a login page or an auth marker. |
| Observations whose service answered, but where no probe could tell whether it enforces authentication. |
Neither authentication count is part of confirmed_exposed, and observed.total minus
confirmed_exposed.total is not a count of secured services: it also holds observations not
yet verified, whose hostname no longer resolves, or whose service no longer answers openly.
The tool relays no number it cannot label. A stats field this version does not know is left out, and the note names it; so is a count in an unexpected shape. A ranked row carries only its name and its count.
Related MCP server: purify-feeds-mcp
Every tool answers in one of two shapes, so a model reading the result cannot mistake an outage for an all-clear:
Success — the first text block is the API's JSON verbatim; the second is a one-line
note saying the call succeeded, which base URL answered, and what it found. When the
feed genuinely holds nothing for the query the note says so in words ("we looked and
found nothing … not a lookup failure"), because a measured zero is a measurement. The
exception to verbatim is exposure_radar's shadow_ai: its counts are regrouped as above,
and its poller block carries only running and last_run_at, or is dropped when it
carries no real completion time. The block's other fields describe the server instance that
answered, not the radar. Its last_run_at is when the radar's leader last
completed a Certificate Transparency (crt.sh) cycle, and its running is true only when
that was within 30 minutes of the answer. When running is true, the note says the
radar's leader last completed a cycle at that time; when it is false, the note says no
cycle has completed since that time; when last_run_at is absent, the note says the
radar's freshness is unknown and the block is left out. An older API answered from
whichever server instance served the request, and a follower instance sent
running: false with the zero time 0001-01-01T00:00:00Z; that too is unknown freshness,
never presented as a stopped radar.
Failure — an MCP error result (isError: true) whenever the lookup did not complete:
the host could not be reached, it answered non-2xx, it took longer than the timeout, or
it answered 2xx with a body that is not a JSON object. The text names the tool, the
cause (status code or error kind), the path, and the base URL, and says it is not a
finding. A failure is never rendered as a success with null fields.
Add it to your MCP client's config. It runs via npx — no global install needed.
claude_desktop_config.json → mcpServers:
{
"mcpServers": {
"echelongraph": {
"command": "npx",
"args": ["-y", "echelongraph-mcp"]
}
}
}~/.cursor/mcp.json (or the client's MCP settings):
{
"mcpServers": {
"echelongraph": {
"command": "npx",
"args": ["-y", "echelongraph-mcp"]
}
}
}Restart the client, then ask: "Is CVE-2023-44487 actively exploited, and how many exposed services does EchelonGraph's radar have on record for it?"
Env var | Default | Purpose |
|
| Override the API base (self-host / proxy). |
|
| Per-request timeout. A slower answer is reported as a failed lookup, not as empty data. |
npm install
npm run build # tsc → dist/
npm test # build, then behavioural tests against a stub API (no network needed)
npm run smoke # spawn the server + call cve_exposure against the production APInpm run smoke calls the production API with this package's User-Agent, so its requests are
counted as external MCP adoption. npm test never leaves the machine.
The code is MIT-licensed.
The CVE Pulse compilation (how EchelonGraph combines its CVE sources, and the EchelonGraph score) is © EchelonGraph, served under the CVE Pulse free-access terms; the source records it compiles stay under their publishers' terms.
Exposure counts are derived from Shodan data. Shodan data is owned by Shodan, which holds its copyright (© Shodan). EchelonGraph claims no ownership of it or copyright in it.
Internet-exposure footprint for one CVE from EchelonGraph's KEV-exposure radar: how many internet-facing services (distinct ip:port, returned as exposed_hosts; a machine answering on two ports counts twice) the radar has on record running a version its CVE matcher maps to this CVE, with a country/product breakdown and a ransomware flag. Aggregate and host-redacted; free and keyless. Method: exposure counts are derived from Shodan data. Shodan data is owned by Shodan, which holds its copyright (© Shodan). Every 12 h, when Shodan query credits allow, the radar runs one Shodan query per tracked product, reads up to 100 ip:port services per query, and keeps a service when its banner version matches a CISA-KEV or high-EPSS CVE; a service not seen on its port for 21 days is dropped. last_seen is when a service was last seen listening on its port, not when its vulnerable version was last confirmed: between searches a re-check that finds the port still listed refreshes it without re-reading the banner, so a patched service can stay counted while its port stays open. A count is therefore a banner-version inference over a sample, not an exploit test and not an internet-wide census. The radar only looks for its tracked set of CVEs: for a CVE outside that set the result says NOT ASSESSED, and its 0 is not a measurement.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | a CVE ID, e.g. CVE-2023-44487 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so richly: it discloses the data source (Shodan), the 12h refresh cadence and credit limits, the 21-day staleness drop, the crucial caveat that last_seen is port-liveness rather than vulnerability confirmation, that counts are banner-version inferences over a sample rather than exploit tests or a census, and that it is aggregate, host-redacted, free and keyless.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first clause, which is good, but the single dense paragraph runs long and includes material of questionable necessity (the Shodan copyright/ownership aside) alongside genuinely valuable caveats. Each caveat earns its place; the legal aside and some redundancy do not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe the return shape, and it does: exposed_hosts count with the double-counting rule, country/product breakdown, and a ransomware flag. Combined with the scope and methodology caveats, an agent has everything needed to interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single cve_id parameter is fully documented in the schema (100% coverage), so the schema does the heavy lifting. The description adds meaning about which CVE values are actually assessed (tracked set vs NOT ASSESSED), but no syntax or format detail beyond the schema's own example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'internet-exposure footprint for one CVE', and immediately defines the unit (distinct ip:port, exposed_hosts) and the scoping to a single CVE, which cleanly separates it from aggregate siblings like exposure_radar and lookup siblings like get_cve. An agent knows exactly what this returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when the tool is informative versus not: it only assesses a tracked set of CVEs, and for anything outside that set the result says NOT ASSESSED and its 0 is not a measurement. It does not, however, explicitly route the agent to a named alternative (e.g., exposure_radar or cve_summary) for cases where a per-CVE view is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary of EchelonGraph's CVE Pulse feed: total active CVEs and counts by severity (critical/high/medium/low/none), plus when the feed was last updated. The feed is polled from its sources on a schedule, so this is the state as of that update.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the feed is polled on a schedule and reflects state as of the last update (a freshness/staleness caveat), but omits auth requirements, rate limits, or whether the summary can be stale relative to live source data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The core content of the summary is front-loaded, and the freshness caveat follows as a short qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no parameters, the description must explain the return shape itself — and it does, listing the severity buckets and last-updated timestamp. Only the freshness semantics (how often polled, how stale it can get) remain slightly under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline credit applies. No parameter-level gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (EchelonGraph's CVE Pulse feed) and enumerates exactly what the result contains: total active CVEs, counts by severity buckets, and last-update time. This aggregate-summary identity is clearly distinguishable from retrieval siblings like get_cve and search_cves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — an agent can infer this is for a high-level overview rather than fetching individual CVEs, but the description never says when to prefer it over get_cve/search_cves/exposure_radar nor sets any exclusions. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate totals from EchelonGraph's internet-exposure radars, each refreshed on its own schedule: shadow AI services found through Certificate Transparency logs and Shodan and then checked by EchelonGraph's identified probes; internet-facing services running actively-exploited (CISA-KEV) CVEs, plus the ransomware-linked subset, derived from Shodan data; unauthenticated data stores and observability UIs, found through Shodan (LeakIX when Shodan query credits run low) and then confirmed by EchelonGraph's own identified check (not a pure read: on Redis it names its client, and on ClickHouse its query is recorded in the server's query log); and leaked credentials sampled from public GitHub push events. The kev_exposure and exposed_databases distinct_hosts figures count distinct ip:port services, so a machine answering on two ports counts twice. The shadow_ai result is regrouped by what each number counts, and carries no number the tool cannot label. shadow_ai.confirmed_exposed counts services EchelonGraph's probes found answering without an authentication gate (liveness active, or rechecking during a re-check): confirmed_exposed.total is the sum of confirmed_exposed.by_category, and confirmed_exposed.last_24h counts those first recorded in the last 24 h. Only confirmed_exposed counts exposed services. shadow_ai.observed counts every Certificate Transparency or Shodan observation on record, whatever its verification state: its numbers are observed, not exposed. They are observed.total; observed.by_category (the same observations by category); observed.last_24h (those first recorded in the last 24 h); observed.trend_30d (observations per UTC day over the last 30 days); and observed.top_products, observed.top_countries and observed.top_issuers (up to ten products, countries and issuers ranked by observations, where an issuer is the certificate's CA for a Certificate Transparency observation and the hosting operator Shodan reports for a Shodan one). shadow_ai.authentication counts observations by probe outcome: authentication.observed where a probe observed an authentication gate (a 401/403, a login page or an auth marker), and authentication.not_determined where the service answered but no probe could tell. Neither authentication count is part of confirmed_exposed, and observed.total minus confirmed_exposed.total is not a count of secured services. The shadow-AI poller block carries only running and last_run_at: last_run_at is when the radar's leader last completed a Certificate Transparency (crt.sh) cycle, and its running is true only when that was within 30 minutes of the answer. Shodan data is owned by Shodan, which holds its copyright (© Shodan).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so extensively. It discloses data sources, refresh schedules, counting semantics (distinct ip:port services), the distinction between observed and confirmed exposed, and even notable side effects: 'not a pure read: on Redis it names its client, and on ClickHouse its query is recorded in the server's query log.' It also notes Shodan copyright and poller freshness rules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single very long, dense paragraph with no headings or structural breaks. While much of the output-field explanation is substantive given the absent output schema, it is far from concise and is not front-loaded beyond the opening sentence. Many clauses could be tightened or separated for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain return values and behavior. It does so exhaustively, defining each result block, counting caveats, refresh logic, and side effects. For a zero-parameter aggregate tool, this is complete enough for an agent to interpret the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics for the description to clarify. Per the scoring baseline for zero-parameter tools, this is a 4. The description appropriately focuses on output semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource: 'Aggregate totals from EchelonGraph's internet-exposure radars.' It also names the radar categories (shadow AI, KEV CVEs, exposed databases, leaked credentials), making the tool's scope clear. However, it does not explicitly differentiate this tool from siblings like cve_exposure or cve_summary, so an agent must infer when this aggregate endpoint is preferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains no when-to-use guidance, no when-not-to-use guidance, and no mention of alternative sibling tools. It reads entirely as output-field documentation rather than invocation guidance. An agent gets no explicit routing signal for choosing this over cve_exposure or search_cves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one CVE: description, NVD CVSS v3/v4, the EchelonGraph multi-source score + confidence, EPSS, CISA-KEV status (including ransomware-campaign use), GitHub GHSA, CWE, and references. Pass a CVE ID like CVE-2023-44487.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | a CVE ID, e.g. CVE-2023-44487 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It discloses what data sources are aggregated (a real behavioral trait: multi-source enrichment with confidence), but is silent on failure behavior for an unknown CVE ID, rate limits, and whether external lookups are cached or live. Read-only nature is only inferable from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and the output inventory, followed by the input instruction. No filler, no restatement of the tool name, and the field list is compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by enumerating the returned data families, which is exactly what an agent needs to judge relevance. For a single-required-parameter lookup tool it is nearly complete; only edge-case behavior for invalid IDs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single cve_id parameter already carries an example ('CVE-2023-44487'), so the baseline is 3. The description's example duplicates the schema's example rather than adding format rules, case handling, or validation behavior beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Full detail for one CVE') and enumerates the exact data families returned (NVD CVSS, EchelonGraph score, EPSS, CISA-KEV, GHSA, CWE, references). The 'full detail for one CVE' framing implicitly contrasts it with the cve_summary sibling, so an agent can pick between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the input form ('Pass a CVE ID like CVE-2023-44487'), which is genuine usage guidance, but never states when to prefer this over cve_summary, search_cves, or cve_exposure. Usage is only implied by the word 'full', leaving the agent to infer the single-lookup scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Returns CVEs with the EchelonGraph multi-source score, severity, CVSS, EPSS, and KEV status.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | sort order (default: published) | |
| limit | No | page size (default 20, max 50) | |
| search | No | free-text search (product, vendor, or keyword, e.g. 'tomcat') | |
| min_cvss | No | minimum CVSS score | |
| severity | No | filter to one severity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does meaningful work: it discloses data provenance (five sources), that each is polled on a schedule (freshness implication), and the shape of the returned records (score, severity, CVSS, EPSS, KEV). It omits pagination behavior, result caps, and any auth/rate-limit notes, which is what keeps it from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, and front-loaded: identity and source scope first, filtering and return fields second. Every clause earns its place by adding information an agent can act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by naming the fields returned (EchelonGraph score, severity, CVSS, EPSS, KEV status), which is exactly what an agent needs. The remaining gap is operational detail — pagination beyond the schema's limit, default sort confirmation, and behavior on empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (sort, limit, search, min_cvss, severity) is already fully documented in the schema. The description restates the filter categories generically without adding syntax, defaults, or format detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 even names the upstream sources (NVD, MITRE-CNA, CISA-KEV, EPSS, GHSA). An agent immediately knows this is the multi-source CVE search endpoint. It does not, however, differentiate itself from siblings like get_cve or cve_summary, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by enumerating available filters (severity, min CVSS, free text, sort), which tells an agent this is the browse/filter tool. But it never states when to prefer it over get_cve (single lookup) or cve_summary (aggregate view), so routing guidance must be inferred from the names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.3cve_exposurecve_summaryexposure_radarget_cvesearch_cvesScored across 5 tools
Each tool has a fairly distinct role: cve_summary gives aggregate counts, search_cves browses/lists, get_cve fetches one CVE's detail, cve_exposure is per-CVE footprint, and exposure_radar is cross-domain aggregate. The main risk is cve_summary vs search_cves, which both surface CVE feed data and could be confused when a user wants counts.
Naming is consistently snake_case but mixes verb_noun (get_cve, search_cves) with bare noun phrases (cve_summary, cve_exposure, exposure_radar). The inconsistency between verb-led and noun-led names means the pattern isn't predictable, though all names are readable and domain-specific.
Five tools is well-scoped for a CVE intelligence and exposure-radar service, covering summary, detail, search, per-CVE exposure, and aggregate radar. Each tool earns its place without redundancy.
The surface covers CVE lookup, search, aggregation, per-CVE exposure, and cross-domain radar totals, which is solid lifecycle coverage for an intelligence feed. There is no explicit way to browse tracked products/KEV lists independently, but search and the radar aggregates largely work around that.
CVE intelligence: exploitation (KEV/EPSS), detection coverage, fixed versions. All tools keyless.
Read-only CVE intelligence, remediation playbooks, and agent setup guides. Not a scanner.
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
CVE search, vulnerability database, EPSS exploit prediction, KEV, IP reputation & threat feed.
