Bitquery: Crypto & Blockchain Data

Robinhood Native Balances

robinhood_native_balances

Read-only

NATIVE COIN BALANCE of up to 50 Robinhood (robinhood, rh, Robinhood Chain) addresses you ALREADY HAVE: each address's current ETH balance (the coin that pays gas) - for filtering a known set of wallets down to the funded ones, e.g. an airdrop cohort. To discover holders you do not have yet, use robinhood_token_holders. NOT one address's transfer history → use robinhood_address_flow_summary. Pass the addresses separated by "|" (0x..) - up to 50; addresses after the 50th distinct one are ignored (compare Addresses_Requested with Addresses_Used), so split a longer list into several calls. WINDOW: only balances UPDATED within the last since_days days (default 7) are read, so an address that has not moved its native coin in that window returns NO row. Use the same window you searched for activity - e.g. the window of robinhood_token_senders - because an active wallet's balance is always fresh there; a wider window costs more for no gain on active wallets. Native_Balance is in ETH (18 decimals); Native_Balance_Raw is the exact integer amount (wei); Balance_As_Of is when that balance was last updated. To identify the addresses, pass them to labels_for_addresses. Each row: Address, Native_Balance, Native_Balance_Raw, Balance_As_Of, Addresses_Requested, Addresses_Used.

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": {
      "addresses": "<addresses>"
    },
    "name": "robinhood_native_balances"
  }
}

Input Schema

Name	Required	Description	Default
`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
`addresses`	Yes	Addresses to look up, 0x-hex (case-insensitive), separated by "\|" - up to 50; addresses after the 50th distinct one are ignored (compare Addresses_Requested with Addresses_Used).
`since_days`	No	Only balances updated in the last N days are read (default 7, 1-30); an address not active in that window returns no row. Use the same window you used for robinhood_token_senders.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

changedInput schema / properties / since_days / default
```
Previous value: -2New value: +7
```

changedInput schema / properties / since_days / description

Previous value: -"Only balances updated in the last N days are read (default 2, 1-30); an address not active in that window returns no row. Use the same window you used for robinhood_token_senders."New value: +"Only balances updated in the last N days are read (default 7, 1-30); an address not active in that window returns no row. Use the same window you used for robinhood_token_senders."

AddedOct 28, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false), yet the description adds the non-obvious behavior that matters: only balances updated inside the since_days window are read, so an inactive address returns NO row; the 50th+ distinct address is silently ignored and that truncation is observable via Addresses_Requested vs Addresses_Used. It also discloses units (ETH, 18 decimals), the raw wei integer, and the freshness meaning of Balance_As_Of.

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?

The lead clause front-loads the capability and scope before any caveats, and most sentences carry distinct information. It is somewhat dense and repeats the 50-address cap and truncation rule that the schema descriptions already state, which is the main trimming opportunity.

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 enumerating every returned field (Address, Native_Balance, Native_Balance_Raw, Balance_As_Of, Addresses_Requested, Addresses_Used) with units, and by pointing to labels_for_addresses for identification. Nothing an agent needs to call this correctly or interpret the result is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds meaning the schema does not: it ties since_days to the window used for robinhood_token_senders and explains that a wider window costs more for no gain on active wallets. It reinforces the '|' separator and truncation semantics already documented in the schema, so the gain is real but partly redundant.

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 — look up each address's current native coin (ETH) balance for up to 50 Robinhood addresses you already hold — and explicitly names the sibling to use instead for the adjacent task (robinhood_token_holders for discovery, robinhood_address_flow_summary for a single address's transfer history). An agent can route correctly without opening any 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 the use case concretely ('filtering a known set of wallets down to the funded ones, e.g. an airdrop cohort'), then supplies explicit when-not rules with named alternatives for both adjacent needs. It also gives operational guidance for the input list (split longer lists into several calls after 50 addresses) and for choosing since_days (reuse the same window as robinhood_token_senders).

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.