Reference

The connector advertises 18 tools: 10 read-only and 8 write. The read tools are annotated readOnly:true, destructive:false; the eight write tools are honestly annotated readOnly:false, destructive:true. The free-form query path is provably read-only — write and admin Cypher is rejected before it reaches the database — and the write surface lives entirely in dedicated, narrow tools (whisper_agents, the watch_* subscription tools, and the submit_* contribution tools), never in query. The schema and the docs are discovered on demand rather than dumped into the model's context up front.

Read tools (10)

Write tools (8)

Every write tool is honestly annotated readOnly:false, destructive:true. They are narrow, per-action tools (never one fat runtime-discriminated tool), and every write op is audited. The whisper.online control plane is API-key-scoped; the Indenture watch_* / submit_* tools need a real tenant key (anonymous sessions are refused).

identify / assess / walk are also available as gallery workflows (e.g. indicator for a full identify → assess → walk threat read including WHOIS/BGP history) you run via run_workflow — call list_workflows to find them. explain_schema and read_docs are cached server-side, so an agent can call them as often as it needs without paying a quota cost.

The whisper.online control plane, two tiers

• No API key → verify_identity still works (it reads the public keyless gateway), so anyone can answer "is this address a Whisper agent, and who operates it?".
• With your API key → whisper_agents unlocks provision + govern + egress. The key on your MCP session is forwarded to the control plane; every op runs under your own tenant and scopes, and the backend answers cap/argument problems with clear typed errors (BAD_ARGS, AGENT_LIMIT, EGRESS_DISABLED, …).

The query tool

query is the primary tool. Beyond the Cypher string it accepts two presentation controls:

• format — how rows come back:
  • table (default for tabular results) — columns + rows, the classic shape.
  • graph — nodes + edges, for results that return whole paths or subgraphs.
  • compact — a denser encoding for large result sets that minimises token usage.
• Pagination — page (1-based) and pageSize. Pagination is count-first: the first page returns the total row count alongside the slice, so an agent knows how many pages exist before walking them.

Every query response also carries an evidence block and a top-level references object and, where they apply, the self-correction fields (autoLimited, rewritten, fix, truncated) — see Self-correcting queries and Evidence & provenance. The response carries no remaining-quota or plan-budget field: the MCP server applies no plan, rate, or usage limits of its own — read the whisper://quota resource for the graph engine's own caps.

Resources

The schema and the doc/cookbook resources are now discovered on demand through explain_schema and read_docs rather than always listed — that's most of what cut the always-listed surface in half. The lightweight, always-useful descriptors stay available as resources:

The Cypher function reference, the cookbook, and the agent guide are reachable through read_docs (e.g. read_docs for the Cypher functions page, the cookbook, or any docs page) instead of riding along in every connection.

Prompts

The connector ships 12 slash-style prompts for common investigation patterns, one per gallery workflow. A prompt's depth depends on which capability layers are live on the deployment you're connected to — the readyLayers[] field of the whisper://server resource is the authoritative list.

Each prompt is generated from a gallery workflow, so the prompt surface matches the gallery by construction — every prompt wraps a run_workflow call, embeds that workflow's per-step plan, and ends with an evidence directive. Arguments come from the workflow's inputs; the tunable params are listed in the prompt body (call list_workflows for their options and ranges).

Prompts and gallery recipes overlap by design: a prompt is a single-shot, client-triggered template; a gallery recipe (run_workflow) is a server-side, multi-step investigation you run by slug. When in doubt, the gallery is the more capable path — see the Workflow & recipe gallery.

When an agent isn't sure whether the canonical property is h.name or h.fqdn, or whether to anchor on HOSTNAME or DOMAIN, it should call explain_schema before writing the query. With no argument it returns the label catalogue; pass a label and it returns that entity's properties, edges, and a runnable sample traversal. It's cached server-side and returns in milliseconds — cheap to call, and it prevents the most common query bug (writing a defensive MATCH (h) WHERE h:HOSTNAME OR h:DOMAIN OR h:FQDN ... against a billion-node label, which the validator rejects).

A typical introspection-then-query transcript:

User:     What labels does the Whisper graph have?
Agent:    [calls explain_schema]                 (no argument)
          → {labels: [{label: "HOSTNAME", count: 2_631_997_144, scale: "2.6B"},
                      {label: "IPV4", count: 618_914_961, scale: "619M"},
                      ... 37 more], labelCount: 39, edgeCount: 45}
Agent:    The graph has 39 labels. The biggest are HOSTNAME (2.6B), IPV4 (619M), and
          ANNOUNCED_PREFIX (1.4M). What do you want to look at?

User:     Show me the threat properties on a hostname.
Agent:    [calls explain_schema {label: "HOSTNAME"}]
          → {label: "HOSTNAME", exists: true, count: 2_631_997_144, scale: "2.6B",
             properties: [{name: "name", type: "String"},
                          {name: "threatScore", type: "Double"},
                          {name: "threatLevel", type: "String"},
                          {name: "isThreat", type: "Boolean"},
                          {name: "isC2", type: "Boolean"}, ...],
             outboundEdges: [{type: "RESOLVES_TO", to: ["IPV4", "IPV6"], pattern: "(h:HOSTNAME)-[:RESOLVES_TO]->(:IPV4)"},
                             {type: "CHILD_OF", to: ["HOSTNAME", "TLD"]}, ...],
             inboundEdges:  [{type: "NAMESERVER_FOR", from: ["HOSTNAME"]},
                             {type: "MAIL_FOR", from: ["HOSTNAME"]}, ...],
             sampleTraversal: {intent: "...", cypher: 'MATCH (h:HOSTNAME {name: "example.com"}) RETURN h LIMIT 1'}}
Agent:    [calls query]
          MATCH (h:HOSTNAME {name: "evil.example"})
          RETURN h.threatScore, h.threatLevel, h.isThreat, h.isC2,
                 h.isPhishing, h.isMalware

Agents that introspect first write valid queries on the first try; agents that don't tend to fall back to defensive label-or'ed scans that the validator rejects.

The query tool returns a typed error envelope that clients and LLMs can branch on instead of parsing free-text messages.

errorCode is one of:

QUERY_TOO_EXPENSIVE is the size guard, distinct from DB_TIMEOUT's duration guard — a query can be cheap-per-row but still touch too many elements. retryable is read straight off the code, so a client can branch on it without parsing the message.

Migration note: the old catch-all CYPHER_SYNTAX_ERROR was split into SCHEMA_ERROR (bad label / property / column) and SYNTAX_ERROR (malformed Cypher), and LIMIT_ERROR was carved out of VALIDATION_REJECTED for the over-cap-LIMIT case. Clients that branch on CYPHER_SYNTAX_ERROR should migrate to the new codes.

Beyond the dedicated tools, the query tool accepts a set of procedures directly inside Cypher, so you can compose them into a larger query or run them ad hoc:

For a packaged, multi-step version of these, run a gallery recipe with run_workflow; the CALL form is there for composing inside a larger query of your own. whisper.variants() also works in expression position, not only as a top-level CALL — e.g. RETURN size(whisper.variants("paypal.com")) or MATCH (h:HOSTNAME {name: whisper.variants("paypal.com")[0].variant}) RETURN h. explain() and whisper.history() remain CALL-only.

The write/admin arms whisper.submit and whisper.watch are not reachable — the read-only pre-check rejects them (along with any CREATE/MERGE/DELETE/SET/REMOVE/LOAD CSV clause) before a query executes. The whole MCP surface is provably read-only.

The server validates every query before running it. These seven rules keep every query bounded — but most of them are things the server now helps you satisfy rather than hard rejections (see Self-correcting queries below). A query that genuinely can't be auto-corrected comes back as VALIDATION_REJECTED with a suggestion and, where one applies, a machine-applicable fix.

1. shortestPath must be bounded (no unbounded variable-length path inside it). An unbounded [*] returns a BOUND_PATH fix proposing [*1..6].
2. LIMIT must be ≤ 5000. An over-cap LIMIT is auto-clamped to 5000 and the query runs (rewritten: true).
3. No unlabeled MATCH — every MATCH pattern must carry a node label or a {name: …} anchor.
4. No same-variable label disjunction — WHERE n:A OR n:B on one variable is rejected (introspect with explain_schema instead).
5. Indexed text operators (CONTAINS / STARTS WITH / ENDS WITH) are allowed only on the .name property; on any other property the server returns an EXACT_MATCH fix.
6. No unanchored scans on large labels — anchor the MATCH on an indexed value.
7. Exploration queries must include a LIMIT — if you omit one the server auto-injects the default LIMIT and runs the query (autoLimited: true), rather than rejecting it.

A read-only pre-check runs before these seven rules and rejects any write/admin clause or mutating/admin CALL up front.

The validator does more than reject. Where it safely can, it bounds or rewrites the query and runs it anyway, and tells you what it did. A query response can carry these self-correction fields so an agent spends fewer round-trips fixing its own Cypher:

Two classes of correction:

• Bounding rewrites run automatically. They only trim the result to a bounded prefix — same rows, just capped — so they're safe to run without asking. The query succeeds and the response notes autoLimited / rewritten with the applied rewrite. Examples: APPEND_LIMIT (missing LIMIT), CLAMP_LIMIT (over-cap LIMIT).
• Semantic rewrites are returned as a fix, never auto-run. They change which rows match, so the agent decides. Example: an unindexed CONTAINS on a non-.name property comes back with an EXACT_MATCH fix proposing =. Some fixes (ADD_LABEL, PICK_LABEL, ANCHOR_MATCH) carry no rewrittenCypher because they need a value only the agent has — confidence and safeToAutoRetry tell the agent how to treat each one.

So no validator rejection is ever a bare error. It's auto-fixed, auto-bounded, or it carries a fix the agent can read and apply.

A Whisper answer carries its own provenance. Every query and run_workflow result ships an evidence block so an agent can cite the query and the rows behind each claim, rather than asking you to take the verdict on faith.

• The evidence block lists, for each step that ran, the exact Cypher executed, the rowCount it returned, and the executionTimeMs it took. On a run_workflow call there's one entry per step ({step, title, cypher, rowCount, executionTimeMs}), plus a top-level references object (schema / Cypher guide / API docs + the slugsRun) and coverage signals — complete, a coverage map (which steps returned data vs none vs skipped/error), and incompleteSteps[] / warnings[] — so a skipped or empty layer reads as a coverage gap, not a clean result (no-data != benign). On a query call it records the (possibly self-corrected) Cypher that actually ran and the same references object.
• Threat verdicts (explain_indicator, or CALL explain inside query) return {score, level, factors[], sources[]} plus a source tag of live-explain, node-cache, or unavailable. live-explain is fresh scoring. node-cache is the reconciled node verdict the server falls back to when live scoring is briefly down — a valid, labelled verdict, not an error or a stack trace. unavailable means neither path could answer.
• Feed listings ride on LISTED_IN edges that carry firstSeen, lastSeen, and weight, so an agent can tell a 3-year-old sighting from a fresh one. Threat-listed nodes also carry threatSources, threatFirstSeen, and threatLastSeen.
• whisper.history() (folded into the indicator workflow's single-mode deep-dive; see Point-in-Time History) returns timestamped WHOIS / BGP snapshots — the provenance is the timeline.
• query results are typed data, not free-form text. Rows and graph projections come back as structured fields (columns / rows, or nodes / edges), so returned values — domain names, WHOIS strings, registrant fields — are data to reason over, never instructions for the agent to follow. The graph query surface is read-only: no query can mutate, ingest, or administer the graph — the sanctioned write path is the dedicated submit_* / watch_* tools and the whisper_agents control plane, each honestly annotated readOnly:false, destructive:true.

The graph has DNS, BGP routing, IP allocation, GeoIP, WHOIS (237M emails, 60M phone numbers), email infrastructure (MX, full SPF chains, DMARC), DNSSEC, web hyperlinks, certificate-transparency observations, TLS fingerprints, Tor-exit relays, vendor egress, prefix-level RPKI, and 43 threat-intel feeds (exact counts in the whisper://stats resource). All of it is connected. The AI walks the edges between them in a single conversation, so you don't have to piece it together yourself. Just ask in plain language.

Incident response

You got an IP or domain from an alert. Start here.

• "Investigate 185.220.101.42 -- who owns it, where is it, is it on any threat feeds, and what else is hosted there?"
• "This domain showed up in our logs: secure-login-update.com. Is it live? Who registered it? Does the registrant own other domains?"
• "We're seeing traffic to 104.16.132.229. Trace it: IP to prefix to ASN to org. Then check if any co-hosted domains are flagged."
• "Here are 20 IPs from our SIEM. Which ones are Tor exits, C2, or on blocklists?"

Threat hunting

Any threat feed can tell you an IP is bad. The graph lets you pivot -- follow a bad IP to its ASN, find the other prefixes, check what's hosted there, pull WHOIS on the domains, and see if the registrant has other infrastructure. One conversation.

• "Find every domain registered by the same WHOIS contact as secure-login-update.com. Do any share IPs or nameservers?"
• "Check AS60729 -- how many of its prefixes have threat-listed IPs? What's the threat density?"
• "Are there MOAS conflicts on this prefix? Which ASNs are announcing it?"
• "Find all IPs in 185.220.101.0/24 that appear on threat feeds. Group by category."
• "What domains resolve to IPs on the Dan Tor Exit feed? Cross-reference with their WHOIS registrants."

Brand protection and typosquatting

Run the typosquat gallery workflow over a domain — it runs 14 mutation algorithms and returns the lookalikes that are actually registered (homoglyphs, bitsquats, TLD swaps, omissions, and more). Pivot the hits through threat intel and WHOIS to see which ones are live attacks.

• "Run the typosquat sweep for paypal.com."
• "Generate lookalike domains for our brand, then check which ones are on threat feeds or resolve to live IPs."
• "Which registered variants of microsoft.com share a registrant email or nameserver with each other?"
• "Run a typosquat sweep on stripe.com -- who registered the lookalikes and is any of their infrastructure flagged?"

Attack surface

Everything an attacker would look for: subdomains, IPs, mail servers, SPF authorization chains, nameservers, WHOIS.

• "Map tesla.com -- subdomains, IPs, ASNs, nameservers, mail servers, SPF includes, and WHOIS registrant."
• "What third-party services can send email as netflix.com? Walk the full SPF include chain."
• "Find every subdomain of example.com, resolve them, and group by ASN. How many hosting providers?"
• "Where does the CNAME chain for www.example.com end up? Who hosts the final target?"

WHOIS and registrant pivoting

This is where investigations get interesting. WHOIS gives you a registrant email or phone number. The graph has 237M emails and 60M phones, so you can follow that contact to every other domain they registered, then check if those domains share hosting.

• "Find the WHOIS registrant for secure-login-update.com, then every other domain they registered. Do any share infrastructure?"
• "What domains use this contact email? Show their IPs and ASNs, and flag any that are threat-listed."
• "Has google.com changed registrars? Show the history."
• "Find domains registered with the same phone number. Any overlap in hosting?"
• "Compare WHOIS for these five domains -- same registrant? Same email? Same registrar?"

BGP and routing

116K ASNs, 2.5M prefixes, full peering topology.

• "If AS16509 (Amazon) went down, how many prefixes and peers are affected? What domains go dark?"
• "Which ASNs peer with both Cloudflare and Google?"
• "Show the BGP routing history for 8.8.8.0/24. Has the announcing ASN changed?"
• "Find prefixes with MOAS conflicts announced by AS60729. Any of them hosting threat-listed IPs?"
• "What RIR allocated this prefix? Which org registered it?"

Comparing infrastructure

The thing that's hard to do anywhere else: checking whether two domains share anything. Same IPs, same ASN, same nameservers, same registrant email, same phone number. The graph checks all of it at once.

• "Do pandas-crossing.com and afterlifeevents.com share any infrastructure?"
• "These three phishing domains were reported separately. Any shared nameservers, IPs, ASNs, or WHOIS contacts?"
• "Compare the hosting and email setup of these two competing SaaS products."
• "Find domains that share both the same registrant email and the same IP range as this known-bad domain."

Email, SPF, and DMARC

The graph stores the full SPF record structure -- includes, ip4, a, mx, exists, redirect -- as separate edges, plus MX and DMARC. So you can walk the authorization chain rather than parsing TXT records by hand. (DKIM selector/key records are not live on this deployment yet — see layer availability — so questions that depend on DKIM signing return no rows here.)

• "Who can send email as shopify.com? Walk the SPF chain."
• "What domains use the same SPF include targets as this phishing domain?"
• "Does this domain have MX records? SPF? a DMARC policy? Give me the full email setup."
• "Where does this domain send its DMARC aggregate reports?"

GeoIP and data residency

619M IPv4 addresses mapped to cities and countries.

• "Where are all the IPs that example.com resolves to? List by country."
• "Does this company host anything in sanctioned countries? Check all their domain IPs."
• "Find all IPs in this ASN that geolocate to Russia."

Web links

The hyperlink graph between hostnames, from Common Crawl.

• "What external domains does google.com link to? Where are those hosted?"
• "Who links to this suspicious domain? Are any of the linking sites threat-listed?"
• "Do these two domains link to each other?"

DNSSEC

• "Is cloudflare.com signed with DNSSEC? What algorithm?"
• "What percentage of domains under this nameserver use DNSSEC?"

History

WHOIS and BGP changes over time.

• "Show the WHOIS history for google.com -- registrar changes, nameserver updates, ownership."
• "BGP routing history for 8.8.8.8 -- has the announcing ASN or prefix changed?"
• "When was this domain registered? Has it changed hands?"

Host identity and de-cloaking

Whose infrastructure is this, and where does it really live? The host-identity recipes answer identity separately from verdict — a host on AWS isn't malicious just because AWS also hosts malware — and the origin-IP recipe finds the server behind a CDN.

• "Whose infrastructure is github.com and raw.githubusercontent.com? Are either of them dangerous?"
• "Identify these 50 hosts from our logs, then assess each -- which are unknown vs. known-clean vs. suspicious?"
• "What are the candidate true-origin IPs behind www.cloudflare.com? Which can I reach directly, behind the WAF?"
• "No identity match for this host -- walk its neighborhood and show the nearest known vendors and structural siblings."

Egress, fingerprints, and transparency

The newest layers: who really operates a netblock, what an IP's TLS fingerprint reveals, which subdomains certificate transparency has seen, Tor-exit identity, and DMARC posture.

• "Does 185.220.101.1 run a Tor exit relay? Show the relay fingerprints and its anonymizer flags."
• "Who operates the netblock 104.16.0.0/13 -- the egress vendor, not just the WHOIS owner?"
• "Read the TLS fingerprint of this IP and find every other IP that shares it."
• "What hostnames has certificate transparency seen for this domain, including CT-only names that never resolve?"
• "Where does apple.com send its DMARC reports? Show the rua/ruf recipients and the SPF mechanisms."
• "Show signed ROAs for this prefix -- the authorizing ASN, max-length, and trust anchor."

A few prompts are worth a try first.

indicator

Full indicator triage in one pass — feed listings, composite score, level, recency, and hosting context for an IP / hostname / ASN / CIDR.

/indicator 185.220.101.1

This indicator is a Tor exit node listed in several feeds (Dan Tor Exit, Tor Exit Nodes, FireHOL Level 2, IPsum). The prompt returns the feed list, score breakdown, first/last seen across all feeds, and the upstream ASN's reputation — with the Cypher behind each step in the evidence block.

typosquat

Brand-protection sweep — finds registered lookalikes of a domain (the typosquat workflow), enriches each with threat-feed listings, and pivots through WHOIS to identify who registered the suspicious ones.

/typosquat paypal.com

Returns: every registered variant of the domain (with the mutation method and a confidence score), which of those variants are on threat feeds or resolve to live infrastructure, and the WHOIS registrant behind the suspicious ones.

route-health

A network or address block's full routing health card — announced prefixes, peers and upstream transit, MOAS conflicts, RPKI ROA coverage, and the facilities and exchanges it sits in.

/route-health AS13335

For Cloudflare's ASN, the prompt returns the network name, a prefix-inventory sample, the facilities and IXPs it sits in, MOAS detections, country of registration, and how many of the routed IPs appear in threat feeds.

indicator

The same single-mode deep-dive as above, run on a different host to show the grounding contract an agent relies on: a coverage-qualified verdict band, vendor identity when the host is known, and the structural neighbourhood around it — so "no data" is never read as "known clean."

/indicator raw.githubusercontent.com

Returns the host's vendor and host_class, a coverage-qualified clean / suspicious verdict (one bad sub-URL does not condemn a multi-tenant apex), and the nearest known vendors and structural siblings — each step with its Cypher in the evidence block.