Bitquery: Crypto & Blockchain Data

Base Flow Edges

base_flow_edges

Read-only

MONEYFLOW GRAPH EDGES out of a Base (base, L2, Coinbase L2) address: one row per counterparty — Source → Target, total Amount, Currency. NOT choosing which counterparty to follow next → use base_trace_next_hop. Building block for a MoneyFlow DIAGRAM. HOW TO DRAW: call this per address/hop, collect the edges, and emit a Mermaid graph LR (one node per address; each edge labeled with Amount+Currency). Pass the Target addresses to labels_for_addresses to flag CEX / mixer / bridge nodes and STOP expanding those branches. Pass a currency to avoid spam-token noise; call WITHOUT a currency filter to spot a token → USDT off-ramp at the edge. For raw per-transfer rows use base_transfers_out. Each edge carries the token Contract — pin one exact token with the contract param. On a very high-traffic address (an exchange or bridge hub) this aggregates a lot of history and can take tens of seconds — narrow it with contract or currency to one token to make it far faster. Amounts here are TOKEN UNITS, never USD - no USD value is available in this data, so there is no usd filter and totals for different tokens must not be compared or added together. For a ranking you can reason about, pin ONE token with contract, or bound the range with min_amount / max_amount. Symbol_NonAscii = 1 flags a symbol that is not plain ASCII: normal for CJK / emoji names, but also how a scam token impersonates a major one with Cyrillic or Greek look-alike letters - never treat such a token as the asset it resembles. In the top arrays it is the symbol_nonascii field of each entry. Bound one period with after_time / before_time. First_Seen / Last_Seen give each edge's first and last transfer. A transaction's own transfer is TOP-LEVEL, not internal, and is always counted. ETH moved by contract code deeper inside a transaction (an internal transfer) is left out unless you pass include_internal=1.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "base_flow_edges"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Max edges (largest amount first). At most 10000.
`format`	No	Shape of the returned data. "rows" (the default) returns one item per row. "columnar" returns a single item, {"columns":[...],"rows":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.	rows
`address`	Yes	Source address, 0x-hex (case-insensitive).
`contract`	No	Restrict to ONE exact token by its contract address (0x-hex, case-insensitive) — the reliable way to pin a token, since a currency symbol also matches clone tokens. Empty = no token filter.
`currency`	No	Restrict to one currency symbol (e.g. "ETH", "USDT") — recommended. Empty = all. A symbol is NOT unique — look-alike clones share it, so confirm the token via the returned Contract or pin one with contract. No backslashes.
`after_time`	No	Only transfers at/after this UTC time (e.g. "2026-06-01"). Empty = no lower bound.
`max_amount`	No	Maximum total amount for an edge to be returned. 0 (default) = no upper bound. Amounts are in each token's own units and are NOT comparable across tokens, so a token with inflated or wrong decimals can total billions of units and push the real edges off the ranking - cap it here, or pin one token with contract.
`min_amount`	No	Minimum total amount for an edge to be returned. 0 = all.
`before_time`	No	Only transfers strictly before this UTC time. Empty = up to now. Format: YYYY-MM-DD, YYYY-MM-DD HH:MM[:SS], ISO-8601 like 2026-09-20T00:00:00Z (fraction or +02:00 offset allowed) or 10-digit unix seconds.
`include_internal`	No	0 (default) = top-level transfers only - the transfer a transaction makes itself, plus token transfers. 1 = also count ETH moved by contract code deeper inside a transaction (an internal transfer, for example through a batch sender or a withdrawal contract). Only 0 or 1.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / format

Added value: +{
+  "default": "rows",
+  "description": "Shape of the returned data. \"rows\" (the default) returns one item per row. \"columnar\" returns a single item, {\"columns\":[...],\"rows\":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.",
+  "type": "string"
+}

First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/destructive annotations: warns that high-traffic addresses aggregate a lot of history and may take tens of seconds, explains that amounts are token units with no USD value and totals cannot be summed across tokens, flags the Symbol_NonAscii impersonation risk, and clarifies top-level vs internal transfer inclusion.

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?

Front-loaded with purpose and the nearest alternative before workflow and caveats; nearly every sentence carries an actionable warning. Some redundancy with the schema remains (include_internal, min/max_amount, time bounds are re-explained), which slightly dilutes density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, no-output-schema tool this is complete: it covers output grain and fields (Contract, First_Seen/Last_Seen, symbol_nonascii), performance limits, data-semantics pitfalls, and the multi-hop diagram workflow, leaving no material gap for correct invocation.

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%, so baseline is 3, but the description adds analytical meaning: pinning one token via contract to make a ranking meaningful or to avoid decimal-skewed spam tokens, and calling without a currency filter to spot a token → USDT off-ramp edge. These connect parameters to reasoning rather than restating field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('MONEYFLOW GRAPH EDGES out of a Base address') with the exact output grain: one row per counterparty with Source → Target, Amount, Currency. It explicitly distinguishes itself from base_trace_next_hop (path selection) and base_transfers_out (raw per-transfer rows), so an agent can route correctly without opening schemas.

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?

Gives explicit when-to-use/when-not-to-use instructions naming siblings ('NOT choosing which counterparty to follow next → use base_trace_next_hop'; 'For raw per-transfer rows use base_transfers_out'), plus a concrete downstream workflow with labels_for_addresses and stopping rules for CEX/mixer/bridge nodes.

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

All Bitquery: Crypto & Blockchain Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.