What can you do with this server?

WhisperGraph is a read-only MCP server providing access to the world's largest internet infrastructure graph database (46B nodes and edges) covering DNS, IPs, ASNs, BGP, WHOIS, web links, and threat intelligence. Core Tools * Cypher Queries (query): Explore 20+ node types (hostnames, IPs, ASNs, prefixes, orgs, emails, etc.) and dozens of relationship types — DNS resolution, BGP routing, WHOIS ownership, web hyperlinks, GeoIP, and more. * Threat Assessment (explain_indicator): Get a threat score, level (NONE→CRITICAL), factors, and source breakdown for any IPv4, IPv6, hostname, CIDR, or ASN across ~40 feeds in 18 categories (C2, malware, phishing, spam, Tor, proxies, VPNs, scanners, etc.). * Historical Data (whisper_history): Retrieve historical WHOIS snapshots or BGP routing data (origin ASN, prefix announcements, peer visibility) for domains, IPs, prefixes, and ASNs. * Typosquat & Brand Protection (domain_variants): Generate and check up to 14 classes of domain mutations (omissions, transpositions, homoglyphs, TLD-swap, Unicode confusables, etc.) against the live graph. * Schema Exploration (list_labels, describe_label): List all node labels with counts and inspect their properties before writing queries. Resources & Workflows * MCP resources include the full schema, relationship map, Cypher function reference, query cookbook, and live stats/quota. * 8 pre-built prompt templates cover workflows like investigate-ip, map-attack-surface, compare-domains, blast-radius, threat-triage, whois-pivot, bgp-investigation, and typosquat-sweep. * Supports DNS chain analysis, ASN/BGP history, WHOIS pivoting, email infrastructure mapping (SPF/DKIM/DNSSEC), web hyperlink graph analysis (10.9B links), and attack surface/incident response attribution.

WhisperGraph

Official

by whisper-sec

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

WhisperGraph is an MCP server backed by the world's largest internet-infrastructure graph database - 46 billion nodes and edges across 20 entity types, mapping every domain, IP, ASN, prefix, organization, Web link and threat-intelligence listing into a single Cypher-queryable graph. Used by security teams, incident responders, and AI agents for investigation, attribution, brand protection, and infrastructure forensics.

Built for agents from day one.

Programmatic signup in 2 HTTP calls. No browser, no CAPTCHA, no human-in-the-loop. Email verification only. Working API key in ~5 seconds.
Free trial for everyone, including agents. Paid tiers for higher quotas.

What you can ask:

DNS: resolution, nameservers, MX, SPF chains, DNSSEC
Routing: ASN ownership, BGP origin history, MOAS conflicts, peering
Hosting & ownership: registrar, WHOIS contacts, organization mapping
Threat intel: ~40 feeds across 18 categories, CALL explain() for full threat scoring
Historical: WHOIS history, BGP route changes
Web: 10.9B hyperlinks for inter-domain analysis

Learn more: Agent signup · WhisperGraph intro · Cypher API reference · Query guide · Cypher syntax · Functions · Best practices · MCP setup

Quick start

You need a WhisperGraph API key. Get one either:

Programmatically (recommended for agents) - see Agent quickstart below.
Via the dashboard (recommended for humans) - console.whisper.security/sign-up.

Hosted remote server (no install)

Whisper runs a hosted MCP server at https://mcp.whisper.security. Point any MCP client that supports remote servers at it and authenticate with your API key:

{
  "mcpServers": {
    "whisper": {
      "url": "https://mcp.whisper.security",
      "headers": { "Authorization": "Bearer <your_api_key>" }
    }
  }
}

MCP clients (stdio)

For local stdio transport, add this to your MCP client config:

{
  "mcpServers": {
    "whisper-graph": {
      "command": "npx",
      "args": ["-y", "@whisper-security/whisper-graph-mcp"],
      "env": { "WHISPER_API_KEY": "your-api-key" }
    }
  }
}

Self-hosting this repo is for teams who want to run the MCP layer in their own environment. See How to set up.

Related MCP server: Lookup-Domain

Agent quickstart

Get a working API key in two HTTP calls - no browser, no CAPTCHA, no waiting list.

Step 1 - start signup (Whisper emails a verification code):

POST https://console.whisper.security/api/signup
Content-Type: application/json

{"email":"your-agent@example.com","attribution":{"agent_name":"your-agent","source":"<registry-name>"}}

Step 2 - verify with the emailed code:

POST https://console.whisper.security/api/signup/verify
Content-Type: application/json

{"signup_id":"...","code":"..."}

The response contains api_key, mcp_url, dashboard_url, and docs_url. Use api_key in the MCP config snippet above. Full docs: whisper.security/docs/agent-signup.

Tools

All eight tools are read-only.

Tool	What it does
`query`	Execute a Cypher query against WhisperGraph. Validated against a safety rule set before it reaches the backend.
`list_labels`	List every node label with counts. Call it before writing a query when you're unsure which label to anchor on.
`describe_label`	Confirm a label exists and enumerate its property keys.
`explain_indicator`	Threat assessment for an IP, hostname, CIDR, or ASN - score, level, factors, sources.
`whisper_history`	Historical WHOIS or BGP data for an indicator.
`domain_variants`	Typosquatting / brand-protection variants of a domain, checked against the graph.
`list_recipes`	List the full whisper.security catalog of ready-made recipes (see below).
`run_recipe`	Run any catalog recipe by slug - a keyless direct procedure or a keyed multi-step flow.

Catalog recipes

list_recipes + run_recipe expose the entire whisper.security catalog - 29 curated recipes, no hand-written Cypher required. The vendored catalog (src/catalog/recipes.json) is generated from the canonical source with npm run sync:catalog, so it tracks the platform.

Two kinds:

Direct recipes (keyless). A single graph procedure that runs without a key (rate-limited): assess (threat posture), identify (vendor/operator), explain, variants, origins (CDN de-cloak), history / history-whois, walk, psl-tldplusone, psl-affiliation, asset, lookup-tor-relay, db-schema.
Flow recipes (keyed). Curated multi-step investigations that need an API key: attack-path, attack-surface, indicator-enrichment, infrastructure-mapping, subdomain-takeover, bgp-hijack-exposure, blast-radius, route-health, typosquat, nameserver-hijack-dns-consistency, map-supply-chain-concentration, discover-ai-agent-infrastructure, build-takedown-evidence-package, indicator, anycast-dns-root-sovereignty.

// keyless direct recipe
{ "name": "run_recipe", "arguments": { "recipe": "assess", "inputs": { "v": "185.220.101.33" } } }

// keyed multi-step flow (needs WHISPER_API_KEY / X-API-Key)
{ "name": "run_recipe", "arguments": { "recipe": "indicator-enrichment", "inputs": { "value": "github.com" } } }

Each recipe carries a docsUrl (visible in list_recipes) linking to its page under whisper.security/docs.

Resources

Six MCP resources: the full schema, the relationship map, a Cypher function reference, a query cookbook, plus live whisper://stats and whisper://quota.

Prompts

Eight investigation-workflow prompt templates: investigate-ip, map-attack-surface, compare-domains, blast-radius, threat-triage, whois-pivot, bgp-investigation, typosquat-sweep.

Self-hosting (Docker / HTTP)

For remote or team deployments, run the server over Streamable HTTP:

docker run -p 8080:8080 -e MCP_TRANSPORT=http \
  ghcr.io/whisper-sec/whisper-graph-mcp:latest

Or with Docker Compose:

docker compose up

In HTTP mode the server does not authenticate inbound requests - it relays the caller's X-API-Key or Authorization: Bearer header to the hosted WhisperGraph API, falling back to the WHISPER_API_KEY environment variable when no header is present. Put it behind your own gateway if you need access control.

Configuration

All configuration is via environment variables.

Variable	Default	Description
`WHISPER_API_KEY`	(none)	Your WhisperGraph API key. Get one programmatically in 2 HTTP calls or via the dashboard.
`MCP_TRANSPORT`	`stdio`	`stdio` for local CLI use, `http` for remote/Docker.
`HTTP_HOST`	`0.0.0.0`	Bind host for the HTTP transport.
`HTTP_PORT`	`8080`	Bind port for the HTTP transport.
`WHISPER_ALLOWED_HOSTS`	(none)	Comma-separated `Host` header allowlist for DNS-rebinding protection in HTTP mode. Leave empty only behind a trusted gateway.
`WHISPER_DB_URL`	`https://graph.whisper.security`	Base URL of the hosted WhisperGraph API.
`WHISPER_QUERY_TIMEOUT_MS`	`60000`	Hard per-query deadline forwarded to the API.
`WHISPER_DB_TIMEOUT_MS`	`10000`	HTTP timeout for non-query calls.
`LOG_LEVEL`	`info`	`debug`, `info`, `warn`, or `error`.

Development

npm install
npm run dev       # run from source over stdio
npm test          # unit + integration tests (no secrets needed)
npm run build     # bundle to dist/
npm run lint      # eslint
npm run typecheck # tsc --noEmit

Contributing

Contributions are welcome. See CONTRIBUTING.md and our Code of Conduct. Security issues: see SECURITY.md.

License

Apache-2.0. "Whisper", the Whisper logo, and "WhisperGraph" are trademarks of Whisper Security - see NOTICE.

Available Tools

8 tools

describe_labelDescribe WhisperGraph LabelA

Read-onlyIdempotent

Inspect

Describe a single label: confirm it exists, get its node count, and enumerate the property keys observed on that label.

Use this BEFORE writing a query that filters on a specific property. If you write WHERE h.fqdn = "..." but describe_label("HOSTNAME") returns properties = ["name", "threatScore", ...], your query will silently scan the entire label. Verify first.

Argument: label (string, required) - uppercase letters, digits, and underscores only.

Returns: {name, exists, count, properties[], edgesDoc}. Cached 5 minutes.

Tip: edge types are NOT in the response - see the whisper://schema/relationships resource for which edges connect this label to others.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes	Label name. Uppercase letters, digits, underscores. Examples: HOSTNAME, IPV4, ASN.

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`count`	No
`error`	No
`exists`	Yes
`edgesDoc`	No
`properties`	No
`suggestion`	No
`propertiesError`	No

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses caching behavior ('Cached 5 minutes') and limitations ('edge types are NOT in the response'). This adds significant context for an agent to understand freshness and completeness.

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 concise (around 150 words), well-structured with clear sections, and every sentence adds value. The tip at the end is a useful, non-redundant addition.

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 and the presence of an output schema, the description covers all necessary aspects: what it does, when to use, caching, limitations, and parameter constraints. It feels complete for an agent to invoke correctly.

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%, with the input schema already describing the label format (uppercase, digits, underscores, examples). The description repeats this but adds no new meaning, meeting the baseline for high coverage.

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 clearly states the tool's purpose: 'Describe a single label: confirm it exists, get its node count, and enumerate the property keys observed on that label.' This specific verb-resource combination distinguishes it from siblings like list_labels, which lists labels without details.

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 description explicitly advises using this tool 'BEFORE writing a query that filters on a specific property' and warns against silent scans if properties are not verified. It also points to the schema resource for edge types, providing clear guidance on when and how to use the tool.

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

domain_variantsTyposquat / Brand-Protection VariantsA

Read-onlyIdempotent

Inspect

Generate typosquatting / brand-protection variants of a domain or brand name and check which ones actually exist in WhisperGraph.

Runs 14 mutation algorithms - character omission, repetition, transposition, QWERTY-adjacent replacement/insertion, vowel-swap, bitsquatting, homoglyph / Unicode confusables, hyphenation, dot insertion/omission, TLD-swap, TLD-addition, and subdomain-add. Unicode input is accepted (and expected) so IDN homoglyph lookalikes resolve correctly.

Returns { rows: [...] }. Each row: { variant, method, exists, nodeId, label, confidence (0.3-0.9), confidenceLabel (low/medium/high) }. By default only variants that EXIST as nodes are returned - the registered lookalikes worth investigating. Note that "exists" means registered/observed, NOT malicious: pivot each hit through explain_indicator for a threat verdict.

Arguments:

name (string, required) - the domain or brand to mutate, e.g. "google.com". Allowed characters: letters (including Unicode), digits, '.', '-', '_'.
label (string, optional, default HOSTNAME) - node label to check existence against.
includeNonExistent (boolean, optional, default false) - when true, also return generated variants that do NOT exist in the graph (larger, noisier result set).

Performance: typically <150ms. Results are capped at 500 rows.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Domain or brand to generate variants for. Examples: "google.com", "paypal.com". Unicode allowed.
`label`	No	Optional node label to check existence against. Default: HOSTNAME.
`includeNonExistent`	No	Optional. When true, also return generated variants that do not exist in the graph. Default: false.

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Adds value beyond annotations: performance timings, result caps, default behavior (existent-only), and clarifies that 'exists' does not imply malicious intent. No contradiction with annotations.

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?

Well-structured and informative, but slightly verbose with algorithm list. Could be more concise without losing essential details.

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 complexity (14 algorithms), the description covers purpose, algorithms, output schema, parameters, performance, and sibling tool recommendation. Very complete.

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 covers all parameters fully (100%). Description adds allowed characters, default values, and behavioral implications (e.g., includeNonExistent noisiness), enhancing beyond 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 clearly states the tool generates typosquatting/brand-protection variants and checks existence, distinguishing it from siblings like query or explain_indicator.

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?

Provides explicit context for use (brand-protection, threat investigation) and suggests pivoting to explain_indicator, but lacks explicit when-not-to-use or comparison to alternative tools.

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

explain_indicatorThreat Assessment for an IndicatorA

Read-onlyIdempotent

Inspect

Run a comprehensive threat assessment on a single indicator. The indicator can be an IPv4, IPv6, hostname, CIDR network, or ASN - the procedure auto-detects the type.

Returns a single structured row: { indicator, type, available, cached, found, score, level (NONE/INFO/LOW/MEDIUM/HIGH/CRITICAL), explanation, factors[], sources[] }. For ASN inputs the row also includes a breakdown object with composite sub-scores (threatDensityScore, graphMetricsScore, historicalScore, prefixAgeScore). For CIDR inputs the explanation field carries threat-density stats (listed IPs, density %).

Prefer this tool over manual ASN→PREFIX→IP→LISTED_IN walks - those time out on large ASNs (AWS, GCP, Azure, Cloudflare). Performance: 3-25ms for IP/domain/network, up to ~80ms for ASN.

Argument: indicator (string, required). Allowed characters: letters, digits, '.', '-', ':', '/', '_'. Cypher-special characters are rejected.

ParametersJSON Schema

Name	Required	Description	Default
`indicator`	Yes	IPv4 / IPv6 / hostname / CIDR / ASN. Examples: "185.220.101.1", "google.com", "3.64.0.0/12", "AS13335".

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Description discloses auto-detection of indicator type, output structure including conditional fields for ASN and CIDR, and allowed character constraints. This adds significant detail beyond annotations (readOnly, idempotent, non-destructive). No contradiction.

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?

Description is well-organized with clear sections: purpose, output format, special cases, usage advice, performance, and argument details. No superfluous sentences.

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 complexity (handles multiple indicator types, conditional output), the description covers all relevant aspects: purpose, input, output, edge cases, and performance. Output schema exists, so return values are adequately described.

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?

While the input schema provides examples, the description adds auto-detection of type and allowed characters, which are not present in schema. Schema coverage is 100%, so description enhances but is not essential.

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 clearly states the tool's function: 'Run a comprehensive threat assessment on a single indicator.' It specifies acceptable indicator types and auto-detection. It differentiates from siblings by focusing on threat assessment for indicators, contrasting with other tools like 'describe_label'.

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?

The description advises to prefer this tool over manual ASN-to-IP walks, and provides performance timings. It implies when to use (threat assessment on indicators) but lacks explicit when-not-to-use or direct sibling comparisons.

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

list_labelsList WhisperGraph LabelsA

Read-onlyIdempotent

Inspect

List all node labels in WhisperGraph with their counts.

Use this BEFORE writing a query when you're not sure which label to anchor on. It rules out hallucinated labels (e.g. there is no DOMAIN or FQDN - only HOSTNAME) and tells you which labels are large (HOSTNAME, IPV4) vs small (RIR, COUNTRY).

Returns: an array of {label, count} rows. Cached server-side for 5 minutes.

Tip: pair with describe_label to verify which properties exist on a label before referencing them in WHERE clauses.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`labels`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations provide readOnlyHint, destructiveHint=false. Description adds beyond that: confirms caching for 5 minutes, output format as array of {label, count} rows. No contradictions.

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?

Three compact sentences: what, when, output+tip. Front-loaded with purpose. Every sentence adds value. No redundancy.

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?

No parameters, output schema exists. Description covers return format, caching, and usage tip. Fully informative for the tool's complexity.

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?

No parameters; baseline 4 applies. Description doesn't need to add parameter detail since none exist. Schema coverage is 100% irrelevant here.

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 states 'List all node labels in WhisperGraph with their counts' - a specific verb+resource+scope. It distinguishes from sibling tools by explaining its use case: 'Use this BEFORE writing a query when you're not sure which label to anchor on.'

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 advises when to use: before writing a query when unsure of label. It explains benefits: avoids hallucinated labels, reveals label sizes. Tips to pair with describe_label provides context. Doesn't explicitly state when not to use, but guidance is clear.

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

list_recipesList WhisperGraph Catalog RecipesA

Read-onlyIdempotent

Inspect

List the whisper.security catalog of ready-made recipes - the full set exposed by this server. Two kinds:

direct recipes (keyless) are a single graph procedure: whisper.assess (threat posture), whisper.identify (vendor/operator), whisper.explain, whisper.variants (typosquats), whisper.origins (CDN de-cloak), whisper.history / whisper.history.whois (WHOIS timeline), whisper.walk, whisper.psl.*, whisper.asSet, whisper.lookupTorRelay, db.schema. These run WITHOUT an API key (rate-limited).
flow recipes (keyed) are curated multi-step investigations: attack-path, attack-surface, indicator-enrichment, infrastructure-mapping, subdomain-takeover, bgp-hijack-exposure, blast-radius, route-health, typosquat, nameserver-hijack-dns-consistency, map-supply-chain-concentration, discover-ai-agent-infrastructure, build-takedown-evidence-package, indicator, anycast-dns-root-sovereignty. These need a WhisperGraph API key.

Each entry returns { slug, title, purpose, category, mode, access, requiresKey, inputs[], params[], columns[], docsUrl }. Run any of them with run_recipe(recipe=, ...). Optional filters:

mode ("direct" | "flow")
access ("keyless" | "keyed")

The catalog is generated from the canonical whisper.security catalog, so this list stays in sync with what the platform ships.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Filter to only direct or only flow recipes.
`access`	No	Filter to keyless (no API key) or keyed (API key required) recipes.

Output Schema

ParametersJSON Schema

Name	Required	Description
`recipes`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: it's a listing operation, non-destructive, and mentions rate limits for keyless recipes. No contradictions.

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 description is well-structured with clear sections (two kinds, filters, usage). While slightly lengthy, every sentence provides value, and it's front-loaded with the core purpose.

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 complexity (two recipe types, filters, linking to run_recipe), the description is comprehensive. Output schema exists, so return values are not needed. Covers all necessary context.

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% with descriptions and enums for both parameters. The description adds meaning by linking mode and access filters to the two recipe categories (direct/flow, keyless/keyed), enhancing understanding 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 clearly states the tool lists recipes from the WhisperGraph catalog, distinguishes between 'direct' and 'flow' recipes, and uses specific verbs. It differentiates from sibling tools like run_recipe.

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?

Provides explicit context for when to use this tool (e.g., to list available recipes) and mentions optional filters. It indirectly points to run_recipe for execution, offering some guidance on alternatives.

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

queryWhisperGraph Cypher QueryA

Read-onlyIdempotent

Inspect

Execute a Cypher query against WhisperGraph - the internet's largest infrastructure graph database (7.39B nodes, 39B edges, 5.6M threat intel edges). Returns JSON with columns, rows, and statistics.

Use this tool for any question involving domains, hostnames, IPs, DNS, BGP, GeoIP, web links, email infrastructure, WHOIS, DNSSEC, or threat intelligence.

NODE LABELS (20): HOSTNAME (2.6B), IPV4 (619M), IPV6 (820K), PREFIX (2.5M), ASN (116K), ASN_NAME (108K), ORGANIZATION (119M), CITY (54K), TLD (1.7K), COUNTRY (424), RIR (5), DNSSEC_ALGORITHM (8), TLD_OPERATOR (737), REGISTRAR (51K), EMAIL (237M), PHONE (60M), REGISTERED_PREFIX (326K, virtual), ANNOUNCED_PREFIX (1.4M, virtual), FEED_SOURCE (40, virtual), CATEGORY (18, virtual). All nodes have a "name" property. Threat-listed IPV4/IPV6/HOSTNAME nodes also carry: threatScore (Double), threatLevel (NONE/INFO/LOW/MEDIUM/HIGH/CRITICAL), threatSources, threatFirstSeen/threatLastSeen (epoch ms), and 13 boolean flags: isThreat, isAnonymizer, isC2, isMalware, isPhishing, isSpam, isBruteforce, isScanner, isBlacklist, isTor, isProxy, isVpn, isWhitelist. ANNOUNCED_PREFIX adds BGP-enrichment: isMoas, isAnycast, isWithdrawn, wasMoas, hasOriginChanged, threatScore, threatLevel, threatSourceCount, firstSeen, lastSeen. LISTED_IN edges carry firstSeen, lastSeen, weight.

KEY EDGES: RESOLVES_TO (HOSTNAME→IPV4/IPV6, forward only), CHILD_OF (child→parent: HOSTNAME→HOSTNAME→TLD), ALIAS_OF (CNAME), NAMESERVER_FOR / MAIL_FOR (NS/MX → domain - to list a domain's MX use (domain)<-[:MAIL_FOR]-(mx)), SPF_INCLUDE/SPF_IP/SPF_A/SPF_MX/SPF_EXISTS/SPF_REDIRECT (SPF policy; SPF_IP targets IPV4|IPV6|PREFIX), LINKS_TO (web hyperlinks, 10.8B), BELONGS_TO (3 semantics: IPV4/IPV6→PREFIX, PREFIX→RIR, FEED_SOURCE→CATEGORY), LOCATED_IN (IPV4/IPV6→CITY only - for country, chain through HAS_COUNTRY), HAS_COUNTRY (ASN/CITY/IPV4/HOSTNAME/PHONE/ANNOUNCED_PREFIX/REGISTERED_PREFIX→COUNTRY), ANNOUNCED_BY (IPV4/IPV6→ANNOUNCED_PREFIX, then ROUTES→ASN), ROUTES (ASN/ANNOUNCED_PREFIX→PREFIX/ASN, virtual), PEERS_WITH (ASN↔ASN, bidirectional, virtual), HAS_NAME (ASN→ASN_NAME, virtual; asn.name is the AS number - the network name lives on the ASN_NAME node), REGISTERED_BY (HOSTNAME/ASN/PREFIX→ORGANIZATION), HAS_REGISTRAR / PREV_REGISTRAR / HAS_EMAIL / HAS_PHONE (WHOIS), LISTED_IN (indicator→feed; threat intel for IPV4/IPV6/HOSTNAME), CONFLICTS_WITH (PREFIX/ANNOUNCED_PREFIX↔ASN, MOAS, bidirectional), OPERATES (TLD_OPERATOR→TLD).

TRAVERSAL CHAINS: DNS: HOSTNAME→RESOLVES_TO→IPV4→BELONGS_TO→PREFIX←ROUTES←ASN→HAS_NAME→ASN_NAME BGP-direct: IPV4→ANNOUNCED_BY→ANNOUNCED_PREFIX→ROUTES→ASN GeoIP: HOSTNAME→RESOLVES_TO→IPV4→LOCATED_IN→CITY→HAS_COUNTRY→COUNTRY WHOIS: HOSTNAME→HAS_REGISTRAR→REGISTRAR, HOSTNAME→HAS_EMAIL→EMAIL Threat: IPV4/HOSTNAME→LISTED_IN→FEED_SOURCE→BELONGS_TO→CATEGORY

RULES:

Use {name: "value"} or WHERE n.name = "value" for lookups - both indexed
Always include LIMIT on exploration queries (max 500)
shortestPath requires bounded depth: [*1..6]
Never scan FEED_SOURCE or CATEGORY directly - access via LISTED_IN from anchored nodes
STARTS WITH, ENDS WITH ".x", CONTAINS on .name are all indexed and fast
SIGNED_WITH currently returns 0 rows on live data (DNSSEC layer empty)

PROCEDURES: CALL explain("indicator") for threat assessment, CALL whisper.history("indicator") for historical WHOIS/BGP data, CALL whisper.variants("name") for typosquatting / brand-protection variant generation, CALL whisper.quota() for rate limits, CALL db.labels() / db.relationshipTypes() / db.schema("json") for schema introspection.

EXAMPLES: MATCH (h:HOSTNAME {name: "www.google.com"})-[:RESOLVES_TO]->(ip:IPV4) RETURN h.name, ip.name MATCH (ip:IPV4 {name: "8.8.8.8"})<-[:RESOLVES_TO]-(h:HOSTNAME) RETURN h.name LIMIT 20 MATCH (h:HOSTNAME {name: "google.com"})-[:RESOLVES_TO]->(ip:IPV4)-[:LOCATED_IN]->(c:CITY) RETURN ip.name, c.name MATCH (a:ASN {name: "AS15169"})-[:HAS_NAME]->(n:ASN_NAME) RETURN n.name MATCH (h:HOSTNAME) WHERE h.name ENDS WITH ".google.com" RETURN h.name LIMIT 20 MATCH (ip:IPV4 {name: "185.220.101.1"})-[:LISTED_IN]->(f:FEED_SOURCE) RETURN f.name, ip.threatScore

DOCUMENTATION: API reference: https://www.whisper.security/docs/cypher-api-reference Cypher query guide: https://www.whisper.security/docs/cypher-query-guide Cypher functions: https://www.whisper.security/docs/cypher-functions

ParametersJSON Schema

Name	Required	Description	Default
`cypher`	Yes	Cypher query string. Must include LIMIT for exploration queries. Use {name: "value"} property syntax for lookups.

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes
`error`	No
`columns`	Yes
`success`	Yes
`errorCode`	No
`retryable`	No
`statistics`	No
`suggestion`	No

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already indicate read-only (readOnlyHint=true, destructiveHint=false). The description adds rich behavioral context: graph schema, node/edge details, traversal patterns, query rules, example queries, and caveats (e.g., SIGNED_WITH returns 0 rows). This far exceeds what annotations alone provide.

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 description is lengthy but well-structured with clear sections (NODE LABELS, KEY EDGES, etc.) and front-loaded purpose. Every part earns its place given the tool's complexity, though some details (e.g., full documentation URLs) could be slightly trimmed without loss.

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 complexity (7.39B nodes, 39B edges, numerous node/edge types), the description is comprehensive. It covers node labels, edges, traversal chains, rules, procedures, examples, and documentation links. Output format is described as 'JSON with columns, rows, and statistics', which is sufficient for a Cypher query tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single 'cypher' parameter benefits from an immensely detailed description that explains the graph structure, supported patterns, and constraints. The schema's brief description is supplemented by the full tool description, enabling the agent to construct correct queries.

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 explicitly states 'Execute a Cypher query against WhisperGraph' and provides a comprehensive scope (domains, IPs, DNS, etc.). It clearly distinguishes this general query tool from sibling tools like 'explain_indicator' and 'whisper_history' by listing specific use cases.

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?

The description gives extensive guidance on when to use the tool (any question involving the listed domains) and includes query rules (LIMIT, indexed properties, avoid direct FEED_SOURCE scans) and traversal chains. However, it does not explicitly contrast with sibling tools, leaving the agent to infer when to use alternatives.

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

run_recipeRun a WhisperGraph Catalog RecipeA

Read-onlyIdempotent

Inspect

Run a named whisper.security catalog recipe by its slug (see list_recipes for the full set). This is the highest-leverage tool for infrastructure & threat questions: instead of hand-writing Cypher, run the curated recipe.

Arguments:

recipe (string, required) - the recipe slug, e.g. "assess", "identify", "indicator-enrichment", "infrastructure-mapping", "attack-path", "subdomain-takeover", "typosquat", "bgp-hijack-exposure".
inputs (object, optional) - the recipe's inputs keyed by name (see the recipe's inputs[] in list_recipes). Examples: {"v":"8.8.8.8"} for assess/identify; {"value":"github.com"} for indicator-enrichment / infrastructure-mapping; {"domain":"paypal.com"} for typosquat; {"country":"BR"} for anycast-dns-root-sovereignty; {"value":"paypal.com","other":"paypa1.com"} for attack-path. Omit to use the recipe's built-in example.
params (object, optional) - flow tuning params, e.g. {"level":"deep"} for attack-surface / infrastructure-mapping / attack-path, {"depth":3} for blast-radius, {"instanceType":"Global"} for anycast-dns-root-sovereignty.

Behaviour:

direct recipes run keyless and return { success, recipe, mode:"direct", columns[], rows[], statistics }.
flow recipes need an API key (WHISPER_API_KEY over stdio, or the relayed X-API-Key / Authorization header over HTTP) and return { success, recipe, mode:"flow", steps[], totalLatencyMs } where each step carries { id, title, columns, rows }.
On an unknown slug or a keyless call to a keyed flow, returns { success:false, error, suggestion } - never throws.

Prefer run_recipe over hand-written Cypher whenever a recipe fits the question; fall back to the query tool for bespoke traversals.

ParametersJSON Schema

Name	Required	Description
`inputs`	No	The recipe's inputs keyed by name, e.g. {"v":"8.8.8.8"} or {"value":"github.com"}.
`params`	No	Optional flow tuning params, e.g. {"level":"deep"} or {"depth":3}.
`recipe`	Yes	Recipe slug from list_recipes, e.g. "assess", "indicator-enrichment", "attack-path".

Output Schema

ParametersJSON Schema

Name	Required	Description
`mode`	No
`rows`	No
`error`	No
`steps`	No
`recipe`	No
`columns`	No
`success`	Yes
`statistics`	No
`suggestion`	No
`totalLatencyMs`	No

TDQS

A4.9/5.0

Behavior5/5

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

Details direct vs flow recipe behavior, error handling, and output format. Annotations (readOnlyHint, etc.) are consistent and the description adds significant context beyond them.

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?

Well-structured with clear sections (arguments, behaviour). A bit verbose in places but every sentence adds value; could be slightly tighter but no wasted words.

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 complexity (3 params, nested objects, output schema), the description covers all necessary aspects: argument details, behavior modes, error handling, and usage advice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds concrete examples for each parameter (e.g., inputs, params) and explains the distinction between them, greatly aiding usage.

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 clearly states 'Run a named whisper.security catalog recipe by its slug' and contrasts with hand-writing Cypher and using the query tool, distinguishing it from siblings like 'query'.

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?

Explicit guidance: 'Prefer run_recipe over hand-written Cypher whenever a recipe fits the question; fall back to the query tool for bespoke traversals.' Also notes key requirements for flow recipes.

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

whisper_historyHistorical WHOIS / BGP for an IndicatorA

Read-onlyIdempotent

Inspect

Retrieve historical WHOIS or BGP data for a single indicator. The indicator can be an IPv4, IPv6, hostname, CIDR, or ASN - the procedure auto-detects the type.

Returns shape varies by indicator type:

IP / prefix (type=routing): { origin, prefix, startTime, endTime, peersSeing }
Domain (type=domain): WHOIS snapshots - { queryTime, createDate, updateDate, expiryDate, registrar, nameServers }
ASN (type=asn): prefix announcement history (slow, ~9s for large ASNs)

On upstream failure (the data source is rate-limiting or temporarily down), the row shape is: { available: false, error: "timeout" | ..., retryAfter: }. Surface the retryAfter to the user - DO NOT loop on retry.

Argument: indicator (string, required). Allowed characters: letters, digits, '.', '-', ':', '/', '_'.

ParametersJSON Schema

Name	Required	Description	Default
`indicator`	Yes	IPv4 / IPv6 / hostname / CIDR / ASN. Examples: "8.8.8.8", "google.com", "8.8.8.0/24", "AS15169".

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Description goes beyond annotations by detailing return shapes per indicator type, upstream failure behavior (available: false, retryAfter), and explicitly instructing not to loop on retry. No contradictions with annotations.

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-organized into logical sections (indicator types, return shapes, failure mode) with no wasted words. It is front-loaded with the core action and then expands with necessary detail.

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 complexity (multiple indicator types, varying return shapes, performance caveats, failure handling), the description covers all essential aspects. Output schema exists, so return values are documented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds extra meaning by giving examples, allowed characters, and explaining auto-detection. This compensates for any missing schema detail.

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 clearly states it retrieves historical WHOIS or BGP data for a single indicator, specifying auto-detection of indicator types (IPv4, IPv6, hostname, CIDR, ASN). This distinguishes it from sibling tools like explain_indicator or query.

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?

The description provides usage context (e.g., ASN queries are slow) and examples of allowed indicators. However, it does not explicitly state when to use this tool vs alternatives, nor does it provide when-not-to-use guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.2.0Jul 21, 2026
- Addedlist_recipes
- Addedquery
2 tool updatesv0.2.0Jul 21, 2026
- Removedquery
- Addedrun_recipe
6 tool updatesv0.1.0May 15, 2026
- First observeddescribe_label
- First observeddomain_variants
- First observedexplain_indicator
- First observedlist_labels
- First observedquery
- First observedwhisper_history

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Scored 2026-07-21 13:51 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: schema inspection, typosquatting, threat assessment, label listing, recipe listing, general querying, recipe execution, and historical data retrieval. No overlap or ambiguity.

Naming Consistency3/5

Most tools use a verb_noun pattern (describe_label, list_labels, run_recipe), but domain_variants and whisper_history start with nouns, breaking consistency. Overall pattern is still readable but not uniform.

Tool Count5/5

8 tools is well-scoped for a graph intelligence server, covering essential operations without bloat or deficiency.

Completeness5/5

The tool set covers schema exploration, query execution, domain-specific analysis (typosquatting, threat assessment, historical data), and curated recipe execution. No obvious gaps for the stated purpose of infrastructure and threat intelligence analysis.

Maintenance

ActivitySlowing

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

VerifyMCP A
io.verifymcp
Independent trust scores, tool surfaces and change history for MCP servers.
Developer Tools
91
Meeba Brain A
io.github.meemoprasad
Repository knowledge graph MCP server for codebase understanding and debugging.
Code Analysis Developer Tools
51
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Developer Tools Blockchain Security
1
Wafergraph MCP A
com.wafergraph
Read-only MCP server for wafergraph.com's semiconductor & AI supply-chain data: 30 tools, no auth.
Research & Data AI & Machine Learning Open Data
302

Related MCP Servers

MCP DNS
Search Developer Tools
glucn
A
license
B
quality
D
maintenance
A Model Context Protocol tool that provides DNS querying capabilities for various record types (A, AAAA, MX, TXT, CNAME, NS, etc.) through a standardized MCP interface.
Updated a year ago (2025-06-08 22:45 UTC)
1
MIT
Lookup-Domain
Entertainment & Media
xiaobenyang-com
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server that provides comprehensive domain name research tools, including RDAP, WHOIS, and DNS query functionality.
Updated 8 months ago (2026-01-09 07:06 UTC)
1
2
Apache 2.0
Threat Intel MCP Server
Penetration Testing Security
iceage2114
F
license
Not graded
quality
D
maintenance
Provides threat intelligence and vulnerability research tools by integrating with NVD, VirusTotal, AbuseIPDB, Shodan, and MITRE ATT\&CK. It enables users to perform CVE lookups, analyze IP reputation, and retrieve detailed MITRE ATT\&CK technique information.
Updated 5 months ago (2026-04-14 20:24 UTC)
1
-
PeerGlass
Search Monitoring
duksh
A
license
A
quality
C
maintenance
Provides global internet resource intelligence by querying RIRs for IP and ASN data, routing visibility, and network health. It enables users to perform RPKI validation, BGP inspection, and historical allocation analysis through natural language or a REST API.
Updated 6 months ago (2026-03-18 08:32 UTC)
42
1
MIT