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

Annotations already carry readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description still adds meaningful context: the pledge row becomes WITHDRAWN rather than erased, the pledged total decreases, no money is refunded, the operation is free, and the same signature-gated authentication as pledging applies. It also clarifies the two-step flow with a time limit, which readOnlyHint alone wouldn't convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three dense sentences cover the action, ledger effect, availability, cost, refund semantics, authentication, return payload, signer requirement, and next step. The most important information is front-loaded, and every clause adds value with no 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?

For a two-parameter prepare tool with a rich description and an existing output schema, nothing critical is missing. The agent knows which parameters to provide, what response to expect, how to sign it, which wallet to use, what to call next, and the time limit for completion.

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 schema already documents workId as 'The packet id' and backerWallet as the same 0x address that pledged. The description reinforces the same-wallet requirement but does not add new parameter-specific constraints, formats, or discovery guidance beyond what the schema 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 states a specific verb ('Take back a pledge') and resource ('pledge'), and the title adds 'step 1 of 2'. It clearly distinguishes itself from the submit step by saying it returns MESSAGE_TO_SIGN and BODY_JSON, which the agent must then sign and pass to submit_backing_withdraw.

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 provides clear usage context: always allowed on every packet, regardless of lifecycle, and only valid if the caller actually pledged. It names the follow-up tool submit_backing_withdraw and the 5-minute signing window, but it never explicitly contrasts with the pledging tool prepare_backing or states 'when not to use' beyond implicit prerequisites.

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