Skip to main content
Glama
laszlopere

mcp-bytesmith

eth_log_decode

Turn a receipt log's topics and data into named event arguments.

Instructions

Turn a receipt log's topics and data into named event arguments.

signature is human-readable, e.g. "Transfer(address indexed from, address indexed to, uint256 value)"; indexed is what splits the arguments between topics and data. Returns {signature (canonical), anonymous, topic0, topic0_matches, args}; topic0 and topic0_matches are omitted for an anonymous event, which carries no topic0 to check. args lists EVERY argument in declaration order — indexed and not, interleaved — as {name (null when undeclared), type, value, indexed}, plus components on tuple args. Only a value type (uintN/intN/bool/address/bytesN) survives in a topic: every array, every struct, and bytes/string are keccak-hashed into it, so those come back with value null plus {hashed: true, hash} — enough to match against keccak of a candidate, never the value itself. A topics[0] that is not this signature's topic0 is soft (topic0_matches false, plus log_topic0 and reason), but a topic COUNT that contradicts the signature raises: ERC-20 and ERC-721 Transfer share a topic0 and differ only there.

Example: eth_log_decode("Transfer(address indexed from, address indexed to, uint256 value)", [topic0, from_word, to_word], "0x..0de0b6b3a7640000") -> args=[{name="from", ...}, {name="to", ...}, {name="value", ...}].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo0x-prefixed log data: the standard ABI encoding of the NON-indexed arguments. Omit (or pass '0x') when every argument is indexed.
topicsYesThe log's topics as 32-byte hex words (0x prefix optional): topic0 (the event's keccak signature hash) first, then one word per indexed argument. An anonymous event has no topic0. A stringified JSON array is accepted.
anonymousNoTrue when the event is declared `anonymous` in Solidity — its log carries no topic0, so indexed arguments start at topics[0] and up to 4 are allowed.
signatureYesA human-readable Solidity event signature, e.g. 'Transfer(address indexed from, address indexed to, uint256 value)'. The `indexed` modifier is what splits the arguments between `topics` and `data`; parameter names are optional and are reported back, and aliases (uint->uint256) are normalized away.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations the description carries the full burden, and it discloses error vs soft-failure semantics precisely: a mismatched topics[0] is soft (topic0_matches false plus log_topic0/reason), while a topic COUNT contradiction raises. It also explains hashed-value behavior (arrays/structs/bytes/string return value null with {hashed, hash}) and return-shape fields.

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?

Front-loaded one-sentence purpose followed by tightly packed detail, ending with a concrete example. Dense and mostly waste-free, though the run-on elaboration of return fields is heavier than strictly necessary.

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?

No output schema exists, so the description must explain return values — and it does comprehensively (signature, anonymous, topic0, topic0_matches, args with name/type/value/indexed/components). Nothing an agent needs to call it correctly is missing.

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 baseline is 3, but the description adds meaning beyond the schema: the human-readable signature example, the fact that `indexed` is what splits args between topics and data, and that parameter names are reported back and aliases (uint->uint256) are normalized.

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+resource: 'Turn a receipt log's topics and data into named event arguments.' Clear enough to distinguish from siblings like eth_revert_decode or eth_tx_codec, which operate on different inputs.

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?

The behavior is described thoroughly, implying the decode-a-log use case, but there is no explicit 'use this when / not when' or reference to alternatives such as eth_revert_decode or eth_calldata. Usage is inferred rather than stated.

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