Procedure Reference

The complete calling contract for every stored procedure the engine registers. Each entry gives the argument the procedure takes and the YIELD columns it emits, in the order the engine emits them, so you can write the YIELD clause without guessing. Seven procedures have a page of their own with worked examples; they are listed on Procedures. Several also have a matching tool on the MCP server.

Calling a procedure

CALL runs a procedure in three forms: standalone, with YIELD to pick and filter columns, or once per row when the argument comes from UNWIND, WITH or MATCH. A standalone call with no YIELD returns every column the procedure produces. Full clause syntax is in Syntax & Clauses.

CALL whisper.variants("paypal.com")
YIELD variant, method, exists, confidenceLabel
WHERE exists
RETURN variant, method, confidenceLabel
LIMIT 6

UNWIND ["google.com", "cloudflare.com"] AS d
CALL whisper.psl.tldPlusOne(d) YIELD apex
RETURN d, apex

Five rules cover nearly every failed call:

• Quote every argument. CALL whisper.identify(ubuntu.com) is rejected as a bad argument, and an unquoted IPv6 literal is parsed as something else entirely and comes back as a syntax error. Always CALL whisper.identify("ubuntu.com").
• Argument types matter as much as names. whisper.topAsnsByPrefixCount(10) takes an Integer; whisper.explain.bundle takes one string and rejects a list; whisper.export takes exactly one map.
• YIELD columns are exact contracts. A column the procedure does not emit is rejected, not ignored, and the message names the valid columns. db.relationshipTypes() yields type, not relationshipType.
• Multi-shape procedures need named columns. explain and whisper.history change their column set with the indicator, so YIELD * is rejected, and so is a YIELD that mixes shapes. Name columns from one shape, or call the single-shape variant: whisper.explain.bundle, whisper.history.whois, whisper.history.bgp.
• A URL folds to its host. whisper.identify, whisper.assess, whisper.walk and the history procedures read https://host/path?q=1 as host. whisper.assess, whisper.assessUrl, whisper.identify and whisper.enrich take a single string or a list.

The procedures

Every procedure the engine registers, grouped by what it answers. The YIELD columns are exact contracts: a column the procedure does not emit is rejected, not ignored.

Read coverage before band. Only known-clean — coverage: known-clean. In coverage, no malicious evidence. licenses the word "clean"; no-data — coverage: no-data. Not in coverage. This is not a verdict — nothing was looked at. means unknown, which is a different thing again; malicious-evidenced — coverage: malicious-evidenced. In coverage, with positive evidence of malice. and ambiguous — coverage: ambiguous. In coverage, and the evidence points both ways. mean there is evidence, whatever the band says. whisper.explain does not return coverage at all. Full contract: Coverage — what we looked at.

Threat & verdict

History

Attribution & discovery

CVE plane

Infrastructure & BGP

Public Suffix List

Threat-intel snapshot candidates

Bulk export

Your own context

Every procedure

The tables above are the ones worth learning first. This one is the whole surface, generated from CALL db.procedures() — every procedure the engine registers, whether or not a page has been written about it. Mode is the engine's own, and it describes the ENGINE, not this API: READ answers a question; WRITE names a procedure that would change something, and that you cannot call from here. The public Cypher endpoint rejects mutating calls, and the MCP server exposes read-only tools only — it has no contribution or feedback tool. There is no route by which a reader of this page writes to the graph.

The WRITE rows are engine capabilities, not something you can call here. whisper.submit and whisper.watch are registered by the engine and reported by db.procedures(), which is why they appear in this table. They are not reachable through the MCP server, which exposes read-only tools and refuses write procedures by name, and not through the public Cypher endpoint, which rejects any mutating call. There is no contribution or feedback tool on the MCP surface. Treat this column as a statement about the engine, not an invitation.

Rows generated from CALL db.procedures() YIELD name, signature, description, mode RETURN name, signature, description, mode ORDER BY name against https://graph.whisper.security, fetched 2026-09-20T01:36:24Z.

Read the advisories channel

A successful response can carry a top-level advisories[] array beside columns, rows and statistics. Each entry has a kind, a human message and, where they apply, the queried input and the resolved value. It lives on the response envelope, not in a row, so it survives any YIELD or RETURN projection, and the key is omitted when there is nothing to say: test for its presence rather than expecting an empty array. The kinds you will meet on this surface:

When to prefer a procedure over a traversal

Reach for the procedures first. They answer the hardest questions in one call, usually faster and cleaner than a hand-written deep traversal.

• The logic runs server-side. explain() computes a score from feed count, feed weights, recency and the age of the listings, and hands back the arithmetic in factors[] with the named feeds in sources[]. Reproducing that by walking LISTED_IN edges yourself takes more hops and gives you less evidence.
• A procedure replaces a slow scan. Where a hand-written query walks the graph itself, a procedure does the same work in one call, which makes it the standard fix for a query that runs long — alongside anchoring the query and adding a LIMIT. See Best Practices.
• The output is decision-ready. A procedure returns labeled columns you can paste straight into a ticket.

One caveat: BGP routing history over a large network is slow. Keep a LIMIT on whisper.history.bgp() calls and expect a longer round trip.

Access

Some of these calls need an API key. Pass it in the X-API-Key header; sign in to get one — there is no card to enter.

Schema introspection

The db.* procedures describe the live schema, so you can confirm a label or edge exists before you anchor on it.

CALL db.labels() YIELD label RETURN label ORDER BY label LIMIT 12

db.labels() lists every node label with its count. db.relationshipTypes() lists every edge type as type (not relationshipType) with its source and target labels, and flags an edge that is declared but currently empty. db.propertyKeys() lists every property name in use. db.schema() returns a structured overview of the whole graph and accepts a format argument ("json", "markdown", or "details"), which collapses the result into a single schema column; db.schema.nodeTypeProperties() and db.schema.relTypeProperties() list the properties on each label and edge type. db.functions() and db.procedures() list the callable surface itself. The full label, edge, and property model is on the Graph Schema pages.