Decode raw calldata into function name and typed arguments using a provided ABI on Ethereum mainnet. Pure computation — no RPC call needed. Pass the hex calldata from a transaction input or eth_call.
| Name | Required | Description | Default |
|---|---|---|---|
| abi | Yes | Contract ABI as a JSON array of ABI items, or a JSON-encoded string of that array | |
| calldata | Yes | Raw calldata (0x-prefixed hex) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds valuable context: it is a 'pure computation' with no network dependency, which is not explicitly stated in the annotations. This helps the agent understand performance and dependency characteristics beyond the standard safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and each sentence adds meaningful information. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with 100% schema coverage and good annotations, the description fully covers the tool's purpose, input requirements, and execution model. It also mentions the output (function name and typed arguments), which compensates for the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage of both parameters with descriptions (calldata pattern and ABI type). The description adds a minor semantic hint ('using a provided ABI' and 'pass the hex calldata') but does not go beyond what the schema already conveys. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('decode') with a precise resource ('raw calldata') and clearly states the outcome ('function name and typed arguments'). It distinguishes from sibling tools by specifying 'raw calldata' and 'ABI', which differentiates it from decode_log, decode_return, decode_revert, and encode_calldata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool (when you have raw calldata and an ABI) and highlights that it requires no RPC call, implying a lightweight alternative to eth_call. It does not explicitly name alternative tools, but the context and phrasing ('no RPC call needed') signal appropriate use cases and boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool has a clearly distinct purpose with no ambiguity. The tools are organized into two parallel sets (Ethereum and Mezo) with identical functions, each targeting specific operations like contract calls, data decoding, and batching. Descriptions explicitly differentiate between read-only calls, pure computations, and revert handling, ensuring agents can easily select the correct tool.
Tool names follow a highly consistent verb_noun pattern with a clear prefix (eth_ or mezo_) for network distinction. All tools use snake_case uniformly, and verbs like 'call', 'decode', and 'encode' are applied predictably across both sets, making the naming scheme intuitive and easy to parse.
The 13 tools are well-scoped for an advanced blockchain MCP, covering essential operations for two EVM-compatible networks. Each tool earns its place by providing distinct functionality, such as contract interactions and ABI decoding, without redundancy. The count is appropriate for the domain, enabling comprehensive coverage without being overwhelming.
The tool surface is complete for its stated purpose of advanced blockchain interactions, offering full CRUD-like coverage for read-only operations and data decoding. It includes contract calls, multicall batching, and comprehensive decoding for calldata, logs, returns, and reverts on both Ethereum and Mezo, with no obvious gaps that would hinder agent workflows.