Bitquery: Crypto & Blockchain Data

Robinhood Flow Edges

robinhood_flow_edges

Read-only

MONEYFLOW GRAPH EDGES out of a Robinhood (robinhood, rh, Robinhood Chain) address: one row per counterparty — Source → Target, total Amount, Currency. 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). NOT choosing which counterparty to follow next → use robinhood_trace_next_hop. Address labels are not available on this chain, so flag a service node from its own profile (robinhood_address_profile) and STOP expanding that branch. 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 robinhood_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": "robinhood_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. A symbol here may also be a tokenized equity ticker (NVDA, GME, AAPL), not just a clone, so the contract is the only reliable identifier. 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?

Annotations only declare readOnly, yet the description adds behavior well beyond that: aggregation across history, a slowness warning on high-traffic hubs and how to narrow it, exclusion of internal transfers unless include_internal=1, and the critical caveat that amounts are token units with no USD value and are not comparable across tokens. It also warns about non-ASCII look-alike scam symbols.

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 the core definition and the diagram recipe, then proceeds to caveats. It is dense and long with a few trailing accretion-style sentences, but nearly every sentence carries operational guidance rather than filler.

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?

There is no output schema, and the description compensates by naming the returned fields (Source, Target, Amount, Currency, Contract, First_Seen/Last_Seen, symbol_nonascii) and their semantics. For a 10-parameter read tool, everything needed to call it correctly and interpret results is present.

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 already 100%, so the baseline is 3; the description still adds meaning by explaining why contract beats currency (symbol collisions, tokenized equity tickers), why min_amount/max_amount protect against inflated-decimal tokens skewing the ranking, and what after_time/before_time bound. It largely restates schema rationale rather than introducing undocumented parameter behavior.

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 up front ('MONEYFLOW GRAPH EDGES out of a Robinhood address') and immediately defines row granularity ('one row per counterparty — Source → Target, total Amount, Currency'). It explicitly contrasts with robinhood_trace_next_hop and robinhood_transfers_out, so an agent can distinguish it from siblings 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 an explicit workflow ('call this per address/hop, collect the edges, and emit a Mermaid graph LR'), an explicit exclusion ('NOT choosing which counterparty to follow next → use robinhood_trace_next_hop'), and a fallback for raw rows (robinhood_transfers_out). It also advises when to filter by currency vs. deliberately omitting the filter to spot an off-ramp.

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.