Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Zec Address Received

zec_address_received
Read-only

INCOMING Zcash (zec, ZEC, mainnet) outputs for an address — every coin received (tx, amount, output type: payment/change/mining (block reward), time), most recent first. Indexed by address (fast). Use to see what a ZEC address received and in which transactions. NOT what this address spent → use zec_sent_from_address. NOT sums over its whole history → use zec_address_flow_summary or zec_address_profile. An address can receive several coins (outputs) in one transaction, each its own row. Returns up to limit rows (default 20, at most 1000), newest first; page back with the last row's Cursor - a page shorter than limit is the last one. Set sort='amount' for the largest receipts instead: a top-N page with no Cursor. NOTE: shows receiving events, not the sender addresses (a UTXO output has no single sender) — pass a Tx to zec_tx_flow to see the addresses that funded it, or call zec_address_flow_summary for the top senders. Coins that arrive from the shielded pool are listed here too: their transaction has no transparent inputs in zec_tx_flow, and where they came from cannot be traced. Only the TRANSPARENT side of Zcash is visible: transparent addresses start with t1 or t3. Coins moved into or out of the shielded pool (z-addresses, unified u1… addresses) cannot be traced here. Each row: Time, Tx, Type, Amount_ZEC, Cursor.

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

Input Schema

NameRequiredDescriptionDefault
sortNo"amount" = largest outputs first; "recent" (default) = newest first; any other value is refused. Ranking by amount returns a TOP-N, not the head of a page-walk: such a page carries no Cursor, so start a walk with sort='recent'.recent
limitNoMax outputs (ordered by `sort`; default newest first). 1-1000.
cursorNoExact paging cursor: pass the Cursor value of the LAST row of the previous page to get the next page. Prefer this over before_time, which skips any rows sharing the last row's timestamp (a busy address can receive hundreds of outputs in one second). When set, before_time is ignored and rows come back newest-first whatever sort says. Empty = first page. Any other value is rejected.
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
addressYesZcash TRANSPARENT address — t1… or t3…, 35 characters, case-sensitive, matched verbatim. Shielded z-addresses and unified u1… addresses are not supported and are rejected. An address of another chain does not have this form and is refused.
after_timeNoOnly outputs at/after this UTC time: "YYYY-MM-DD", "YYYY-MM-DD HH:MM:SS" or ISO "2026-07-01T00:00:00Z" (the form Time comes back in). Must be earlier than before_time when both are set. Empty = no lower bound. Other formats and impossible dates (2026-02-30, 25:00) are rejected.
before_timeNoOnly outputs strictly before this UTC time ("YYYY-MM-DD", "YYYY-MM-DD HH:MM:SS" or ISO "2026-07-01T00:00:00Z" (the form Time comes back in)) — a coarse upper bound, NOT a paging mechanism (it drops every row sharing the last row's timestamp). Page with cursor instead. Ignored when cursor is set. Empty = no upper bound. Other formats and impossible dates are rejected.

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

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

Annotations only cover readOnly/non-destructive, and the description adds substantial context: the transparent-only visibility limit (t1/t3, no shielded or u1), the no-single-sender property of UTXO outputs, multiple outputs per tx as separate rows, and the paging contract (page shorter than limit = last page). These are real behavioral traits an agent cannot infer from structured fields.

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 purpose then exclusions then paging, which is the right order. It is dense and repeats a couple of schema facts (default 20, max 1000, newest first), but nearly every sentence carries routing or behavioral information.

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, and the description compensates by listing the row fields (Time, Tx, Type, Amount_ZEC, Cursor) and the columnar/rows shapes. Address format constraints and the shielded-pool blind spot are both called out, so nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description adds cross-parameter semantics the schema describes only per-field: cursor overrides sort/before_time, amount ranking is a top-N with no cursor, and default 20 / max 1000 paging behavior. It explains how the parameters interact, not just what each one is.

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 (incoming outputs for a Zcash address), enumerates the fields per row, and explicitly contrasts itself with zec_sent_from_address, zec_address_flow_summary and zec_address_profile. An agent can pick this over the three nearest siblings 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 Guidelines5/5

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

Gives explicit when-not clauses with named alternatives ('NOT what this address spent → use zec_sent_from_address', 'NOT sums → flow_summary/profile'), plus the routing for sender addresses ('pass a Tx to zec_tx_flow') and when to switch to sort='amount'.

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.