Skip to main content
Glama

Find Tron contract events

portal_tron_query_logs
Read-only

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}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eventNoFILTER: common event alias (transfer, approval, swap, mint, burn) or a topic0 hash. Merges with topic0.
limitNoMax logs to return (default: 20, max: 25)
cursorNoContinuation cursor from a previous response
decodeNoDecode known event signatures inline with Base58 addresses
topic0NoFILTER: event signature hashes, with or without 0x.
topic1NoFILTER: indexed parameter 1 (often the sender). An address in any form is padded to a topic.
topic2NoFILTER: indexed parameter 2 (often the recipient). An address in any form is padded to a topic.
topic3NoFILTER: indexed parameter 3.
networkNoNetwork name (default: tron-mainnet). Optional when continuing with cursor.
to_blockNoEnding block number. Tron produces a block every 3 seconds.
addressesNoFILTER: 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.
timeframeNoTime range (e.g., '5m', '1h'). Alternative to from_block/to_block.
from_blockNoStarting block number
to_timestampNoEnding timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
finalized_onlyNoOnly query finalized blocks
from_timestampNoStarting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
max_scan_blocksNoSafety cap for filtered latest-first scans. Default: min(window, 50000).
response_formatNoResponse format: defaults to 'compact' for chat-friendly output. Use 'summary' for counts by contract and event.
include_transactionNoAttach the parent transaction (type, caller, contract, result, fee). The hash is always attached.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
_uiNoChart, table, and follow-up presentation metadata.
_appNoSQD Explorer identity and host-render state.
_llmNoHints to locate the primary evidence.
_metaNoNetwork, block range, timing, and row counts.
errorNoStructured failure details.
itemsNoPrimary rows for list results.
valueNoPrimary scalar result.
answerNoAnswer grounded in the returned data.
_noticeNoLimitation or truncation notice.
_serverNoSQD server name, exact version, and git commit.
displayNoLabels for presenting the result.
_noticesNoLimitation or truncation notices.
_summaryNoHuman-readable summary.
_coverageNoWindow and result completeness.
_evidenceNoReplayable arguments, digest, row count, and receipt.
_orderingNoOrdering guarantees.
_executionNoBounded execution and scan details.
_freshnessNoFreshness and finality.
next_stepsNoSafe follow-up actions and continuation guidance.
_paginationNoPagination state and next_cursor.
investigationNoEvidence paths, pivots, and limitations.
pipes_handoffNoSQD Pipes guidance for custom data needs.
_tool_contractNoTool identity, intent, and chain families.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral value by noting every row carries the parent transaction hash, that event aliases are supported, and that decoding is optional, plus examples showing output-oriented usage. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a lead sentence, categorized sections (FIRST CHOICE FOR, WHEN TO USE, DON'T USE) and examples. Each section is front-loaded and earns its place; the whole is scannable despite covering many use cases and two exclusions.

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?

Given a 19-parameter tool with 100% schema coverage and an output schema, the description covers what the tool is for, when to prefer it over two named alternatives, and how typical USDT transfer requests should be shaped. The examples plus schema exhaustively cover invocation concerns, so nothing critical is missing for an agent to call it 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?

The schema already describes all 19 parameters (100% coverage), so the baseline is 3; the description earns extra credit through two full JSON examples. The wallet-received example demonstrates that `topic2` should carry the recipient Base58 address, and both examples pair `addresses`, `event`, and `decode` into a realistic query. This is meaningful guidance beyond the raw property descriptions.

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 and resource: 'Query raw Tron (TVM) event logs by contract address and topics.' It immediately scopes to Tron/TRC-20 and highlights the parent-transaction-hash output, which distinguishes it from generic EVM log tools. The 'DON'T USE' section explicitly routes native TRX calls to portal_tron_query_transactions and EVM calls to portal_evm_query_logs, so the purpose is unambiguous.

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?

Description includes named WHEN TO USE bullets (TRC-20 Transfer/Approval events, topic filtering, parent tx hash) and an explicit DON'T USE section naming portal_tron_query_transactions for native TRX transfer/contract calls and portal_evm_query_logs for EVM networks. This gives the agent direct decision rules rather than implied context.

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.