Clear signing status of a contract

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.