elysium-chain-mcp

Get event logs

get_logs

Read-onlyIdempotent

Query event logs over a block range, filtering by contract address or event signature/topics to decode and return matching logs.

Instructions

Query event logs over a block range. Filter by contract address and either an event signature (with optional indexed-argument values) or raw topics. Without an address or topic filter the range is capped at MAX_LOG_BLOCK_RANGE blocks (default 2,000, about 3-7 minutes on Elysium); with one, any range is allowed. Either way the RPC returns at most 10,000 logs per query; split longer ranges or add filters if you hit that.

Input Schema

TableJSON Schema

Name	Required	Description
`abi`	No	Optional ABI used to decode logs (in addition to event). Either a JSON ABI (array of items, or a single item), or human-readable signatures such as ["function balanceOf(address owner) view returns (uint256)", "event Transfer(address indexed from, address indexed to, uint256 value)"].
`args`	No	Values for indexed event parameters, by name, e.g. {"from": "0x..."}. A list of values means "any of". Requires event.
`event`	No	Event to filter by, as a human-readable signature ("event Transfer(address indexed from, address indexed to, uint256 value)") or a JSON ABI event item. Matching logs are decoded.
`limit`	No	Maximum logs to return (default 1000). The response says if results were truncated.
`topics`	No	Raw topic filter (alternative to event): position-matched 32-byte hex values, a list for "any of", or null for wildcard.
`address`	No	Contract address, or a list of up to 20, that emitted the logs.
`toBlock`	No	Last block (inclusive): a number or tag. Defaults to latest.
`fromBlock`	Yes	First block (inclusive): a number or tag (latest, safe, finalized, earliest).

Output Schema

TableJSON Schema

Name	Required	Description
`logs`	Yes
`count`	Yes	Number of logs returned.
`toBlock`	Yes
`fromBlock`	Yes
`truncated`	Yes
`totalMatched`	Yes	Number of logs the node returned before applying limit.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Oct 2, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description goes beyond them by disclosing the range cap (MAX_LOG_BLOCK_RANGE, default 2,000, ~3-7 min on Elysium), the 10,000-log-per-query ceiling, and the mitigation (split ranges or add filters) – concrete limit behavior the annotations do not convey.

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?

Three sentences, front-loaded with the core action, then filtering options, then the constraint/limit caveat. No filler; each sentence adds operative information.

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?

An output schema exists, so return values need not be explained. Combined with annotations carrying the safety profile, the description covers action, filtering, and limits fully enough for an agent to invoke 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 a 3 baseline is warranted, but the description adds meaningful relational semantics: address filtering plus the choice between an event signature (with optional indexed-argument values) or raw topics. This clarifies the event/args-vs-topics alternative beyond the per-property schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Query) and resource (event logs) with a clear scope (over a block range) plus the two filtering mechanisms (address + event signature/args, or raw topics). It is distinguishable from siblings like get_transaction and get_block by resource, though it never explicitly names a sibling to route against.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides operational guidance on how filtering changes the allowed range and how to react to the 10,000-log cap, which is genuinely useful when-usage context. However, it never names an alternative (e.g., read_contract or get_transaction) or states when a different tool would be preferable, so routing guidance is only implied.

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

Deploy Server