Bitquery: Crypto & Blockchain Data

Tron Find Calls

tron_find_calls

Read-only

FIND SMART-CONTRACT CALLS on one Tron (trx, TRX, TRON) contract — "who called method X on contract Y, when, did it succeed" in one filtered query. Match by method name (e.g. "transfer"), full signature ("transfer(address,uint256)"), or raw 4-byte selector (e.g. a9059cbb) — useful when the method is unnamed. Without after_time the search covers the most recent 7 days (ending at the cursor's time, or at before_time, if set) — set after_time to search further back. Value is the TRX attached to the call. Inspect a found tx's token movements with tron_tx_transfers. NOT event logs a contract emitted → use tron_find_events. NOT what one address signed → use tron_transactions. Returns up to limit calls (default 20, at most 10000), newest first; page back with the last row's Cursor - each page covers the days window ending there. SCAN COST scales with the window, not with the limit: on a very high-traffic contract set days=1 and page back with cursor - several times cheaper than a 7-day window for the same page. Widen days for quiet contracts or rare matches. Calls inside one transaction come back in no particular order - sort them by CallPath if you need execution order. Each row carries the call's decoded input Arguments (Name, Type, Value; integers are decimal strings in raw units, NOT divided by token decimals; addresses in base58) - at most 32 per row: ArgumentCount is the full number and ArgumentsTruncated=1 marks a cut list (every array element counts as one). A method the decoder does not recognise has no Arguments. Each row: Tx, Time, Block, Caller, Method, Signature, Selector, CallPath, Value, Success, Reverted, Error, GasUsed, Cursor, Arguments, ArgumentCount, ArgumentsTruncated.

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": {
      "contract": "<contract>"
    },
    "name": "tron_find_calls"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Size of the default scan window in DAYS, ending at the cursor's time when cursor is set, else at before_time, else now. Ignored when after_time is set. Use days=1 on a very high-traffic contract and page back with cursor.
`limit`	No	Max calls (newest first). At most 10000.
`caller`	No	Only calls made from this Tron base58 address. Empty = any caller.
`cursor`	No	Exact 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 (busy contracts often have hundreds in one second). When set, before_time is ignored and the scan window ends at the cursor's time. Empty = first page.
`format`	No	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.	rows
`method`	No	Method to match — name (e.g. "transfer") or full signature ("transfer(address,uint256)"), case-insensitive. Empty = any method.
`contract`	Yes	Tron base58 contract address (T...) whose calls to search.
`selector`	No	Raw 4-byte method selector, hex with or without 0x (e.g. "a9059cbb"). Alternative to `method` for unnamed methods. Empty = any.
`after_time`	No	Only calls at/after this UTC time. Empty = search the most recent 7 days (ending at the cursor's time, or at before_time, if set). 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.
`before_time`	No	Only calls strictly before this UTC time — a COARSE filter, not a pager: it drops every row that shares the last row's timestamp, so a walk built on it silently loses calls. Use cursor to page. Ignored when cursor is set. Empty = no upper 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.
`only_successful`	No	1 = only successful calls in successful transactions (default); 0 = include failed / reverted calls.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

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"
+}

First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond readOnly annotations, it discloses cost behavior ("SCAN COST scales with the window, not with the limit"), the days=1 vs 7-day tradeoff, ordering caveat (calls within a tx come back unordered; sort by CallPath), the 7-day default window, and argument-decoding limits (32-arg cap, ArgumentsTruncated, raw-unit decimals caveat). That is exactly the non-obvious context annotations cannot convey.

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/cost, then row shape — a sensible order, with caps-keyword structure aiding scanning. It is long and partly redundant with the schema (the days=1 advice appears twice, default 7-day window restated), which keeps it short of a 5.

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-value burden and does so: it enumerates every row field, explains Arguments decoding, ArgumentCount vs ArgumentsTruncated, and the limit default/max plus newest-first paging. An agent has everything needed to call it and interpret results correctly.

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 meaning: method-match accepts name, full signature, or raw 4-byte selector (useful for unnamed methods), and Value is the TRX attached to the call. It reinforces the cursor-vs-before_time distinction and the days/after_time interplay, though most of this duplicates the schema text rather than extending it.

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?

Opens with a specific verb+resource+scope: "FIND SMART-CONTRACT CALLS on one Tron contract" with the question it answers (who called method X on contract Y, when, did it succeed). It explicitly names what it is not (event logs, address-signed transactions) and points at the sibling to use instead, so an agent can distinguish it from tron_find_events and tron_transactions 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 routing ("NOT event logs a contract emitted → use tron_find_events", "NOT what one address signed → use tron_transactions") and a follow-up pointer ("Inspect a found tx's token movements with tron_tx_transfers"). It also states operational guidance: default 7-day window, use after_time to go further back, and page with cursor rather than before_time.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Bitquery: Crypto & Blockchain Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.