Skip to main content
Glama
laszlopere

mcp-bytesmith

eth_calldata

Split calldata into named, typed arguments — or build calldata from them.

Instructions

Split calldata into named, typed arguments — or build calldata from them.

signature is human-readable, e.g. "transfer(address to, uint256 amount)"; parameter names are optional and come back as args[].name (null when the signature declares none), with args[].components naming a struct's members. action=encode (needs values) -> {action, signature (canonical), selector, calldata, args}; values may be omitted for a zero-argument signature. action=decode (needs data) -> {action, signature, selector, selector_matches, args}; ints are decimal strings and addresses EIP-55 checksummed. When the calldata's leading 4 bytes are not this signature's selector the arguments are still decoded, but selector_matches is false and data_selector + reason report the mismatch — the values are then almost certainly meaningless.

Example: eth_calldata("decode", "transfer(address to, uint256 amount)", "0xa9059cbb...") -> args=[{name="to", ...}, {name="amount", ...}].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo0x-prefixed calldata to decode: the 4-byte selector followed by the encoded arguments (required for action=decode).
actionYes'encode' a call's arguments into calldata, or 'decode' calldata into named arguments.
valuesNoArgument values to encode, positionally matching the signature's parameters; ints accept int/decimal/0x-hex, bytes are 0x-hex, tuples and arrays are nested lists. A stringified JSON array is accepted. Omit for a zero-argument signature.
signatureYesA human-readable Solidity function signature, e.g. 'transfer(address to, uint256 amount)'. Parameter names are optional and are reported back; data locations, aliases (uint->uint256) and a trailing 'external returns (...)' clause are normalized away.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.3/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 does so well: it discloses int-as-decimal-string and EIP-55 address formatting, the selector-mismatch behavior (still decodes but sets selector_matches=false, reports data_selector/reason, values likely meaningless), and the canonicalized output shape for both modes. These are exactly the behavioral traits an agent needs beyond the schema.

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?

The purpose is front-loaded in the first line, then mode-specific output shapes and an end-to-end example follow in a logical order with no filler. The dense inline-code styling makes the middle passage slightly harder to parse than it needs to be, but every element 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?

There is no output schema, so the description must document returns itself, and it does: it specifies the returned fields for both encode and decode, the canonical signature/selector, checksum/decimal formatting, and the failure-mode fields. For a two-mode codec this is complete.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning: it ties `values` to encode and `data` to decode, notes names come back as args[].name and struct members as args[].components, and explains signature normalization. This goes modestly beyond what the schema already states.

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?

The first sentence states a precise bidirectional verb+resource: split calldata into named typed arguments, or build calldata from them. An agent immediately knows this is a calldata<->args codec. It never explicitly contrasts itself with the closely-related sibling abi_codec, so sibling differentiation is left to inference.

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

Usage Guidelines4/5

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

It clearly explains the internal action selection: action=encode needs `values`, action=decode needs `data`, and `values` may be omitted for a zero-argument signature. That is strong context for choosing a mode, but there is no guidance on when to pick this tool over an alternative like abi_codec.

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