Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Robinhood Trace Dominant Path

robinhood_trace_dominant_path
Read-only

AUTO-WALK the dominant (largest-total-amount) OUTGOING edge of ONE token from a Robinhood (robinhood, rh, Robinhood Chain) address, hop by hop, up to 5 hops — collapses ~5 manual robinhood_trace_next_hop calls into one. Every hop returns Hop*_To (the address that received), Hop*_Token (the contract of the token that moved) and Hop*_Edge_Total, plus Hops_Found (how many hops resolved) and Path_Status for the walk itself. Hop*_Edge_Total is NOT the amount that travelled along the path: it is the ALL-TIME total of EVERY transfer of that token between that hop's sender and receiver, so it can be orders of magnitude larger than the sum you are tracing and the hop totals are not comparable with each other. To break one edge down — its transfer count (Transfers), first/last seen, and the full ranking of that address's edges — call robinhood_trace_next_hop on the hop's sender. The walk NEVER goes back to an address it has already visited (the seed included), so it cannot bounce back and forth between the same two wallets — each hop is the largest edge to a NEW address. READ Path_Status FIRST — NO_MATCH means the token filter matched nothing (wrong symbol, or that symbol belongs to a different token — pass contract), PATH_END means the trail really ran out, DEPTH_LIMIT means it may continue past hop 5. All-NULL hops with NO_MATCH are a filter problem, not a dead end. Address labels are not available on this chain, so read down the hops and stop at the first address whose profile looks like a service — that's the destination. Pin the token with contract whenever you know it — a SYMBOL is not unique, clone tokens reuse popular symbols, and with a symbol alone the hops can drift between look-alike tokens; compare the per-hop token contract to spot that. LIMITS: follows only the single biggest edge per hop (misses splits / fan-outs), fixed depth 5, and transfers to the burn address are not followed. For branching / adaptive tracing call robinhood_trace_next_hop hop by hop, identify each hop with labels_for_addresses and choose the next address yourself (prompt_playbook with playbook=money_flow returns the full step-by-step procedure); for one hop's full ranking use robinhood_trace_next_hop. Heavy multi-hop walk — can time out on a very busy address; retry, or narrow it with contract / a less-busy token. 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>",
      "currency": "<currency>"
    },
    "name": "robinhood_trace_dominant_path"
  }
}

Input Schema

NameRequiredDescriptionDefault
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
addressYesSeed wallet/contract address, 0x-hex (case-insensitive).
contractNoRestrict the walk to ONE exact token by its contract address (0x-hex, case-insensitive) — the reliable way to pin a token, since a symbol also matches clone tokens. Overrides `currency` when both are given. Empty = follow `currency` instead.
currencyYesToken symbol to follow, e.g. "USDT", "WETH". Ignored when `contract` is given. A symbol is NOT unique — clone tokens reuse popular symbols, so prefer `contract` when you have it. No backslashes.
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. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare a read-only, non-destructive walk and the description is entirely consistent, adding substantial context beyond them: Path_Status values (NO_MATCH / PATH_END / DEPTH_LIMIT), the no-revisit rule, the misleading nature of Hop*_Edge_Total (all-time edge total, not path amount), burn-address exclusion, timeout risk, and the internal-vs-top-level transfer rule. This is exactly the extra behavioral disclosure annotations cannot provide.

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 action and the key caveat about Hop*_Edge_Total immediately after, which is the right ordering. It is dense but nearly every sentence carries a distinct operational rule; the only bloat is the redundant restatement of robinhood_trace_next_hop as the tool for a single hop's ranking, mentioned once early and again near the end.

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 no output schema, the description still names the returned fields (Hop*_To, Hop*_Token, Hop*_Edge_Total, Hops_Found, Path_Status) and explains how to interpret each. Limits, failure modes, and retry guidance are all covered, so an agent has everything needed to call and read this heavy multi-hop tool.

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 the baseline is 3, but the description adds real semantic weight: why `contract` should be pinned (symbols are not unique and clone tokens can make hops drift between look-alikes) and that per-hop token contracts can be compared to detect drift. `address` and `format` are left to the schema, which is acceptable given full coverage.

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 — 'AUTO-WALK the dominant (largest-total-amount) OUTGOING edge of ONE token from a Robinhood address, hop by hop, up to 5 hops' — and explicitly contrasts it with the manual alternative robinhood_trace_next_hop. The scope (one token, outgoing, single largest edge, depth 5) is unambiguous and cannot be confused with any sibling.

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?

Names the alternatives and the conditions that select them: robinhood_trace_next_hop hop by hop for branching/adaptive tracing, labels_for_addresses for identification, prompt_playbook with playbook=money_flow for the full procedure, and robinhood_trace_next_hop for one hop's full ranking. It also states when to prefer `contract` over `currency` and when to retry versus narrow.

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.