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

Annotations declare readOnlyHint=true, so the description doesn't need to restate safety. It adds useful behavioral context by explaining the exact hashing formulas for each kind, including the note that keccak_words matches hand-written assembly MSTORE behavior. However, it doesn't disclose edge cases like whether keys are left-padded or right-padded, or what happens with invalid input.

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 compact and front-loaded with the core purpose ('Derive storage slots'), then efficiently enumerates the kinds. Each kind's formula is stated in a single clause. The only minor issue is that the list of kinds is dense and could be slightly more scannable, but it earns its place.

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 computation tool with readOnlyHint=true and no output schema, the description covers the main formulas but leaves gaps: it doesn't specify the expected input format (hex vs decimal), the output format (32-byte hex?), or how nested_mapping ordering maps to the 'keys' array. These are important for an agent to call it correctly without guessing.

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?

Schema description coverage is 86%, so the schema already documents most parameters. The description adds meaning by explaining the formulas that connect parameters (e.g., pad32(key).pad32(slot) for mapping), which goes beyond the schema. However, it doesn't clarify the exact format of key/slot strings (hex? decimal?) or how nested_mapping applies left to right in terms of parameter order.

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 states a specific verb ('Derive') and resource ('Solidity storage slot'), and enumerates the supported kinds, which distinguishes it from sibling tools like read_storage or eth_call. However, it doesn't explicitly name a sibling alternative or contrast itself, so it's clear but not fully differentiated.

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 implies usage by listing the kinds and their formulas, but it doesn't explicitly state when to use this tool vs alternatives like read_storage. It provides no exclusions or conditions, so an agent must infer that this is for computing slots rather than reading them.

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

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

The description discloses meaningful behavioral detail beyond the readOnlyHint annotation: it explains that the output consists of a selector, 32-byte words, address-like flags, and possibly a function name. This gives the agent a clear mental model of what the tool computes, though edge-case behavior is not covered.

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?

A single, well-structured sentence that front-loads the core action and uses no filler. Every clause contributes specific operational detail, making it compact and immediately useful.

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 simple one-parameter, read-only tool, the description covers the main output behavior well. It omits guidance on malformed or non-word-aligned calldata, but given the low complexity and the readOnlyHint annotation, the definition is largely sufficient.

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?

Schema coverage is 100% and the schema already describes 'data' as 'Calldata hex.' The description adds value by explaining how the data is interpreted—split into a 4-byte selector and 32-byte words—which clarifies what kind of input is expected beyond a generic hex string.

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 names a specific verb ('Split'), a precise resource ('calldata'), and detailed behaviors: extracting the 4-byte selector, splitting into 32-byte words, flagging address-like words, and naming known functions. This clearly differentiates it from siblings like function_selector and disassemble.

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?

There is no explicit guidance about when to use this tool versus siblings such as function_selector or eth_call. The intended use is only implied by the operational description, and no alternatives or exclusions are mentioned.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses significant extra behavior: it validates statically-resolvable jump targets, reports invalid jumps separately as `invalidJumps`, and explains the runtime consequence (revert, all gas consumed). This is genuinely useful context that annotations do not convey.

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?

Three dense sentences with no filler: purpose, input modes, then the critical caveat about jump targets. The most important operational detail is front-loaded, and every sentence earns its place.

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?

There is no output schema, so the description carries the burden of explaining the return shape. It names 'opcodes with program counters' and the `invalidJumps` field, which is enough for an agent to call the tool and interpret results. It could specify the full response structure or error behavior, but overall completeness is strong.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that `address` and `bytecode` are alternative inputs and that bytecode is a 'raw hex string.' This helps disambiguate the optional parameters, though it does not detail every parameter.

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 names a specific verb and resource: 'Disassemble bytecode into opcodes with program counters.' It also distinguishes the tool from siblings like get_bytecode (raw fetch) and decode_calldata (calldata decoding) by explicitly describing opcode-level output plus jump validation.

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 gives clear invocation context: 'Supply either an on-chain address or a raw hex string.' This tells the agent the two valid input modes. It does not explicitly name when-not-to-use or alternative sibling tools, but the context is clear enough for a read-only disassembly task.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds behavioral insight beyond annotations: 'Nothing is broadcast and no key is used' reinforces the read-only nature and explains the absence of state changes. It also reveals the tool's behavior of reporting whether the call reverted, which is useful. However, it doesn't mention error cases or edge conditions like invalid calldata, but this is minor given annotations.

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-loads the primary action and outcome, and adds the safety note. Every sentence earns its place: the first states the result, the second gives usage context. No fluff.

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?

Given the tool has 7 parameters, no output schema, and moderate schema coverage, the description covers the main use case and outcome. It doesn't list all parameter interactions, but for a simulation tool with readOnlyHint=true, an agent can infer that it is a safe probe. The description could benefit from noting that the call is executed in a simulated environment and may not reflect actual future state, but this is a minor gap.

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?

Schema description coverage is 57%, meaning some parameters (to, from, block, value) lack descriptions. The overall description mentions 'calldata and value combinations', which hints at the relevance of data and value parameters. It does not add detail on 'to', 'from', 'block', or 'value' beyond schema, but the description's mention of probing combinations partially compensates. Since coverage is moderate, the description adds moderate value but could provide more per-parameter explanation.

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 clearly states the tool performs a read-only eth_call simulation and reports success/revert status, distinguishing it from mutation tools. It specifies the verb 'Simulate', the resource 'call', and the output (returned or reverted). It names the sibling tools that serve similar but distinct purposes (like get_bytecode, read_storage), helping an agent differentiate.

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 explicitly states when to use this tool: 'Useful for probing which calldata and value combinations a contract accepts.' It implicitly warns against using it when actual transaction execution is desired, since it says nothing is broadcast and no key is used. It doesn't explicitly mention alternatives, but the sibling context provides the differentiation. This is strong guidance.

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

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

Annotations already set readOnlyHint=true, so the safety profile is covered. The description adds that this is a pure computation ('Compute') but does not discuss error behavior, invalid-signature handling, or output formatting. It is coherent with annotations and provides no contradicting information, but adds limited behavioral context beyond what annotations provide.

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 entire description is a single sentence with an illustrative example and zero filler. The core action and input type are front-loaded, making it easy to parse quickly.

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 simple read-only compute tool, the description is mostly complete: it names the input format and the output concept (4-byte selectors). However, since there is no output schema, it does not specify whether selectors are returned as hex strings with a '0x' prefix or in some other encoding. This is a minor gap for such a straightforward utility.

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 already documents the 'signatures' parameter with 'Canonical signatures, no argument names or spaces,' giving 100% coverage. The description's example reinforces the expected format but does not add meaning beyond the schema, so the baseline score of 3 is appropriate.

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 opens with the specific verb 'Compute' and resource '4-byte selectors from canonical signatures,' making the tool's function immediately unambiguous. The example 'transfer(address,uint256)' anchors the expected input and clearly distinguishes this from siblings like decode_calldata or compute_storage_slot.

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 gives a concrete example and specifies the input as 'canonical signatures,' which implies when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the narrow scope leaves little ambiguity; an agent can infer this is for signature-to-selector conversion and not for decoding calldata or reading storage.

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

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

Annotations already establish readOnlyHint and openWorldHint. The description adds behavioral detail beyond annotations: it invokes eth_getCode, returns size and hex, and explains that an empty result means the address is an EOA or has no code.

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?

Three short sentences front-load the action and resource, then add return shape and an important edge-case interpretation. No wasted words or redundant restatement of schema fields.

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 read-only tool with complete schema descriptions and no output schema, the description covers core invocation and return interpretation. It could specify the exact representation of 'size and hex' more precisely, but that is a minor gap.

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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra parameter-level guidance, leaving the baseline of 3 appropriate.

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 ('Fetch') and resource ('contract's deployed runtime bytecode'), names the underlying method eth_getCode, and notes return content and empty-result meaning. This clearly distinguishes it from siblings like read_storage or disassemble.

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 purpose implies when to use it: when you need deployed runtime bytecode. However, it does not explicitly contrast it with sibling tools such as disassemble or eth_call, nor does it state when not to use it.

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

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

The readOnlyHint annotation already declares the tool as read-only, and the description adds behavioral context by stating it lists chain IDs and explorers, and that custom networks are handled elsewhere. This supplements the annotation without contradiction.

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?

Two sentences, both directly useful. The first states the core function, the second clarifies a related behavior (custom networks) without verbosity. No wasted words.

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?

Given zero parameters, no output schema, and a readOnlyHint, the description fully covers what an agent needs: what the tool returns (chain IDs and explorers) and the important note that custom networks are handled via rpc_url elsewhere. Nothing essential is missing for a simple listing tool.

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 tool has zero parameters, so the baseline is 4. The description adds value by specifying what the output contains (chain IDs and explorers), which is the only semantic needed for a parameterless listing tool.

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 (List) and resource (built-in EVM chains) and specifies the key output fields (chain IDs and explorers). It clearly distinguishes itself from the sibling tools, which are all about code analysis or execution, not chain enumeration.

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 implies when to use the tool: when you need to know which built-in chains are available. It also notes that custom networks don't require listing ('Any other network works by passing rpc_url'), which prevents misuse. However, it does not explicitly name an alternative or state when not to use it, but the purpose itself is self-explanatory.

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

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

Annotations already mark the operation read-only and open-world; the description adds useful context by naming eth_getStorageAt and specifying the return shape: a 32-byte word plus uint and address interpretations. It does not discuss block defaulting or edge cases, but it meaningfully extends the annotation-only information.

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 a single front-loaded sentence: the first clause names the action, resource, and RPC method, and the second specifies the return format. There is no filler or redundant restatement of the tool name.

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 read-only storage getter with two required parameters, the description plus schema provides the essential information: address, slot, chain, RPC override, and the expected return values. The main missing context is the semantics of the optional block parameter and explicit guidance on sibling alternatives, but these are relatively minor gaps.

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 schema documents slot, chain, and rpc_url, but address and block have no descriptions. The description does not clarify the ambiguous block parameter or add per-parameter meaning; it mainly reinforces the operation-level behavior. With 60% schema coverage, this is adequate but leaves gaps unaddressed.

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 states a specific operation ('Read a raw storage slot via eth_getStorageAt') and identifies the resource as contract storage. It distinguishes itself from siblings like get_bytecode or eth_call by emphasizing raw storage and naming the exact RPC method.

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?

There is no explicit guidance on when to use read_storage versus compute_storage_slot, eth_call, or get_bytecode. The description does not mention alternatives, exclusions, or conditions, so the agent must infer usage from the sibling list and tool name.

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