Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Arbitrum Trace Next Hop

arbitrum_trace_next_hop
Read-only

CONVERGENCE primitive for Arbitrum (arb, ARB, Arbitrum One, L2) tracing: aggregate an address's OUTGOING flow by counterparty (Σ amount, count, first/last seen), largest first. Answers "where did the bulk of the funds go" in one shot. Narrow with currency (recommended), after_time (= when funds reached this hop), min_amount. Pass the top counterparties to labels_for_addresses to spot a CEX / mixer / bridge (= the destination, stop there). One row per (counterparty, TOKEN); identify a token by Contract, not Currency. 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, and with after_time to one period, which is far faster than one wide call. NOT edges for a diagram → use arbitrum_flow_edges. NOT an automatic walk along the largest edge → use arbitrum_trace_dominant_path. 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. 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. Returns up to top_n rows (default 10, at most 10000), largest Total_Amount first; no rows = nothing matched. Symbol_NonAscii = 1 flags a symbol that is not plain ASCII: normal for CJK / emoji names, also how a look-alike imitates a major token. For the full labelled list in USD, totals by label type, or a set of addresses → counterparties. Each row: Counterparty, Currency, Symbol_NonAscii, Contract, Total_Amount, Transfers, First_Seen, Last_Seen.

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": "arbitrum_trace_next_hop"
  }
}

Input Schema

NameRequiredDescriptionDefault
top_nNoMax counterparties (largest first). At most 10000.
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. Empty = no token filter.
currencyNoRestrict to one currency symbol (recommended to keep the trace clean). Empty = all. A symbol is NOT unique — clone/scam tokens reuse "USDC"/"USDT" and their broken decimals can make a fake token outrank the real one, so check the returned contract before trusting the ranking. No backslashes.
after_timeNoOnly flow at/after this UTC time. Empty = no lower 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.
max_amountNoMaximum total amount for a counterparty 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 counterparties off the ranking - cap it here, or pin one token with contract.
min_amountNoMinimum total amount for a counterparty to be returned. 0 = all.
before_timeNoOnly flow strictly before this UTC time; with after_time it bounds one period. 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_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?

Goes well past readOnlyHint: it discloses that high-traffic addresses can take tens of seconds, that amounts are token units with no USD value available, that top-level transfers are always counted while internal ETH requires include_internal=1, the top_n default and 10000 cap, and that no rows means nothing matched. It also explains Symbol_NonAscii as a look-alike-token flag, which is behavioral context an agent could not infer from annotations.

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 purpose and the answer-shaped question, then alternates between NOT-routing lines and usage notes, which scans well. It is long and repeats the 'no USD / token units' caveat that also appears in max_amount, and the row-field list at the end is partially redundant with the columnar/rows format description.

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 read-only aggregation tool with no output schema, the description covers scope, filters, performance pitfalls, unit semantics, internal-transfer behavior, and the exact returned row fields. Nothing an agent needs to call it 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?

Schema coverage is 100%, so the baseline is 3; the description still adds decision-level meaning: currency is 'recommended' to keep the trace clean, after_time marks when funds reached this hop, min_amount/max_amount are the way to bound a ranking, and top_n caps the rows. The token-address vs currency-symbol distinction is reinforced beyond the schema wording.

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: aggregate an address's OUTGOING flow by counterparty (Σ amount, count, first/last seen), largest first, and frames the question it answers ('where did the bulk of the funds go'). It explicitly names the two nearest siblings it is not (arbitrum_flow_edges, arbitrum_trace_dominant_path), so it is distinguishable 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 explicit when-not routing ('NOT edges for a diagram → arbitrum_flow_edges', 'NOT an automatic walk along the largest edge → arbitrum_trace_dominant_path'), plus a downstream step ('pass top counterparties to labels_for_addresses') and a stop condition for a CEX/mixer/bridge. It also recommends narrowing with currency/contract/after_time and explains the performance tradeoff of a wide call.

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.