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

Goes well beyond the annotations: discloses that the row becomes WITHDRAWN rather than erased, that the amount leaves the pledged total, that nothing is refunded because no money moved, that there is no gas cost, that the signature window is 5 minutes, and that the house never holds a key. The readOnlyHint is consistent because the tool only returns MESSAGE_TO_SIGN/BODY_JSON and the mutation lands in submit_backing_withdraw, which the description makes explicit.

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 two-step flow, the state effect, and the signer requirement are front-loaded, and every clause carries operational content. Minor redundancy: 'Free' is stated early and again as 'Cost and signer: free, no gas', costing a little tightness.

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?

Even though an output schema exists, the description names the returned fields (MESSAGE_TO_SIGN, BODY_JSON) and the exact handoff to the submit step, and it covers the permissions and cost model an agent needs. Nothing required 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% and both parameters already carry descriptions ('The packet id', 'The same 0x… address that pledged'). The description's 'SAME wallet that pledged' reinforces backerWallet but adds no syntax, format, or constraint beyond what the schema states, so the baseline 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?

States a specific verb and resource — take back a pledge, producing WITHDRAWN in the packet's pledge ledger — and the title labels it 'step 1 of 2', which separates it cleanly from submit_backing_withdraw. An agent can distinguish it from prepare_backing (the inverse action) without opening either 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?

Explicitly states the availability condition ('Always allowed, on every packet, whatever its lifecycle') and the downstream sequencing ('sign with the SAME wallet that pledged, then call submit_backing_withdraw within 5 minutes'). It lacks an explicit when-not / alternative branch (e.g. what to do if the withdrawal window closed or the pledge was already withdrawn), so it falls just short of the top.

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