Skip to main content
Glama
laszlopere

mcp-bytesmith

eth_bytecode

Disassemble EVM bytecode, scrape its selectors, or read its solc metadata.

Instructions

Disassemble EVM bytecode, scrape its selectors, or read its solc metadata.

code is hex runtime bytecode. The trailing solc CBOR metadata is data, not code, so it is excluded from both the disassembly and the selector scrape and reported as metadata_offset instead. action=disassemble -> {size, code_size, count, offset, instructions} with each instruction {pc, opcode, name} plus push_data for PUSH1..PUSH32; an unassigned byte has name null and unknown, and code ending mid-immediate is flagged truncated. Output is capped at limit instructions, which adds {truncated, next_offset} — page with offset, or pass limit=0 for all. action=selectors -> {count, selectors, sites}: every PUSH4 the dispatcher then compares (EQ, or GT/LT in solc's binary-search dispatcher), decoded rather than grepped, so a PUSH4 pattern inside another push's immediate cannot masquerade as one. sites gives the {selector, pc, op} of each comparison. This is a heuristic on unstructured code: an ERC-165 interface id is a PUSH4 compared with EQ and is indistinguishable from a selector here, and an unconventional dispatcher may hide one. Feed the results to abi_inspect's selectors map (or a 4-byte database) to name them. action=metadata -> {present, offset, length, cbor, metadata} plus solc_version and, when the hash is an IPFS CIDv0 multihash, ipfs_cid. Code compiled with metadata stripped returns present=false, not an error.

Example: eth_bytecode("selectors", "0x6080...") -> selectors=["0xa9059cbb", "0x70a08231"].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesContract bytecode as hex (0x prefix optional) — the DEPLOYED runtime code, as returned by eth_getCode. Creation bytecode also decodes, but its constructor carries the runtime code as an inline blob, so the tail disassembles as data.
limitNoaction=disassemble only: how many instructions to return; 0 removes the cap and returns all of them.
actionYes'disassemble' decodes the code into instructions; 'selectors' scrapes the function selectors out of its dispatcher; 'metadata' parses the trailing solc CBOR metadata.
offsetNoaction=disassemble only: index of the first instruction to return (not a byte offset), for paging through a large contract.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.7/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 delivers: it discloses that CBOR metadata is excluded and reported as metadata_offset, that output is capped with truncated/next_offset paging flags, that an ERC-165 interface id is indistinguishable from a selector, that unconventional dispatchers may hide selectors, and that stripped metadata returns present=false rather than erroring.

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?

Front-loaded with a one-line purpose, then a short note on the `code` input, then a per-action block for each of the three modes. Despite its length, every sentence carries technical payload (edge cases, return shapes, caveats) rather than filler.

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, and the description fully documents the return shape for all three actions, including edge cases and a worked example. For a complex multi-mode tool, an agent has everything needed to call and interpret it 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 the baseline is 3. The description goes beyond the schema by explaining how parameters interact — paging via `offset` when a result is truncated, and limit=0 removing the cap — plus clarifying that `code` is runtime (not creation) bytecode and why the creation tail decodes as data.

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?

Opens with a specific three-part verb+resource statement: disassemble EVM bytecode, scrape its selectors, read its solc metadata. This clearly distinguishes the tool from siblings like eth_selector and abi_inspect, and the per-action breakdown removes any ambiguity about scope.

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 gives clear context for each action and explicitly routes downstream work to `abi_inspect`'s `selectors` map (or a 4-byte database). It does not, however, state when to prefer this tool's selector scrape over the sibling `eth_selector`, nor any explicit when-not conditions.

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