Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Robinhood Transfers Out

robinhood_transfers_out
Read-only

OUTGOING Robinhood (robinhood, rh, Robinhood Chain) transfers from an address — where this wallet sent funds. Narrow with after_time (flows after funds arrived), currency (follow one asset), min_amount (drop dust). For an aggregated "where did the bulk go" view use robinhood_trace_next_hop; for incoming use robinhood_transfers_in. For an address with many transfers set min_amount or sort='amount', else large counterparties hide behind recent dust. Query WITHOUT a currency filter to surface the token → USDT off-ramp. Page back through history with cursor: pass the Cursor value of the LAST row of a page to get the next one — unlike before_time it never skips rows that share a timestamp. Address labels are not available on this chain — judge a counterparty from its own transfer profile (robinhood_address_profile) instead. Each row carries the token Contract — a symbol alone can match look-alike clones, so pin the real token with the contract param. Amount is in TOKEN UNITS; amounts of different tokens must never be added together. Each row also carries Price_Usd - the token's USD price at the time of the transfer - and Value_Usd = Amount x Price_Usd, with Price_Status: "ok"; "no_price" = no price is known for this token at that time, so Price_Usd and Value_Usd are empty (never read that as zero); "suspect" = the stored price is more than twice the price one day earlier AND one day later, or less than half of both - a likely data glitch - so Value_Usd is left empty - check the price with price_at. ETH and the major tokens are priced to 5 minutes, every other token has ONE price per day, so the value of a small token is approximate. There is no usd filter: min_amount / max_amount are in token units. For a ranking you can reason about, pin ONE token with contract, or bound the range with min_amount / max_amount. Amount_Raw is the exact amount as an integer in the token's smallest unit and Decimals its scale (Amount = Amount_Raw / 10^Decimals); Block and Tx_Index place the row in the chain. A transaction's own transfer is TOP-LEVEL, not internal, and is always included. Internal = 1 marks a transfer moved by contract code deeper inside a transaction; those are 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_transfers_out"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNo"amount" = largest transfers first; "recent" (default) = newest first. Ranking by amount returns a TOP-N, not the head of a page-walk: such a page carries no Cursor, so start a walk with sort='recent'.recent
limitNoMax transfers (ordered by `sort`; default newest first). At most 10000.
cursorNoExact paging cursor: pass the Cursor value of the LAST row of the previous page to get the next page. Prefer this over before_time, which skips any rows sharing the last row's timestamp (busy addresses often have hundreds in one second). When set, before_time is ignored and rows come back newest-first whatever sort says. Empty = first page.
formatNoShape 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
addressYesWallet/contract address, 0x-hex (case-insensitive).
contractNoRestrict 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. Pass "native" for ETH itself only - a currency filter such as "ETH" also matches counterfeit tokens that print that symbol. Empty = no token filter.
currencyNoRestrict to one currency symbol (e.g. "USDC"). A symbol is NOT an identifier here — clone tokens reuse it, and look-alike spellings in other alphabets render identically, so a symbol filter can sweep counterfeits in. Pin the real token with contract. Empty = all. No backslashes.
after_timeNoOnly transfers at/after this UTC time (e.g. "2026-06-01 00:00:00"). Empty = no lower bound.
max_amountNoMaximum transfer amount (token units). 0 (default) = no upper bound. Amounts are in each token's own units and are NOT comparable across tokens, so with sort="amount" a token with inflated or wrong decimals can report billions of units and push real transfers off the page - cap it here, or pin one token with contract.
min_amountNoMinimum transfer amount (token units). 0 = all.
before_timeNoOnly transfers strictly before this UTC time — a coarse upper bound, NOT a paging mechanism (it drops every row sharing the last row's timestamp). Page with cursor instead. Ignored when cursor is set. Empty = no upper bound. 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_internalNo0 (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.

  1. Changed1 schema field changed
    • 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"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / before_time / description
      Previous value: -"Only transfers strictly before this UTC time — page back through history by passing the oldest Time of the previous page. Empty = no upper bound. 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."New value: +"Only transfers strictly before this UTC time — a coarse upper bound, NOT a paging mechanism (it drops every row sharing the last row's timestamp). Page with cursor instead. Ignored when cursor is set. Empty = no upper bound. 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."
  3. Changed1 schema field changed
    • changedInput schema / properties / contract / description
      Previous value: -"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."New value: +"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. Pass \"native\" for ETH itself only - a currency filter such as \"ETH\" also matches counterfeit tokens that print that symbol. Empty = no token filter."
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say readOnlyHint=true; the description adds substantial undisclosed context — token-unit amounts that must not be summed across tokens, Price_Status semantics ('no_price' must not be read as zero, 'suspect' = >2x or <0.5x of neighboring daily prices), price-resolution limits (5 min for majors, one/day for others), and that top-level transfers are always included while internal ones need include_internal=1. That is real behavioral disclosure beyond structured fields.

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 routing, then param guidance, then row-shape notes — a sensible order. It is long, and a few points (cursor paging, before_time not being a paging mechanism, contract vs currency) are restated in the schema descriptions, so some material is redundant rather than wasted.

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?

With 12 parameters, no output schema, and an encoding-heavy result set, the description still covers everything an agent needs: row fields (Contract, Price_Usd, Value_Usd, Amount_Raw/Decimals, Block/Tx_Index), how to judge counterparties without address labels (robinhood_address_profile), and how to page reliably. Nothing material is missing for correct invocation or interpretation.

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%, so the baseline is 3, but the description adds meaning beyond it: it explains the cursor-vs-before_time tradeoff in terms of skipped same-timestamp rows, why a symbol filter sweeps in clones and contract should be used to pin a token, that there is no USD filter so min/max_amount are token units, and that sort='amount' is a TOP-N that breaks page-walking. These are cross-parameter interactions the schema alone does not spell out.

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?

Opens with a specific verb+resource+scope: 'OUTGOING Robinhood (robinhood, rh, Robinhood Chain) transfers from an address — where this wallet sent funds.' It explicitly contrasts with robinhood_transfers_in (incoming) and robinhood_trace_next_hop (aggregated destination view), so an agent can route without opening a sibling schema.

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 alternatives ('for an aggregated "where did the bulk go" view use robinhood_trace_next_hop; for incoming use robinhood_transfers_in'), plus situational advice: set min_amount or sort='amount' for busy addresses, query without a currency filter to surface off-ramps, and page with cursor rather than before_time.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.