Skip to main content
Glama

portal_evm_query_logs

Query EVM event logs filtered by contract address, topic signatures, or event aliases. Supports earliest or latest scan order and optional inline decoding.

Instructions

Query raw EVM logs with address/topic filters, common event aliases, earliest/latest scanning, and optional inline decoding.

COMMON USER ASKS:

  • Recent USDC Transfer logs

  • First recent USDC Transfer log

  • Latest ERC721/pass mint ID and tx hash

FIRST CHOICE FOR:

  • NFT or ERC721 mint lookups such as latest pass minted, token ID, and mint transaction hash

  • contract event questions where the user needs exact event evidence rather than wallet or transaction summaries

WHEN TO USE:

  • You need event logs filtered by contract or topic signature.

  • You want decoded log hints while still keeping the raw log shape available.

  • You want the first or last matching event in a bounded block/time window.

  • You want common event names such as transfer, approval, swap, mint, or burn instead of remembering topic0 hashes.

  • You need the latest ERC721/pass mint in a bounded deployment/recent window: filter Transfer events with topic1 as the zero address, use scan_order=latest, limit=1, and decode=true to expose decoded_log.decoded.token_id plus transaction_hash.

DON'T USE:

  • You only want token transfers, which are easier with the token-transfer tool.

EXAMPLES:

  • Recent USDC Transfer logs: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"event":"transfer","limit":20}

  • First recent USDC Transfer log: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"event":"transfer","scan_order":"earliest","limit":1}

  • Latest ERC721/pass mint ID and tx hash: {"network":"base-mainnet","from_block":46020000,"to_block":46100000,"addresses":["0xE4E70FdF2Fc1147a7f35c4c5de88E6BeA63eeAfA"],"event":"transfer","topic1":["0x0000000000000000000000000000000000000000000000000000000000000000"],"scan_order":"latest","decode":true,"include_transaction":true,"limit":1}

  • Decode logs inline: {"network":"ethereum-mainnet","timeframe":"1h","topic0":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"],"decode":true,"limit":10}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eventNoCommon event alias or topic0 hash. Examples: "transfer", "approval", "swap", "sync", "deposit", "withdrawal". Merges with topic0.
limitNoMax logs to return (default: 20, max: 200). Note: Lower default for MCP to reduce context usage.
cursorNoContinuation cursor from a previous response
decodeNoDecode known log signatures inline when topics/data are available
topic0NoEvent signatures (topic0). E.g., Transfer = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
topic1NoTopic1 filter (often: from address in Transfer, indexed parameter 1)
topic2NoTopic2 filter (often: to address in Transfer, indexed parameter 2)
topic3NoTopic3 filter (indexed parameter 3, chain-specific)
networkNoNetwork name or alias. Optional when continuing with cursor.
to_blockNoEnding block number. RECOMMENDED: <10k blocks for fast (<1s) responses. Larger ranges may be slow or timeout.
addressesNoContract addresses to filter (e.g., ['0xUSDC...', '0xDAI...']). IMPORTANT: Always include this or topics for fast queries.
timeframeNoTime range (e.g., '24h', '7d'). Alternative to from_block/to_block. Supported: 1h, 6h, 12h, 24h, 3d, 7d, 14d, 30d
from_blockNoStarting block number (use this OR timeframe)
scan_orderNoWhich side of the block window to scan first. Use earliest for first-event questions.latest
field_presetNoField preset: 'minimal' (address+topic0+block, ~80% smaller), 'standard' (all topics+timestamp), 'full' (includes raw data hex, largest). Use 'minimal' to reduce context usage.standard
to_timestampNoEnding timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
token_symbolsNoToken symbols to resolve via open token-list data and merge into addresses, e.g. ["USDC"].
finalized_onlyNoOnly query finalized blocks
from_timestampNoStarting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
response_formatNoResponse format: defaults to 'compact' for chat-friendly output, or stays 'full' when inline transaction context is requested. Use 'summary' for counting or categorizing.
include_transactionNoInclude parent transaction data
include_transaction_logsNoInclude all logs from parent transactions
max_token_symbol_matchesNoMaximum token-list matches to include per token symbol. Use addresses for deterministic single-contract filters.
include_transaction_tracesNoInclude traces for parent transactions
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses performance characteristics (recommend <10k blocks for speed), field presets for context reduction, and scanning order. While read-only is implicit, no destructive actions are indicated.

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-structured with clear sections and front-loaded summary. Uses bullet points and examples effectively. Some redundancy but overall concise given the tool's complexity.

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

Completeness3/5

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

No output schema, so description should explain return structure. It hints at decoded logs but doesn't fully describe output. Cursor usage mentioned but not elaborated. High parameter coverage partially compensates, but lacks output details.

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?

All 24 parameters have descriptions in the schema (100% coverage). The description adds value by explaining event aliases, scan_order usage, field_preset effects, and token_symbols resolution, going beyond the schema.

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?

The description clearly states the tool's purpose: 'Query raw EVM logs with address/topic filters, common event aliases, earliest/latest scanning, and optional inline decoding.' It includes specific use cases like NFT mint lookups and distinguishes from token transfer tool.

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?

Provides explicit WHEN TO USE conditions (5 points), a DON'T USE section (token transfer tool), and concrete examples. This guides the agent effectively on when to choose this tool over siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/subsquid-labs/portal-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server