Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Zec Tx Flow

zec_tx_flow
Read-only

Full flow of one or several Zcash (zec, ZEC, mainnet) transactions: all INPUT addresses (senders) and OUTPUT addresses (receivers) with amounts, each annotated. Note shows change/not_change on outputs — the real payment is the non-change output(s). THE hop primitive for ZEC tracing: follow a non-change recipient to its own spends (zec_sent_from_address) and repeat. tx_hash is the 64-hex id as returned by the other zec tools; pass several ids separated by "|" (up to 50; ids past the 50th are ignored) to expand a batch in one call — the Tx column attributes each row. Side is input, output, fee (the miner fee of the transaction — one row per transaction, 0 on a block reward) or not_found (a requested id that does not exist here — check the id and the chain). Index is the position of the input or output inside the transaction, and Funded_By_Tx on an input row is the transaction that created the coins being spent — pass it back to this tool to trace one hop backwards. An output whose address is also one of the transaction's OWN input addresses is marked change_to_input_address: the wallet paid itself, so it is not a payment to someone else. Only the transparent side of a transaction is shown: when inputs exceed outputs by more than a normal fee the difference went into the shielded pool, and outputs with no inputs came out of it (or are a block reward — its single input has an empty Address). Shielded senders and recipients cannot be traced. The fee row carries that difference too, so on a transaction that moved coins into the shielded pool it is an upper bound on the real fee, not the fee itself. Address labels are not available for this chain, so exchange / mixer / service nodes cannot be recognized from this data.

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": {
      "tx_hash": "<tx_hash>"
    },
    "name": "zec_tx_flow"
  }
}

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
tx_hashYesZcash transaction id, 64-hex (as shown by the other zec tools). Several ids may be passed separated by "|". Anything that is not a 64-character hex id is refused. Up to 50 are read.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses output semantics such as change/not_change, fee rows, not_found rows, change_to_input_address, and Funded_By_Tx. It also explains important limitations: transparent-side-only visibility, shielded-pool inference, and the fee row being an upper bound when coins moved into the shielded pool.

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 description is front-loaded with the core behavior and then adds necessary tracing, output-shape, and limitation details. It is long and dense, but most sentences carry specific operational value for a complex tracing primitive; minor tightening is possible but there is little true waste.

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?

Although there is no output schema, the description explains the returned row structure in detail: input/output addresses and amounts, change flags, Side values, Index, Funded_By_Tx, and fee rows. It also covers edge cases such as not_found, shielded flows, and block rewards, making the definition complete for correct invocation and interpretation.

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 both parameters are already documented in the input schema. The description still adds useful semantics beyond the schema by explaining that tx_hash accepts multiple 64-hex ids separated by '|', that ids past the 50th are ignored, and that the Tx column attributes each row in a batch.

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?

The description states a specific verb and resource: it returns the full input/output flow of one or several Zcash transactions with amounts and annotations. It distinguishes itself from sibling tools by naming zec_sent_from_address as the next tracing step and by explaining its role as the hop primitive for ZEC tracing.

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?

It gives explicit tracing guidance: follow a non-change recipient to zec_sent_from_address, pass Funded_By_Tx back to trace one hop backwards, and batch up to 50 tx_hash values separated by '|'. It also sets scope boundaries by stating that shielded senders and recipients cannot be traced and that address labels are unavailable for this chain.

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.