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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuine context beyond that by naming the external dependencies it queries (the Ethereum Foundation ERC-7730 registry, ERC-8176 attestations, Sourcify), which tells an agent it performs live third-party lookups. It stops short of stating latency, caching, or failure behavior when a source is unreachable.

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 definition is a single front-loaded sentence that leads with the core question and then enumerates the criteria, with no filler. The trailing 'Read-only.' is redundant with readOnlyHint=true and is the only wasted token.

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 two-parameter read tool with full schema coverage and strong annotations, the description covers what is checked thoroughly. With no output schema present, it could be slightly clearer that the result reports each of the four checks separately (e.g. booleans or per-source status), which is the only remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema itself enumerates chain IDs and enforces the address pattern, so the description need not restate them. The description adds no syntax or semantic detail about chainId or address beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource ('Check whether an EVM contract is clear-signed') and then decomposes the check into four named criteria: ERC-7730 registry descriptor presence, function/EIP-712 coverage, ERC-8176 auditor attestation verification, and Sourcify source verification. This is unmistakably a contract-level status check, distinct from the sibling tools that explain or simulate transactions and signatures.

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 implied rather than stated: an agent can infer this tool applies when it needs to know if a contract is clear-signable before interpreting a signature via explain_signature. There is no explicit when-to-use/when-not-to-use guidance and no named alternative, so the routing is left partly to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new behavior: uncovered messages are marked NOT CLEAR-SIGNED and returned as sent, and the domain must carry chainId and verifyingContract. It does not describe the shape of the explanation output, but that is a minor 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?

Four short sentences, front-loaded with the core purpose and ending with the read-only note. Dense but every sentence carries information; the ERC-7730 analogy is slightly decorative but aids interpretation.

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 nested-object tool with no output schema, the description covers purpose, the uncovered-message return behavior, and a key domain requirement. What an agent still lacks is any sense of the explanation's output structure, but the essentials for correct invocation are present.

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 does add one useful constraint beyond the schema — that the free-form domain object needs chainId and verifyingContract — but says nothing about the account parameter or the types/primaryType/message structure.

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 ('Explain an EIP-712 signature request (eth_signTypedData_v4)') and grounds it with concrete examples (token permit, order) plus the ERC-7730 wallet framing. This clearly separates it from explain_transaction and simulate_transaction, which operate on different artifacts.

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 makes clear this is for typed-data signature requests rather than transactions, and notes the fallback behavior for messages without a descriptor. It does not explicitly say 'use explain_transaction instead when X', so the routing to siblings is implied by the artifact type 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so safety is covered. Beyond that, the description discloses a genuinely non-obvious behavior: calls with no descriptor fall back to the contract's Sourcify-verified ABI and are marked NOT CLEAR-SIGNED. That fallback path and the attestation status materially shape how an agent should interpret and relay results.

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 dense sentences with the core purpose front-loaded and no filler. The clause about Sourcify fallback is long but carries real information, so the density is justified rather than 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?

There is no output schema, and the description compensates by describing exactly what comes back (intent, a filled-in sentence, labeled values, attestation status). Combined with the fallback-decoding caveat, an agent has everything needed to call this and present the result 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 100%, so the baseline is 3. The description adds a little meaning the schema doesn't: that the calls array is an EIP-5792 batch executed in order, which matters for interpreting multi-call input. It adds nothing for from or chainId beyond what the schema 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?

States a specific verb and resource: explaining one EVM call or an EIP-5792 batch, rendered the way an ERC-7730 wallet shows it. It even sketches the output (intent, filled-in sentence, labeled values, attestation status). It does not explicitly name how it differs from simulate_transaction or explain_signature, so an agent must infer the boundary.

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?

'Use it before proposing any transaction, and show the person the result' gives a clear when-to-use trigger and even a workflow instruction. It stops short of exclusions or naming alternatives (e.g. use simulate_transaction when you only need success/failure), so the agent must reason about sibling selection itself.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real substance beyond them: no signing or sending occurs, calls execute in order against current state, and the return payload is characterized (per-call success, balance changes, approvals with unlimited ones flagged, token transfer events). That is exactly the behavioral and return-shape context an agent needs for a simulation tool with no output 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?

Two sentences, front-loaded with the action and mechanism, then the return contents, then the workflow instruction. Every clause carries information; nothing is redundant padding.

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 no output schema, the description correctly takes on the burden of describing return values, and with annotations covering safety it need not re-explain side effects. Purpose, execution mode, return contents, and sibling workflow are all covered, leaving no gap an agent would hit before invoking 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% and the schema already explains `from` ("no key is needed"), `calls` ("a batch run in order"), and `blockNumber`. The description's mentions of "as the given account" and "several in order" largely restate those field descriptions, and it says nothing about `blockNumber`, so it adds only marginal meaning over 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 names a specific verb and resource ("Simulate one EVM call, or several in order") and pins down the mechanism (eth_simulateV1, current chain state, as the given account, no signing or sending). It is clearly distinguishable from the sibling explain_transaction, which analyzes rather than simulates, and the batch capability is stated up front.

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 an explicit workflow cue: "Use it with explain_transaction before proposing a transaction," which tells the agent this is a pre-flight check tool. It stops short of stating when not to use it or what to do instead for pure read-only queries, so no explicit alternative/exclusion is offered.

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