elysium-chain-mcp

Read contract

read_contract

Read-onlyIdempotent

Call a view or pure function on a smart contract and return its decoded result without sending a transaction. Use this to read on-chain data at a specific block.

Instructions

Call a view or pure function on a contract and return its decoded result. Nothing is sent to the chain. For state-changing functions, use simulate_call.

Input Schema

TableJSON Schema

Name	Required	Description
`abi`	Yes	ABI containing the function (a single fragment is enough). 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	Function arguments in order. Integers may be numbers or decimal/0x-hex strings (use strings above 2^53). Tuples may be arrays or objects keyed by component name.
`block`	No	Block to read at. Defaults to latest. An integer block number or a tag: latest, safe, finalized, earliest, pending.
`address`	Yes	Contract address. 0x followed by 40 hex characters.
`functionName`	Yes	Name of the function to call.

Output Schema

TableJSON Schema

Name	Required	Description
`result`	Yes	Decoded return value. Integers are decimal strings; multiple outputs are an array or object.
`address`	Yes
`signature`	Yes	The resolved function signature, e.g. balanceOf(address).
`functionName`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Oct 2, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description reinforces this with 'Nothing is sent to the chain' and adds that the result is decoded, giving useful behavioral context beyond the flags, though it lacks detail on failure/call-revert behavior.

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 short sentences with zero filler; the functional statement is front-loaded and the routing note follows immediately. Every sentence earns its place.

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-value explanation is unnecessary, and rich annotations plus full schema coverage cover the structured fields. For a read-only call tool, nothing an agent needs to invoke it correctly is missing.

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 all five parameters (abi, args, block, address, functionName) are already documented in the schema. The description adds no further parameter meaning such as argument coercion or block-tag nuances, so the baseline of 3 applies.

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 (call), resource (view or pure function on a contract), and outcome (decoded result), which is unambiguous. It also distinguishes itself from the sibling simulate_call by name, so an agent can route without opening either 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?

Explicitly specifies the condition for using the alternative: 'For state-changing functions, use simulate_call.' This gives a clear when-to-use / when-to-use-something-else rule rather than leaving it to inference.

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

Deploy Server