SQD

Official

by subsquid-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Find Tron contract events

portal_tron_query_logs

Read-only

Query Tron event logs by contract address and topics to find TRC-20 transfers, approvals, and contract events with parent transaction hashes and optional inline decoding.

Instructions

Query raw Tron (TVM) event logs by contract address and topics with common event aliases, the parent transaction hash on every row, and optional inline decoding.

COMMON USER ASKS:

Recent USDT transfers on Tron
USDT transfers received by one wallet

FIRST CHOICE FOR:

TRC-20 token transfer events on Tron such as USDT
contract event evidence on Tron with the parent transaction hash

WHEN TO USE:

You need TRC-20 Transfer or Approval events for a token such as USDT on Tron.
You need event logs from a Tron contract filtered by topic signature or indexed address.
You want the exact transaction hash behind each Tron event.

DON'T USE:

You want native TRX transfers or contract calls; use portal_tron_query_transactions.
You need an Ethereum-compatible network; use portal_evm_query_logs.

EXAMPLES:

Recent USDT transfers on Tron: {"network":"tron-mainnet","timeframe":"5m","addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"event":"transfer","decode":true,"limit":20}
USDT transfers received by one wallet: {"network":"tron-mainnet","from_block":84000000,"to_block":84000100,"addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"event":"transfer","topic2":["TJLuVi6UhS3UTx5EUXNCoz9VNqP2gnPmyf"],"decode":true,"limit":20}

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "portal_tron_query_logs"
  }
}

Input Schema

Name	Required	Description
`event`	No	FILTER: common event alias (transfer, approval, swap, mint, burn) or a topic0 hash. Merges with topic0.
`limit`	No	Max logs to return (default: 20, max: 25)
`cursor`	No	Continuation cursor from a previous response
`decode`	No	Decode known event signatures inline with Base58 addresses
`topic0`	No	FILTER: event signature hashes, with or without 0x.
`topic1`	No	FILTER: indexed parameter 1 (often the sender). An address in any form is padded to a topic.
`topic2`	No	FILTER: indexed parameter 2 (often the recipient). An address in any form is padded to a topic.
`topic3`	No	FILTER: indexed parameter 3.
`network`	No	Network name (default: tron-mainnet). Optional when continuing with cursor.
`to_block`	No	Ending block number. Tron produces a block every 3 seconds.
`addresses`	No	FILTER: emitting contract addresses in any form (Base58 T..., 41-prefixed hex, 0x or bare 20-byte hex). Always include this or topic0 for fast queries.
`timeframe`	No	Time range (e.g., '5m', '1h'). Alternative to from_block/to_block.
`from_block`	No	Starting block number
`to_timestamp`	No	Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
`finalized_only`	No	Only query finalized blocks
`from_timestamp`	No	Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
`max_scan_blocks`	No	Safety cap for filtered latest-first scans. Default: min(window, 50000).
`response_format`	No	Response format: defaults to 'compact' for chat-friendly output. Use 'summary' for counts by contract and event.
`include_transaction`	No	Attach the parent transaction (type, caller, contract, result, fee). The hash is always attached.

Output Schema

Name	Required	Description
`_ui`	No	Chart, table, and follow-up presentation metadata.
`_app`	No	SQD Explorer identity and host-render state.
`_llm`	No	Hints to locate the primary evidence.
`_meta`	No	Network, block range, timing, and row counts.
`error`	No	Structured failure details.
`items`	No	Primary rows for list results.
`value`	No	Primary scalar result.
`answer`	No	Answer grounded in the returned data.
`_notice`	No	Limitation or truncation notice.
`_server`	No	SQD server name, exact version, and git commit.
`display`	No	Labels for presenting the result.
`_notices`	No	Limitation or truncation notices.
`_summary`	No	Human-readable summary.
`_coverage`	No	Window and result completeness.
`_evidence`	No	Replayable arguments, digest, row count, and receipt.
`_ordering`	No	Ordering guarantees.
`_execution`	No	Bounded execution and scan details.
`_freshness`	No	Freshness and finality.
`next_steps`	No	Safe follow-up actions and continuation guidance.
`_pagination`	No	Pagination state and next_cursor.
`investigation`	No	Evidence paths, pivots, and limitations.
`pipes_handoff`	No	SQD Pipes guidance for custom data needs.
`_tool_contract`	No	Tool identity, intent, and chain families.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.6Nov 13, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered upstream. The description adds real behavioral context beyond that — the parent transaction hash is always attached, decode produces inline Base58 addresses, event aliases merge with topic0 — but says nothing about rate limits, result caps per call beyond what the schema states, or what happens when max_scan_blocks is exceeded. Useful additions, but not rich behavioral disclosure.

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?

Well front-loaded: the opening sentence carries purpose and the two distinguishing capabilities, followed by labeled sections that scan quickly. The sectioned format is long relative to the information content — 'COMMON USER ASKS' partly duplicates 'WHEN TO USE' and the 'FIRST CHOICE FOR' block — but nothing is genuinely wasted and the examples earn their space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 19-parameter tool this covers the essentials: what it queries, the alias mechanism, decoding behavior, the always-present transaction hash, and clear routing to three sibling tools. An output schema exists so return values need no explanation. The gap is guidance on combining the four time-window mechanisms (timeframe, from/to_block, from/to_timestamp) and on when to set finalized_only, which an agent must still infer.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every one of the 19 parameters thoroughly. The description adds modest practical meaning through its examples — showing that 'event':'transfer' pairs with decode, and that topic2 filters a recipient wallet address — which clarifies intent beyond the field docs. That is helpful but marginal given the exhaustive schema, so baseline-plus rather than a clear 4.

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 ('Query raw Tron (TVM) event logs') plus its three defining scoping dimensions: contract address, topics, and optional decoding. It explicitly names what it is not (portal_tron_query_transactions for native TRX, portal_evm_query_logs for EVM chains), so an agent can separate it from 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?

Contains dedicated 'WHEN TO USE' and 'DON'T USE' blocks that route decisively to alternatives — native transfers go to portal_tron_query_transactions, Ethereum-compatible networks to portal_evm_query_logs. Two worked examples map realistic user asks ('recent USDT transfers', 'transfers received by one wallet') onto concrete parameter sets.

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

Deploy Server