Skip to main content
Glama
laszlopere

mcp-bytesmith

by laszlopere
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

eth_userop_hash

Compute the ERC-4337 userOpHash: an operation's id and signing digest.

Instructions

Compute the ERC-4337 userOpHash: an operation's id and signing digest.

The hash binds the operation to entry_point and chain_id, so the same operation cannot be replayed against another EntryPoint or another chain. version decides the rule and defaults to reading it off the canonical EntryPoint address (0.6 0x5FF1…2789, 0.7 0x0000000071727De2…da032, 0.8 0x4337084d…f108, the same on every chain); pass it explicitly for a custom deployment. v0.6 encodes six separate gas fields; v0.7 packs verificationGasLimit/callGasLimit and maxPriorityFeePerGas/maxFeePerGas into one word each (16 bytes apiece, high half first); v0.8 hashes that same packed struct as EIP-712 typed data. The unpacked eth_sendUserOperation JSON is accepted for v0.7/v0.8 and packed here, which is the fiddly half. Returns {version, entry_point, chain_id, user_op_hash} plus the intermediate values — op_hash for 0.6/0.7, domain_separator and struct_hash for 0.8 — and packed (the words that were hashed) for 0.7/0.8. signature is never read: it signs this hash, so it cannot be part of it.

Example: eth_userop_hash(user_op, "0x0000000071727De22E5E9d8BAf0edAc6f37da032",

  1. -> version="0.7", user_op_hash="0x…".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_opYesThe ERC-4337 user operation as JSON, in the shape a bundler speaks. v0.7/v0.8 accept either the packed form (accountGasLimits/gasFees/initCode/paymasterAndData) or the unpacked eth_sendUserOperation form (factory+factoryData, verificationGasLimit+callGasLimit, maxPriorityFeePerGas+maxFeePerGas, paymaster+paymasterVerificationGasLimit+paymasterPostOpGasLimit+paymasterData). camelCase and snake_case keys are both understood; `signature` is ignored, being what signs this hash. A stringified JSON object is accepted.
versionNoEntryPoint version, which decides the hashing rule. 'auto' reads it off a canonical EntryPoint address.auto
chain_idYesThe chain id the operation is valid on (int, decimal string, or 0x-hex); part of the hash.
entry_pointYesThe EntryPoint contract address the operation is sent to — part of the hash, so the operation cannot be replayed against a different one. Also selects the version when `version` is 'auto'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.6/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 richly: it explains the replay-protection binding to entry_point/chain_id, the per-version encoding rules (six gas fields vs packed 16-byte words vs EIP-712), and the critical behavioral fact that `signature` is never read because it signs this hash.

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?

Dense but front-loaded, leading with the purpose and following with version rules, return shape, and a worked example. Nearly every sentence carries technical weight, though the version-address enumeration is long and could be tightened.

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?

For a complex, nested-object tool with no output schema and no annotations, the description is complete: it enumerates return fields (op_hash, domain_separator, struct_hash, packed), covers input-form flexibility, and supplies a concrete example.

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% (baseline 3), and the description still adds meaning: `version`'s auto-detection from the canonical EntryPoint addresses, and `entry_point`'s dual role as both a hash input and the version selector. It clarifies semantics the schema only gestures at.

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 precise verb+resource: 'Compute the ERC-4337 userOpHash: an operation's id and signing digest.' This clearly distinguishes it from siblings like eth_hash, eth_sign, and eth_tx_codec, and an agent can tell immediately what the tool produces.

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?

Gives strong internal guidance: version defaults to reading the EntryPoint address, pass it explicitly for custom deployments, and v0.7/v0.8 accept the unpacked eth_sendUserOperation JSON which gets packed here. It does not explicitly route against sibling tools (e.g. when to prefer eth_hash or eth_sign), so it falls just short of the top band.

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

Deploy Server

Other Tools