Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Dash Tx Flow

dash_tx_flow
Read-only

Full flow of one or several Dash (dash, DASH, mainnet) transactions: all INPUT addresses (senders) and OUTPUT addresses (receivers) with amounts, each annotated. Note is unknown on nearly every Dash output — change is not detected, so any output can be the payment. THE hop primitive for DASH tracing: follow a recipient to its own spends (dash_sent_from_address) and repeat. tx_hash is the 64-hex id as returned by the other dash 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. Outputs whose script has no standard address carry a placeholder instead of an address: m-… (a bare multisig script) or d-… (a data or other non-standard script; one d-… value can stand for many unrelated outputs). A placeholder cannot be looked up with the address tools — the visible trail ends there. Change detection is not available on Dash: no output is classified as change (nearly every Note is unknown), so the change a wallet pays to another of its own addresses counts as a payment - Targets, Top_Receivers and tx_flow outputs can include such change. Outputs back to the address itself are still left out; dash_related_addresses shows likely same-owner addresses, and dash_tx_flow marks an output paid back to one of the transaction's own input addresses as change_to_input_address, which is the only change signal Dash has. 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": "dash_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_hashYesDash transaction id, 64-hex (as shown by the other dash 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.5/5.0
Behavior5/5

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

Goes well beyond the readOnly annotation: explains that change is never detected, that any output can be the payment, how placeholders (m-…, d-…) terminate the trail, that labels are unavailable on Dash, the one-row-per-transaction fee behavior, and the not_found side value. This is exactly the non-obvious behavioral context an agent needs to avoid misreading results.

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?

Front-loaded with the core purpose, but the change-detection limitation is stated twice (once early, once in a dedicated paragraph near the end) and the placeholder explanation is verbose. The content is valuable but a third of the text is redundant restatement.

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?

No output schema exists, yet the description fully documents the row model: Side values (input/output/fee/not_found), Index semantics, Funded_By_Tx for backward tracing, and the change_to_input_address marker. An agent has everything needed to interpret and chain the output.

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 adds real meaning: tx_hash is 64-hex as returned by other dash tools, ids are '|'-separated up to 50 with ids past the 50th ignored, and the Tx column attributes each row in a batch. That exceeds what the schema documents.

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 ('Full flow of one or several Dash transactions: all INPUT addresses and OUTPUT addresses with amounts'), and the scope (one/several, mainnet) distinguishes it from dash_address_flow_summary and dash_sent_from_address. An agent can tell what it returns without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly positions itself as 'THE hop primitive for DASH tracing' and names the next step (dash_sent_from_address) plus the backward hop via Funded_By_Tx, and points to dash_related_addresses for same-owner signals. It lacks explicit 'use X instead when...' exclusions against siblings like dash_transfers_raw_sql or dash_address_flow_summary, so it falls short of a 5.

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.