sign_contract

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

With no annotations, the description carries the full burden and it delivers: it discloses that wallet signing needs no account, that the signature itself is the authentication, that the last required signer triggers execution and witnessing, and that the call returns the updated contract view. It also reveals the exact EIP-712 domain/type, which is far beyond the schema's capability.

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 efficient: the core purpose is front-loaded, and every subsequent sentence adds a necessary constraint, authentication detail, data shape, or return value. The example at the end is a practical summary rather than repetition.

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 tool with no annotations and no output schema, this is unusually complete. It explains the two authentication paths, the hash-chain effect, the EIP-712 payload shape, the threshold side effect (executed/witnessed), and the return value. Remaining details like precise error handling are not essential for a competent 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 0%, but the description fully compensates by mapping 'id' to contractId, explaining the 'method' enum's two modes, and specifying that walletAddress and signature are required for the wallet form while only id and method are needed for the account form. The example reinforces these parameter shapes.

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 ('Append your consent to a contract') and immediately defines the artifact as an entry on the contract's hash chain. It also distinguishes two signing methods, which separates it from the sibling create_contract (creation vs. signing). The purpose is unmistakable.

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 explains when to use the wallet method vs the account method and the authentication expectations for each, including the 'no cross-method satisfaction' constraint. It does not name alternative sibling tools explicitly, but the method-selection guidance is concrete enough for choosing the correct call.

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