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

No annotations exist, so the description carries the burden. It discloses output formats for decoding (decimal strings, checksummed addresses) and the fact that packed mode is encode-only. Behavioral traits like error handling or performance are not covered, but key behaviors are explained.

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 concise with two short paragraphs and an example. It is front-loaded with the purpose. Some information is repeated from the schema but overall efficient.

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 5 parameters and full schema descriptions, the description covers actions, modes, types, and output format. It lacks error handling or constraints but is sufficiently complete for a encoding 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?

Schema coverage is 100% with parameter descriptions. The description adds value beyond the schema by explaining value formats, providing an example, and clarifying packed mode limitations.

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 explicitly states 'ABI-encode values or ABI-decode call/return/log data', which clearly defines the tool's functionality and distinguishes it from sibling tools like generic encode/decode or rlp_codec.

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 explains when to use encode vs decode and the packed vs standard mode, but does not explicitly exclude non-ABI use cases. However, the purpose is clear enough for an agent to infer usage context.

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?

With no annotations, the description carries the full behavioral burden and does so richly: it enumerates the return shape ({count, entries, selectors, topics}), the per-entry fields, the conditional `collisions` key, and the edge case that constructor/fallback/receive entries carry no signature or selector. This is exactly the disclosure a pure read-only tool needs.

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 first sentence front-loads the purpose, and subsequent sentences are dense with return-shape detail that earns its place given there is no output schema. It is somewhat long and packed, but not padded.

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?

No output schema exists, so the description must document returns, and it does so completely — top-level keys, per-entry fields, conditional fields, edge cases, and a worked example. An agent has everything needed to call and interpret it.

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, but the description adds real meaning beyond the schema: it clarifies the tool converts in either direction and illustrates acceptance of human-readable and JSON forms, reinforced by a concrete example call.

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?

States a specific verb and resource up front: 'List an ABI's entries with their canonical signatures and selectors.' It goes further to explain the bidirectional conversion, which clearly distinguishes it from siblings like abi_codec, eth_selector, and eth_calldata.

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?

Gives clear context for use: accepts either ABI representation and returns both, and names eth_calldata, eth_log_decode, and eth_revert_decode as consumers of its `selectors`/`topics` output. However, it offers no explicit when-not guidance or direct routing against the most similar sibling (abi_codec).

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?

No annotations are provided, so the description must cover all behavioral aspects. It explains the cryptographic derivation process, that the derived private key is returned, the input seed is never echoed, and the return object structure. It does not mention side effects (none expected) but is informative overall.

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 paragraphs plus an example, well-structured with clear purpose, algorithm, return values, and a concrete example. Every sentence adds value, 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?

With 3 parameters and no output schema, the description covers purpose, algorithm, return object, and example. It is complete enough for an agent to understand what the tool does and how to invoke it.

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 baseline is 3. The description adds value beyond schema by explaining the path format (BIP-32/44, hardened steps), that the seed is not echoed, and providing an example. This enhances understanding of parameter usage.

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 derives an HD child key and Ethereum address from a seed along a BIP-32/44 path, specifying the verb, resource, and constraints. It distinguishes from siblings like bip39 (seed generation) and derive_key (general derivation) by focusing on BIP-32 path derivation.

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 includes a detailed example and explains the input format, guiding users to provide a seed rather than a mnemonic. However, it lacks explicit when-to-use or when-not-to-use statements compared to sibling tools, though implicit guidance is present.

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?

With no annotations provided, the description fully discloses behavioral traits: it explains that invalid mnemonics in to_seed raise errors while validate returns a reason, describes the PBKDF2 derivation, and states that sensitive inputs are never echoed back.

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 well-structured with bullet points for each action and includes a concrete example. It is slightly verbose with repeated phrases like 'never echoed back,' but overall efficient.

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 complexity of 5 parameters and no output schema, the description fully explains return value structure for each action, error handling, and format details (e.g., seed as 0x-hex). It leaves no 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 input schema covers all parameters with 100% descriptions. The description adds value by explaining determinism with entropy for generate and the security implication of the passphrase (wrong passphrase yields a different seed).

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 that the tool generates, validates, or converts BIP-39 mnemonics to seeds, with each action's specific output. This distinguishes it from sibling tools like bip32_derive, which operates on seeds rather than mnemonics.

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 provides explicit guidance for when to use each action (generate, validate, to_seed) and warns about error behavior for invalid mnemonics. However, it does not explicitly contrast with alternative tools, though the sibling context makes the purpose clear.

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?

With no annotations, the description fully discloses behavior: it covers byte swapping logic, width-based grouping and padding, handling of equal orders, and return format. There are no contradictions or omissions.

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 concise (single paragraph) and front-loaded with the core purpose. It could be slightly more structured (e.g., bullet points), but every sentence adds value and there is no redundancy.

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's complexity (6 parameters, byte order conversion), the description is remarkably complete. It explains all parameters, edge cases (different widths, equal orders), and the return format, leaving no 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?

Despite 100% schema coverage, the description adds significant value beyond the schema: it explains 'host' resolves to sys.byteorder, clarifies width's array semantics, and provides a concrete example, greatly aiding parameter understanding.

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 verb 'Convert a value between host and network byte order' and specifies the resource. It also mentions analogous functions (htons/htonl/ntohs/ntohl) and provides an example, making the purpose highly specific and distinguishable from siblings like decode or hash.

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 explains when to use the tool (byte order conversion) and thoroughly details each parameter's role. However, it does not explicitly state when not to use it or directly compare with alternatives, though siblings are distinct enough.

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?

No annotations provided, so description fully covers behavior: pad never truncates, trim is inverse, slice uses Python indexing, prefix adds/strips 0x. It also describes the return format and provides an example, ensuring transparency.

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 well-organized with a clear list of actions and concise bullet points. Every sentence provides necessary information, and the example is helpful without being verbose.

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 8 parameters, no output schema, and no annotations, the description thoroughly covers all actions, parameters, and return values. The example addresses a common use case, making it complete for an editing 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?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining action-specific parameter usage (e.g., fill defaults to '00', side defaults to 'left') and gives context for how parameters interact. The example further clarifies parameter semantics.

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 it edits a hex byte-buffer with actions like pad, trim, slice, concat, size, and prefix. It distinguishes itself from sibling tools which are for encoding, hashing, etc., by focusing on low-level hex manipulation.

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?

Each action is described with specific use cases (e.g., pad to widen, trim to strip). It does not explicitly state when not to use, but the sibling tools are very different so context makes it clear. Could be improved with a note about intended vs. unintended inputs.

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?

No annotations provided, so description fully carries burden. Explains the two-step process (encode then decode), fallback behavior (hex output), error handler options, and return format. No contradictions.

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?

Description is efficient, front-loaded with main purpose, then details. Could be slightly more concise but no fluff. Every sentence adds value.

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?

No output schema, but description lists return fields. Covers all parameters, behavior, and provides an example. Complete for a transformation 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?

Schema coverage is 100%, baseline 3. Description adds value beyond schema by explaining the purpose of each parameter, the encoding/decoding logic, and providing an example. The errors parameter default and options are clarified.

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?

Description states specific verb+resource: 'Convert text between character encodings (e.g. latin-1/cp1252 <-> utf-8)'. Clearly distinguishes from siblings like 'decode' and 'encode' by focusing on charset transcoding.

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?

Provides clear context for use (converting between encodings) but does not explicitly state when not to use or list alternative tools. Implicitly differentiated from siblings by its specific purpose.

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 key behaviors: it returns one entry per Unicode scalar, keeps astral characters whole, and explains the count vs len() difference. Since no annotations are provided, the description carries the burden, and it does so well, though it could mention any assumptions about input handling.

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 concise, with a clear purpose statement, detailed output explanation, and a helpful example. Every sentence adds value; 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's simplicity (one parameter, no output schema), the description fully explains the return value fields and behavior. The example clarifies usage.

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 single parameter 'text' is already described in the schema. The description adds significant value by explaining the output structure and providing an example, exceeding the baseline for high schema coverage.

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 breaks text into code points with names and UTF-8/16/32 byte views. It uses specific verbs and resource details, and distinguishes from sibling tools like 'decode', 'encode', and 'unicode_normalize' which have different purposes.

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 the tool is for obtaining detailed code point information, but it does not explicitly state when to use it versus alternatives or when not to use it. No comparison to siblings is provided.

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?

No annotations provided, so description carries full burden. It thoroughly describes actions, encoding options (base64 vs percent), defaults, input/output formats, and includes an example. Behavioral traits are well 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?

Description is front-loaded with main purpose, uses effective line breaks. Every sentence adds value, though some technical detail could be condensed. Overall efficient.

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?

No output schema, so description should detail return values. It describes parse returns (media_type, parameters, is_base64, decoded data) but lacks exact structure. Build returns URI but no format details. Adequate but incomplete.

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%, baseline 3. The description adds value by explaining parameter dependencies (e.g., action determines which params needed), defaults, and provides an example illustrating usage.

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 builds or parses data: URIs per RFC 2397, with specific verbs and resource. It distinguishes between build and parse actions, and the name and description are unambiguous.

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 explains when to use build vs parse and required parameters, but it does not provide guidance on when not to use this tool compared to sibling tools like encode/decode or charset_transcode.

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?

No annotations exist, so the description must convey behavior. It details return fields, including scheme, decoded, output_format, and hrp for bech32. It mentions per-scheme options and extra requirements for base58/base58check/base45/idna, providing behavioral context beyond a simple decode.

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 front-loaded with the core purpose, followed by essential details in a logical order. Every sentence earns its place, including the example. Despite covering many schemes and options, it remains succinct and easy to parse.

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 complexity (many schemes, no output schema), the description covers return values, options, and output format guidance. It misses explicit error handling or invalid input behavior, but overall it provides sufficient completeness for most use cases.

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% with descriptions, but the tool description adds significant value: it explains the role of options for base58/base62, clarifies that base58/base58check/base45/idna need the encoding extra, and advises on output_format for binary data. This goes well beyond the schema.

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 begins with a clear verb and resource: "Decode a base-N/URL/IDNA/bech32/hexdump string back to bytes or text." It distinguishes from the sibling tool 'encode' by stating it is the inverse, leaving no ambiguity.

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 as the inverse of encode, but does not explicitly state when not to use it. It does provide guidance on output_format for binary payloads, which aids appropriate usage.

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?

With no annotations provided, the description fully discloses behavioral traits: determinism (same inputs always yield same key), omitted salt implies empty salt (not random), password never echoed back, and performance differences between KDFs. This provides essential behavioral context for safe tool use.

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 concisely written (~150 words) with an effective structure: main purpose first, then details, then an illustrative example. Every sentence adds critical information without redundancy, making it efficient for an AI agent to parse.

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 complexity of KDFs and the lack of an output schema, the description covers all essential aspects: purpose, algorithm selection, determinism, return format (key, kdf, length, salt, params), and cross-reference to password_hash. It provides a complete mental model for correct tool invocation.

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?

Although schema covers all 6 parameters (100% coverage), the description adds significant value beyond the schema: explains the default salt behavior, the entropy requirements for kdf, the meaning of output_format ('bare hex, no 0x'), and details the params structure with example overrides. This enhances usability beyond what the schema alone provides.

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 verb 'derive' and resource 'raw key bytes from a password or secret via a KDF', and explicitly distinguishes from sibling tool 'password_hash' for password storage. This makes the purpose unambiguous and differentiates it from other tools.

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 provides explicit guidance on when to use each KDF variant (pbkdf2/scrypt for passwords, hkdf only for high-entropy secrets), warns against misuse of hkdf on passwords, and directs users to the sibling tool 'password_hash' for password storage. This meets the highest standard of usage clarity.

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?

No annotations provided, so the description fully discloses behavior: how data is decoded via input_format, per-scheme options, padding, alphabet, hrp, width, and bytes32 padding with round-trip note. It also specifies the return format. No contradictions.

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 well-structured with a clear overall statement, then per-parameter details and an example. It is slightly lengthy (~170 words) but each sentence provides valuable information; could be trimmed slightly but still good.

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's complexity (20 schemes, multiple options, no output schema), the description is comprehensive. It covers data decoding, scheme-specific options, bytes32 behavior, and return format. Missing only explicit mention of error cases, but schema enums handle validation.

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% but the description adds significant value: it explains the meaning of each parameter (data, scheme, input_format, options) with specific details (e.g., default for input_format, per-scheme options like padding, hrp, width). It also provides an example, enhancing understanding beyond the schema.

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 it encodes bytes/text into a string form using various schemes (base-N, URL, IDNA, bech32, hexdump, bytes32). It lists specific schemes and provides an example, making the purpose unambiguous and distinct from sibling tools like decode or hash.

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?

While it doesn't explicitly state when to use versus alternatives, the description gives clear context on how to use each scheme and parameter. The sibling tools are sufficiently different (e.g., decode, hash) that the purpose alone guides selection, but explicit guidance would be better.

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?

With no annotations, the description fully discloses behavior: it hashes as given, warns about normalization, rejects empty labels, and describes the output structure including an example. This is comprehensive.

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 plus a return explanation and example. Purpose is front-loaded, no unnecessary words. Every sentence adds value.

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's specificity and lack of output schema, the description covers purpose, input, output, and important edge cases (normalization, empty labels). It's complete for effective use.

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% with a detailed description. The description adds context about normalization and empty label rejection, going beyond the schema. A score of 4 reflects this added value.

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 computes EIP-137 namehash and labelhash of an ENS name. It uses a specific verb ('compute') and resource ('ENS name'), and the mention of EIP-137 distinguishes it from generic hash tools like 'hash' or 'eth_hash'.

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?

It explains the normalization prerequisite and rejection of empty labels, guiding correct usage. It could be more explicit about when not to use (e.g., for raw keccak256), but it's clear enough.

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?

No annotations are provided, so the description carries the full burden. It details the return structure for both actions, including the reason field for verify. It discloses input acceptance (any casing). It does not contradict 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 well-structured, starting with a high-level statement, then detailing two actions, and ending with an example. It is concise without missing key info, though slightly verbose in the example.

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 no annotations or output schema, the description covers the tool's behavior well: inputs, outputs per action, example. It lacks error handling info but is sufficient for a simple utility 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?

Schema coverage is 100%, but the description adds value by explaining the action enum in context and providing an explicit example showing parameter values and result. This goes beyond the schema alone.

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 applies or verifies EIP-55 checksum. It distinguishes between two specific actions (encode, verify) and describes their outputs, making the purpose precise and unambiguous.

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 explains the two actions and provides an example. While it doesn't explicitly compare to sibling tools, the context is unique enough that usage is clear. It could mention when not to use it but is mostly adequate.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations, the description fully discloses behavior: it is a pure computation ('Computes only — nothing is deployed'), explains the formula step-by-step, and describes the return type (EIP-55 checksummed address). No destructive side effects, no permissions needed, fully transparent.

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 relatively concise given the complexity—two paragraphs and an example. It front-loads the purpose and then details the two schemes. The formula blocks are necessary but add length. No wasted sentences; every part adds value.

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?

Despite no output schema, the description specifies the return format (address, EIP-55 checksummed). All parameters are covered, including defaults and requirements per scheme. The example provides a concrete test case. The description is complete for this computation-only 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?

Schema coverage is 100%, but the description adds significant value beyond the schema: it explains the mathematical role of each parameter (e.g., nonce is the deployer's transaction nonce, init_code is the full creation bytecode), includes a concrete example with expected output, and clarifies the distinction between create and create2 parameters. This goes well beyond the schema's syntactic descriptions.

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 computes CREATE or CREATE2 deployment addresses, with specific verb 'compute' and resource 'contract address'. It distinguishes between the two schemes explicitly, making the purpose unambiguous.

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 explains when to use each scheme (create needs nonce, create2 needs salt and init_code) and provides a formula. It does not explicitly list alternatives or when not to use, but the context from sibling tools is not needed as this is a standalone computation. The description implies usage by showing required parameters for each scheme.

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?

With no annotations, the description carries the load and does so well: it discloses the return shape ({address, public_key}), guarantees the private key is never echoed back, and notes that file-based keys appear in neither call nor result and are never quoted in errors. It could still mention error behavior for invalid keys, but the security-relevant traits are 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?

Front-loaded with the core purpose, then derivation detail, sibling comparison, and an example. It is on the longer side but each sentence carries distinct value; no obvious filler.

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?

No output schema exists, yet the description specifies the return object, the key-exclusion guarantee, the exact-one-of parameter constraint, and a worked example — everything an agent needs to call it correctly.

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 already 100%, so the baseline is 3; the description adds the mutual-exclusivity rule ('Exactly one of private_key or private_key_file is required') plus the rationale for the file variant (keeps the key out of the conversation), which goes beyond the schema.

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?

States a precise verb+resource: 'Derive an EOA's Ethereum address and public key from its private key.' It explicitly distinguishes itself from the sibling `eth_contract_address` as the EOA counterpart, so an agent can pick between them without opening schemas.

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?

Gives clear context ('derives, it does not create an account') and names the sibling it parallels, which helps route selection. It stops short of an explicit when-to-use/when-not statement against a concrete alternative scenario, so it is not a full 5.

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?

With no annotations and no output schema, the description carries the full burden and does so well: it spells out the return shape ({kind, hash}, plus {domain_separator, struct_hash} for eip712 and `preimage` for eip7702), explains the 0x05 replay-protection prefix, and clarifies the chainId=0 meaning. It does not cover error/edge-case behavior (e.g. malformed typed data or non-hex input), keeping it short of a 5.

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 purpose is front-loaded in the first line, followed by return shape, per-kind semantics, and a concrete example. It is dense but every clause carries information; the preimage/replay explanation is the only part that leans verbose for an invocation-time description.

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 4-parameter, 4-variant computation tool with no output schema, the description supplies the return structure for every kind, the key non-obvious gotchas, and a worked example, so an agent has everything needed to invoke it correctly.

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 already 100%, so the baseline is 3. The description adds genuine meaning on top: it notes that `input_format` is ignored for eip712/eip7702, that `data` is a parsed-JSON/dict or authorization tuple for those kinds, and what the chainId field means — beyond what the schema literally states.

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 (compute) and resource (Ethereum hash) and enumerates the exact four supported flavors (keccak-256, EIP-191, EIP-712, EIP-7702), which cleanly separates it from generic siblings like `hash`/`hmac` and from Ethereum signing/decoding tools such as `eth_sign` or `eth_userop_hash`.

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 text characterizes each `kind` well enough to imply when each applies, and it warns that keccak-256 is not SHA3-256, but it never states when to prefer a sibling (e.g. `hash`, `eth_sign`, `eth_userop_hash`) or any when-not-to-use rule. Guidance is implied rather than explicit.

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?

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden and does it well: it discloses every result branch (empty/error/panic/custom/unknown), the selector-mismatch behavior where decoding still succeeds but selector_matches is false, and a worked example. It does not say how malformed or non-hex input is handled, which is the remaining gap.

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?

Front-loaded with the purpose, then a structured kind-by-kind breakdown, then a concrete example. Dense but well organized; a few phrases (e.g. 'exactly as eth_calldata reports them') are slightly redundant, but nothing is wasted wholesale.

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 must specify the return shape — and it does so exhaustively for all five kinds plus the selector-mismatch case, which is everything an agent needs to interpret results from a pure decode 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?

Schema description coverage is 100%, so the baseline is 3. The description mostly reiterates the schema's account of `signature` (needed only for custom errors) and `data`, adding only marginal detail about the signature/selector relationship, so it does not meaningfully exceed the structured fields.

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?

States a specific verb+resource (decode a failed call's revert data) and immediately enumerates the discriminated result kinds, making it distinguishable from siblings like eth_calldata and eth_log_decode. An agent can tell what this tool does without opening the schema.

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?

Usage is only implied by the task-domain scoping (revert data from a failed call) and by the note that `signature` is needed for user-declared errors. It never explicitly states when to reach for this versus eth_calldata or abi_codec, nor any preconditions for obtaining the revert data.

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?

No annotations are provided, so the description carries full behavioral disclosure. It transparently states the return structure (kind, signature, selector/topic0) and mentions canonicalization of signatures. However, it does not cover error cases (e.g., invalid signature) or performance characteristics.

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 highly concise: two sentences plus an example. It front-loads the core purpose and uses minimal, precise language. Every sentence adds value—introducing functionality, detailing return values, and illustrating with an example.

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 derivation tool with no output schema, the description covers purpose, input parameter meaning, and return format. It provides sufficient context for an agent to use the tool correctly. Minor gaps include lack of error handling info, 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?

Input schema provides detailed descriptions for both parameters (signature normalization, kind enum), giving 100% schema description coverage. The description adds value by explaining the return format and providing an example, but does not significantly augment parameter semantics beyond schema.

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 derives a 4-byte function selector or 32-byte event topic from a signature, with specific verb 'derive' and resource 'signature'. It distinguishes between function and event via the kind parameter and provides a concrete example, leaving no ambiguity.

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 context (deriving selectors/topics for ABI encoding) but does not explicitly state when to use this tool versus alternatives like eth_hash or abi_codec. No when-not or exclusion criteria are given, leaving the agent to infer applicability.

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?

With no annotations, the description carries the full burden and does so well: RFC 6979 deterministic nonces matching eth_account/ethers, always-low-s (EIP-2), the key is read from a file by the server and never echoed or leaked in errors, and recovery failure is a soft error (valid false plus reason) rather than an exception. It stops short of stating global preconditions such as file-permission requirements or whether the tool is read-only across actions, so a 5 is not warranted.

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?

Dense but front-loaded: capability and the key semantic caveat (no EIP-191 prefix) come first, then per-action contracts, with a concrete example at the end. The block is long relative to a typical tool, but nearly every sentence carries a distinct constraint (determinism, low-s, no key echo, soft failure), so little is wasted.

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, and the description compensates by specifying the return shape for every action ({signature, r, s, v, yParity, eip2098, address}, {valid, recovered, low_s}, {address, low_s}, {format, result, low_s}). Together with the parameter-to-action mapping and the low_s caveat, an agent has everything needed to call and interpret results correctly.

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 3 baseline is met by the schema alone; the description goes beyond it by tying each parameter to an action, documenting the low_s distinction on the returned signature, and explaining why there is deliberately no inline key argument. It adds genuine interpretation rather than restating the schema.

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?

Opens with a specific verb set (sign, verify, ecrecover, reformat) over a named resource (secp256k1 signature over a 32-byte hash), then enumerates the four actions with their inputs and outputs. It explicitly distinguishes itself from the nearest name-collision sibling, the JSON-RPC eth_sign/personal_sign, by noting the absence of the \x19Ethereum Signed Message prefix.

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?

Gives explicit routing: hash first with eth_hash (naming kind=eip191 for personal_sign, eip712 for typed data), or pass eth_tx_codec's signing_hash or eth_userop_hash. Each action's required parameters are stated inline, so an agent can pick sign vs verify vs recover vs convert without opening the schema.

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?

With no annotations, the description carries the full burden and mostly meets it: it discloses the return shape ({slot, slot_hex}, plus formula/name/namespace), that every constant is derived by keccak rather than pasted from the EIP, and a specific preprocessing rule (the 'erc7201:' annotation prefix is stripped). It never explicitly asserts side-effect freedom or authorization, though 'Compute' plus the deterministic formula list make purity inferable.

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 first line states purpose, then a well-formatted per-layout block, then returns, then composition, then a concrete example. Long, but nearly every token is load-bearing formula or constraint, and it is front-loaded. Minor redundancy exists between the layout bullets and the equally detailed schema 'layout' description.

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?

No output schema exists, so the description must document the return value itself — and it does ({slot, slot_hex}, formula, name/namespace). For a tool with a nested, polymorphic object parameter and three branching layout families, the per-kind requirements, formatting rules for hex/decimal/int, and a worked example together leave nothing an agent needs in order to call it correctly.

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 already 100%, so the baseline is 3. The description goes beyond the schema by giving the derivation rationale behind each parameter's role in the formulas (key_type default uint256, nested mapping key lists, element_size in slots, index doubling as a struct offset for erc7201/diamond) and by explaining how a returned slot composes back into the 'slot' field. That compositional semantics is not present in the schema.

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?

Opens with a specific verb+resource: 'Compute a storage slot: a mapping/array entry, or a well-known layout's root.' The two modes of operation are named up front, so an agent can immediately distinguish this from siblings like eth_hash or eth_selector. No sibling names are used, but the domain-specificity is high enough that misselection against the keccak-family tools is unlikely.

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 layout enumeration effectively acts as a routing table: each kind states what it needs ('mapping -> needs "slot" and `key`', 'dynamic_array -> needs "slot" and `index`') and which are constant and need no slot. It also explains the composition workflow (feed a namespaced root back in as another layout's slot). What it lacks is any explicit statement of when to reach for this tool over eth_hash or abi_codec when a raw hash might suffice.

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?

No annotations exist, so the description carries the full burden and does so well: it discloses that encode does NOT sign, that `hash` is only meaningful once signed, how `signing_hash` is derived per tx type (typed, EIP-155, pre-EIP-155), and the exact v-computation for legacy signatures. This is exactly the behavioral context an agent needs to avoid producing an invalid transaction.

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?

Front-loaded with the two actions and their required inputs, with a worked example at the end. It is dense but largely earns its length, though the type-inference mapping and numeric-format notes are restated from the schema, adding some redundancy.

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?

No output schema exists, and the description compensates by specifying the return shape for both actions (type/raw/hash/signing_hash for encode; type/fields/hash/signing_hash/from for decode) plus formatting details like decimal strings and EIP-55 checksumming. Nothing an agent needs to call this correctly is missing.

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 baseline is 3, but the description goes beyond the schema by tying parameters together: the type-inference mapping, the rule that omitting v/yParity/r/s yields an unsigned tx, and that a legacy `chainId` is carried in v. That relational guidance is not expressible in per-field schema text.

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?

States a specific verb+resource pair ('Serialize tx fields into a raw transaction, or decode a raw tx') and immediately splits the two modes by action. An agent can distinguish this from rlp_codec, abi_codec, or eth_calldata from the first sentence alone.

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?

Clearly states which inputs each action requires (encode needs `fields`, decode needs `data`) and walks through the encode→sign→re-encode workflow for signing. It stops short of naming alternative sibling tools (e.g. rlp_codec for raw RLP), so it is clear context without explicit exclusions.

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?

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.

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.

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.

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.

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.

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.

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

In the absence of annotations, the description discloses the return object structure (algorithm, digest, output_format, bits) and additional int field for CRC/fast hashes. It explains parameter effects (length, key, seed) and algorithm-specific requirements. No side effects or rate limits are mentioned, but these are not expected for a hash function.

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 concise, using backticks for parameter names and a compact example. Each sentence adds value: purpose, parameter usage, return format, and example. No fluff, though it could be slightly shorter. Good structure.

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 7 parameters with 100% schema coverage and no output schema, the description covers return values, parameter usage for algorithm families, and gives an example. It is complete enough for a hash tool, though error handling or default behavior clarification (e.g., output_format default) is not explained.

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 baseline 3. The description adds significant meaning: it explains which parameters are required for specific algorithms (length for shake_*, key for blake2*, seed for xxh*/fnv1a_*), describes the return value with examples, and clarifies decoding behavior via input_format. This goes beyond schema descriptions.

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 'Compute a cryptographic, CRC, or fast non-crypto digest of bytes,' which is a specific verb-resource pair. It distinguishes from siblings like hash_file (file hashing) and hmac (keyed hashing) by listing algorithm categories and noting parameter requirements for specific algorithms.

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 specifies when certain parameters are required (e.g., length for shake_*, key for blake2*, seed for xxh*/fnv1a_*). It does not explicitly state when to use this tool vs siblings like hash_file or hmac, but the context of sibling tools and the clear algorithm list implies usage scope. An example is provided, aiding understanding.

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?

With no annotations provided, the description fully discloses behavioral traits: how different algorithms process the file (crypto streams in chunks; CRC/xxh/fnv reads whole), how verification compares digests (as bytes, tolerant to case/0x/whitespace), and the return structure including optional 'verified' field. This provides comprehensive transparency.

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 well-structured with key information front-loaded. It is slightly verbose but every sentence adds value. It could be slightly more concise, but overall it efficiently conveys necessary details without excessive wordiness.

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?

Despite lacking an output schema, the description thoroughly explains the return value structure (algorithm, digest, path, size, and optional verified). It covers all parameters, algorithm categories, verification behavior, and provides an example, making it fully complete for an agent to understand the tool's functionality.

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?

Although schema coverage is 100%, the description adds significant meaning beyond the schema: it explains the streaming vs. whole-file behavior for algorithm categories, details the verification comparison logic, and gives an explicit example. This enhances understanding of parameter usage and behavior.

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's purpose: 'Checksum a file on disk, optionally verifying it against an expected digest.' It uses a specific verb ('checksum') and resource ('file on disk'), and distinguishes itself from sibling tools like 'hash' by explicitly focusing on disk files.

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 implicitly guides usage by specifying the tool is for files on disk, and it describes behavioral differences between algorithm families (streaming vs. whole-file). However, it does not explicitly state when not to use this tool or mention alternatives (e.g., 'hash' for in-memory hashing), but the context is clear enough for an agent to select appropriately.

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?

With no annotations, the description carries the full burden. It discloses decoding of data/key, constant-time comparison for verification, tolerance of formatting in expected value, and the returned fields. It is transparent about the main behaviors.

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 concise, with two paragraphs and an example. It front-loads the main purpose and each sentence adds meaningful detail without redundancy.

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?

Despite 7 parameters, the description fully explains purpose, parameter roles, behavior (decoding, verification), and return values. No output schema exists, but the description compensates by listing returned fields.

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 baseline is 3. The description adds value by explaining decoding, constant-time comparison, and tolerance in expected format, beyond what the schema lists.

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 computes or verifies an HMAC authentication tag, specifying the verb and resource. It distinguishes from sibling tools like 'hash' and 'hash_file' by focusing on keyed HMAC authentication.

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 explains when to compute vs verify based on the 'expected' parameter. It does not explicitly mention alternatives, but the name and context imply its specific use for HMAC, which is clear enough for an agent.

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?

With no annotations, the description fully discloses key behaviors: randomness source (OS CSPRNG), determinism for v5, time-sortability for v7 and ulid, and return format. No destructive actions are implied, and all traits are accurately described.

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 well-structured, starting with a clear summary, then breaking down each kind systematically. No redundant sentences; each adds value. The example at the end is efficient and illustrative.

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's complexity (7 parameters, multiple modes) and no output schema, the description covers all necessary context: parameter dependencies, return structure, and example usage. It is fully self-contained for correct invocation.

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%, but the description adds substantial meaning beyond schema descriptions, explaining how each parameter affects output (e.g., version effects, default sizes, required combinations). The example further clarifies parameter interplay.

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 generates identifiers (UUID/ULID/nanoid) with specific verbs and resource types. It distinguishes between families and versions, providing a precise scope that differentiates from sibling tools like 'random' or 'hash'.

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?

While no explicit 'when to use' statement is given, the highly detailed description covers all variants and parameters, enabling an agent to infer appropriate contexts (e.g., deterministic IDs for v5, time-sortable for v7). No sibling tool duplicates this functionality, making usage unambiguous.

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?

No annotations exist, so the description fully discloses behavior: it reports system info with no side effects. The example provides concrete output format details.

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 concise, front-loaded with purpose, and includes a helpful example. 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?

For a zero-parameter tool with no output schema, the description fully covers the response format, keys, and example, making it complete.

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?

No parameters exist, baseline is 4. The description adds value by explaining the output fields beyond the empty schema.

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 as a discovery/health-check entrypoint, listing the six keys returned. It distinguishes from sibling tools that perform specific data transformations.

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 is self-evident for a health-check tool; no explicit when-not or alternatives are needed. It implicitly guides use for system availability and version checking.

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?

Without annotations, the description carries the full burden. It explains accepted prefixes, non-decimal output prefixing, pad_bytes behavior (minimum, never truncating, bit-aligned, rejected for decimal), arbitrary precision, and return keys. It lacks error handling details but is otherwise thorough.

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 concise at four sentences, well-structured with purpose first, then details, then example. No redundant information.

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 no output schema and no annotations, the description covers input format, bases, padding, precision, and return keys. It includes an example. It could mention error handling but is sufficient for the tool's complexity.

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%, providing baseline 3. The description adds significant value by clarifying pad_bytes is a minimum, never truncating, bit-aligned, and rejected for decimal; explains output prefixes; and describes return structure. It goes beyond the schema.

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 'Convert a big-integer between bases (hex/dec/bin/oct)', using a specific verb and resource. It distinguishes itself from sibling tools like byte_order or encode by focusing on base conversion with arbitrary precision and giving an example.

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 for base conversion but does not explicitly state when to use or avoid this tool compared to alternatives. No guidance on when not to use or mention of sibling differences.

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?

With no annotations, the description carries full burden. It discloses that the tool never computes OTP codes, normalizes secret to base32, and applies RFC defaults. It does not discuss security implications of secret handling, but for a codec tool, it is adequately transparent.

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 paragraph but is well-structured, front-loading the purpose and splitting into build/parse sections with an example. It is concise given the complexity of the tool.

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?

Despite having 10 parameters and no output schema, the description explains the two modes, the return values (URI or parsed parts), and key parameter constraints. It is fairly complete for a codec 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining interactions (e.g., label handling with issuer, counter required for hotp) and provides an example. This goes beyond the schema descriptions.

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 builds or parses otpauth:// URIs, with specific verbs and a resource. It distinguishes between build and parse actions, and the example reinforces the purpose. No confusion with sibling tools.

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 explains when to use build (needs secret) vs parse (needs uri), and notes constraints like type='hotp' requires counter. It does not explicitly mention when not to use the tool, but the guidance is clear enough for correct usage.

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?

Rich disclosure: password never echoed, wrong password is a result not error, malformed encoded raises, encoding format for each scheme, dependency on crypto extra, example output. With no annotations, description carries full burden and exceeds it.

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?

Well-structured with action descriptions, encoding details, and an example. Slightly long but each sentence earns its place. Could be slightly more concise but overall efficient.

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?

Very complete given 6 parameters, no output schema, no annotations. Covers both actions, error handling, encoding format, parameter semantics, dependencies. Output shapes are implied. No 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?

Schema coverage is 100% with descriptions, but description adds significant context: salt explains production defaults, params lists scheme-specific cost defaults, scheme mentions crypto extra, encoded explains self-describing format. Provides example usage.

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?

Clear verb+resource: 'Hash a password into a verifiable storage string, or check one against it.' Specifies two distinct actions (hash and verify) with distinct return values. Distinct from sibling tools like hash (general) and derive_key (KDF).

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?

No explicit guidance on when to use this tool vs alternatives like hash or derive_key. Only mentions that bcrypt/argon2 need the crypto extra, which is a dependency note, not usage 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?

With no annotations, the description fully discloses behavioral traits: randomness source (OS CSPRNG via `secrets`), output structure ({kind, value, entropy_bits}), security note that value is never logged, and detailed parameter mappings for each kind. This covers all important behavioral aspects 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured, front-loading the purpose and then detailing each `kind`. Every sentence is informative, though the example could be slightly more concise. It earns its length given the complexity of the tool.

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 7 parameters, no output schema, and no annotations, the description is remarkably complete. It explains all parameter interactions, defaults, output format options, and security considerations. No missing information is apparent for correct tool usage.

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 baseline is 3. The description adds value by explaining how `kind` selects which sizing parameter applies (e.g., nbytes for bytes/hex/urlsafe, length for token, words for passphrase), default behaviors, and provides an example. This meaningfully extends the schema's descriptions.

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 explicitly states the tool generates cryptographically secure random bytes, tokens, or passphrases, with specific verb 'generate' and resource 'random bytes/token/passphrase'. It clearly distinguishes from sibling tools focused on encoding, hashing, or data transformation.

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 explains when to use each `kind` (bytes, hex, urlsafe, token, passphrase) and the relevant parameters, providing clear context for selection. However, it does not explicitly state when not to use the tool or mention alternative tools among siblings, though the unique randomness focus makes this less critical.

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?

With no annotations, the description fully explains the tool's behavior: input formats for encode vs decode, output structure ({encoded: '0x...'} for encode, {decoded} with leaves as hex and lists as arrays). It also clarifies that encode accepts recursive structures. No behavioral traits (e.g., side effects, auth needs) are missing for this codec tool.

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 concise, front-loaded with the core purpose, and uses efficient sentences. The example is placed at the end without redundancy, earning 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?

Given the complexity of a recursive codec tool, the description covers input schemas (both action and data), output format via text, and provides an example. No output schema exists, but the description sufficiently explains return values for both actions.

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%, but the description adds significant meaning beyond the schema: it explains the recursive structure for data, the leaf types (hex string, integer), and action's purpose. The example further clarifies the expected format and output.

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's purpose: 'RLP-encode structured data, or RLP-decode a hex string.' This specific verb+resource combination distinguishes it from sibling tools like abi_codec or decode by explicitly naming RLP.

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 provides clear context for usage (encoding structured data or decoding hex strings) and includes an example. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, which would improve 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?

No annotations provided, so description carries full burden. Discloses return value {style, result}, error on unknown style, example output, and shell behavior. Lacks details on edge cases but covers major behaviors.

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 plus example, front-loaded with main purpose, no redundant text.

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 no output schema, description adequately explains output structure, error handling, and provides example. Covers all crucial aspects for a complex tool with multiple styles.

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 covers 100% of parameters; description adds value by listing all style options, explaining shell's behavior, and giving a usage example.

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?

Description clearly states verb 'Escape text for a source-code or markup context', names multiple styles, provides example, and distinguishes from sibling encode (URL escaping).

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?

Explicitly tells when to use encode instead for URL escaping, mentions that unknown style raises ValueError, and references inverse string_unescape.

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?

No annotations provided, so description carries full burden. It states malformed sequences and unknown style raise ValueError, and returns {style, result}. It doesn't mention side effects or explicitly state it's read-only, but the behavior is well-covered for a pure function.

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 concise sentences with no waste. First sentence states purpose, second lists styles and errors, third gives an example. Perfect front-loading.

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 two well-documented parameters, no output schema, and no annotations, the description fully covers behavior, errors, and example. No gaps apparent for this tool's complexity.

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 covers 100% of parameters with descriptions. Description adds value by listing all styles and providing an example of use, which clarifies the style parameter beyond the enum list.

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 it reverses escaping back to original text, identifies itself as the inverse of string_escape, and provides an example. It distinguishes from sibling string_escape.

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 says it's the 'style-for-style inverse of string_escape' and lists supported styles. It implicitly tells when to use (for unescaping) but lacks explicit exclusions or when-not conditions.

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?

No annotations are provided, so the description fully carries the burden. It details parsing, anchoring naive inputs with from_zone, shifting to to_zone, rendering to_format, and return structure (result, from_format, to_format, zone, unix). It also explains edge cases like offset-carrying inputs and http overriding to_zone.

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 detailed and well-structured, starting with purpose and then parameter behavior. It is slightly verbose but each sentence adds necessary detail. Could be slightly tighter without losing clarity.

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?

Despite no output schema, the description fully explains the return object format. It covers all parameters, their interactions, and edge cases. The tool's behavior is completely specified for an agent to use correctly.

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%, but the description adds significant value by explaining the processing flow: parsing per from_format, anchoring with from_zone, shifting to to_zone, and rendering. It clarifies when from_zone is ignored and that http overrides to_zone, which goes beyond the schema descriptions.

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 converts timestamps between textual formats and time zones, listing specific formats (ISO 8601, RFC 2822, HTTP, unix, strftime) and zone handling. It is distinct from sibling tools which are all encoding, hashing, or data transformation tools.

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 explains when to use the tool for timestamp conversion, including nuances like ignoring from_zone for non-naive inputs and http format always using GMT. It does not explicitly mention alternatives, but siblings are unrelated, making the context clear.

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 explains the normalization process, the meaning of `changed`, and the return object. It includes an example demonstrating the transformation. With no annotations, the description carries full burden and does so adequately, though edge cases or errors are not mentioned.

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 concise and well-structured, with two paragraphs and an example. Every sentence adds value and there is no redundancy.

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 lack of output schema, the description explains the return object adequately. It covers normalization forms and provides an example. Missing error handling or invalid input cases, but for a simple tool this is acceptable.

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 baseline is 3. The description repeats the schema's parameter descriptions but adds a helpful example. The additional value is moderate.

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 normalizes text to a Unicode normalization form, lists the four forms, and distinguishes between canonical and compatibility variants. The example clarifies the behavior, making the purpose unambiguous.

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 provides clear context on what the tool does, but does not explicitly state when to use it vs. alternatives. However, the sibling tools are sufficiently different (encoding, hashing), so the lack of explicit exclusion is not critical.

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