Skip to main content
Glama

Find internal calls and contract creations

portal_evm_query_traces
Read-only

Query raw EVM traces to inspect internal calls, contract creations, self-destructs, and rewards filtered by caller, callee, method, deployer, or transaction hash.

Instructions

Query raw EVM traces: internal calls, contract creations, self-destructs, and block rewards, filtered by caller, callee, method, deployer, or one transaction, with the parent transaction hash on every row.

COMMON USER ASKS:

  • Internal calls of one transaction

  • Recent internal calls into a contract

  • Contracts deployed by an address

FIRST CHOICE FOR:

  • what a transaction called internally, including value moved by internal calls

  • contracts deployed by an address, or the internal call tree behind an incident

WHEN TO USE:

  • You need the internal calls of a transaction: which contracts it called, with what selector and value, and which calls failed.

  • You want contracts created by a deployer or the creation trace of a contract.

  • You are tracing an exploit or incident below the top-level transaction and log surface.

  • You want internal ETH transfers between contracts that emit no event.

DON'T USE:

  • You only need top-level transactions or event logs; those tools are cheaper.

  • You need storage changes; state diffs are not exposed by this tool.

EXAMPLES:

  • Internal calls of one transaction: {"network":"ethereum-mainnet","from_block":12244145,"to_block":12244145,"transaction_hash":"0x851bad0415758075a1eb86776749c829b866d43179c57c3e4a4b9359a0358231","limit":25}

  • Recent internal calls into a contract: {"network":"base-mainnet","timeframe":"10m","type":["call"],"call_to":["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"],"method":"transfer","limit":20}

  • Contracts deployed by an address: {"network":"base-mainnet","timeframe":"24h","type":["create"],"create_from":["0x4200000000000000000000000000000000000006"],"limit":10}

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

Input Schema

NameRequiredDescriptionDefault
typeNoFILTER: trace types. 'create' covers both CREATE and CREATE2; 'reward' only exists on proof-of-work history.
limitNoMax traces to return (default: 20, max: 25)
cursorNoContinuation cursor from a previous response
methodNoFILTER (call traces): method alias such as transfer, approve, deposit, or a 4-byte selector. Merges with call_sighash.
call_toNoFILTER (call traces): called addresses.
networkNoNetwork name or alias. Optional when continuing with cursor.
to_blockNoEnding block number. Traces are expensive: keep filtered windows under 5,000 blocks.
call_fromNoFILTER (call traces): calling addresses, contracts or wallets.
timeframeNoTime range (e.g., '10m', '1h'). Alternative to from_block/to_block. Keep it short for traces.
from_blockNoStarting block number (use this OR timeframe)
scan_orderNoWhich side of the block window to scan first. Use earliest for first-occurrence questions.latest
create_fromNoFILTER (create traces): deployer addresses.
call_sighashNoFILTER (call traces): 4-byte selectors such as 0xa9059cbb.
field_presetNoField preset: 'minimal' (type, from, to), 'standard' (value, selector, gas, result address), 'full' (adds call input and output and creation code).standard
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 bounded scans. Default: 5,000 blocks with filters, 100 without.
response_formatNoResponse format: defaults to 'compact' for chat-friendly output. Use 'summary' for counts by type, failures, value moved, and top callers.
transaction_hashNoFILTER: keep only traces of this transaction. Give its block (from_block = to_block) or a window of at most 1,000 blocks; find the block with portal_evm_query_transactions first when unknown.
include_subtracesNoAlso return the child traces of each matching trace
include_transactionNoAttach the parent transaction (sender, recipient, value, status). The hash is always attached.
create_result_addressNoFILTER (create traces): deployed contract addresses.

Output 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. Addedv0.8.6

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnly=true, destructive=false, openWorld=true, so the safety profile is settled. The description adds genuinely useful operational context, notably that traces are expensive and filtered windows should stay under 5,000 blocks, and that transaction_hash requires pinning the block or a <=1,000-block window. That is real value beyond the annotations, though it stops short of stating row limits per type or what partial results look like when the scan cap is hit.

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?

The one-line summary is front-loaded and every section is headed, so an agent can skim to the relevant block. However, COMMON USER ASKS, FIRST CHOICE FOR and WHEN TO USE restate the same three scenarios in slightly different words, and the EXAMPLES repeat them a fourth time, which is more repetition than the content needs.

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?

For a 23-parameter tool this is unusually complete: cost/cap guidance, the prerequisite step to resolve a block when transaction_hash is unknown, alternate time-window inputs, and concrete request payloads. With an output schema present, the description does not need to explain return shapes and correctly does not.

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 coverage is 100%, so every one of the 23 parameters is already documented in the schema, and the description adds little parameter-level meaning beyond naming the filter dimensions. The three worked examples do show how filters combine (type + call_to + method, type + create_from), which carries more weight than prose alone, but they still do not explain interaction rules like method merging with call_sighash.

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 EVM traces') and enumerates the exact trace types covered (internal calls, creations, self-destructs, block rewards) plus the available filters. It clearly separates itself from portal_evm_query_transactions and portal_evm_query_logs, which it names as the cheaper tools for shallower data.

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?

Includes explicit WHEN TO USE bullets, a DON'T USE section that routes to top-level transaction and log tools, and a FIRST CHOICE FOR section for internal call trees and deploys. It also rules out state diffs entirely, so an agent knows where this tool's coverage ends.

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