Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Tron Flow Edges

tron_flow_edges
Read-only

MONEYFLOW GRAPH EDGES out of a Tron (trx, TRX, TRON) address: Source → Target, total Amount, Currency. Building block for a MoneyFlow DIAGRAM — call per address/hop, collect edges, render Mermaid graph LR. Pass the Target addresses to labels_for_addresses to flag & stop at exchange nodes. Pass a currency to avoid spam; call WITHOUT a currency filter to spot a token → USDT off-ramp at the edge. For raw rows use tron_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. NOT choosing which counterparty to follow next → use tron_trace_next_hop. 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.

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

Input Schema

NameRequiredDescriptionDefault
limitNoMax edges (largest amount 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
addressYesSource Tron base58 address (T...).
contractNoRestrict to ONE exact token by its contract address (base58, starts with T) — the reliable way to pin a token, since a currency symbol also matches clone tokens. Empty = no token filter.
currencyNoRestrict to one currency symbol (e.g. "TRX", "USDT"). 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_timeNoOnly transfers at/after this UTC time (e.g. "2026-06-01"). Empty = no lower bound.
max_amountNoMaximum 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_amountNoMinimum total amount for an edge to be returned. 0 = all.
before_timeNoOnly 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.

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.7/5.0
Behavior5/5

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

Annotations only declare read-only/non-destructive, and the description adds substantial context on top: high-traffic addresses aggregate a lot of history and can take tens of seconds, narrowable via contract/currency; amounts are TOKEN UNITS with no USD value available so cross-token totals must not be added; and `symbol_nonascii` flags impersonation tokens. These are real behavioral caveats an agent could not infer from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is an excellent front-load, but the body becomes a dense wall of mixed concerns — performance, unit caveats, symbol spoofing, time bounds — and repeats the contract/currency pinning advice multiple times ('Pass a currency to avoid spam' then 'narrow it with contract or currency' then 'pin ONE token with contract'). Content earns its place, but structure and redundancy cost it.

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 carries the return-shape burden and does it: it names the edge fields (Source, Target, Amount, Currency, Contract, First_Seen/Last_Seen, symbol_nonascii) and explains units and filters. Combined with the performance warning, an agent has everything needed to call this correctly in a money-flow pipeline.

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 baseline is 3, but the description ties parameters to goals: pinning one token via `contract` to make a ranking comparable, bounding with min_amount/max_amount, and bounding a period with after_time/before_time. Much of this restates schema text (the decimal-inflation rationale for max_amount, the clone-symbol caveat for currency), so the added value is real but partly duplicative.

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+resource with the exact output shape: 'MONEYFLOW GRAPH EDGES out of a Tron address: Source → Target, total Amount, Currency'. It also explicitly positions itself against siblings — tron_transfers_out for raw rows, tron_trace_next_hop for hop selection — so an agent can choose it 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 full operating loop (call per address/hop, collect edges, render Mermaid `graph LR`), the downstream step (pass Targets to labels_for_addresses to flag exchange nodes), and two explicit when-to-use variants: with a currency filter to avoid spam versus without one to spot a token→USDT off-ramp. It also names the exclusion case ('NOT choosing which counterparty to follow next → use tron_trace_next_hop').

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.