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

Goes well beyond the annotations: it discloses the financial consequence (held money returns to the Principal's withdrawable balance, listing fee returns as Platform Credit), clarifies the sandbox nature (practice money, no real charge, no Human dispatched, a person plays the Human), and notes the mutation is a board-removal. The destructive/idempotent hints are expanded into concrete 'what actually happens' context.

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?

Front-loaded with the action and endpoint, then the money consequence, then the sandbox caveat, then the alternative. It is dense but nearly every clause earns its place; the closing instruction about naming it 'errand (ACT)' and writing the id for the Principal is mildly tangential to invoking the tool and lengthens the paragraph.

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?

No output schema exists, and the description compensates by explaining the resulting state change (money back to withdrawable balance, fee as Platform Credit) plus the sandbox caveat. For a destructive mutation with three parameters, nothing an agent needs in order to call it safely and report the result 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 description coverage is 100%, so the schema already documents id, key, and idempotencyKey, which sets the baseline at 3. The description adds only a formatting convention for the id ('write its id as the site shows it, without act_') and says nothing about key or idempotencyKey beyond what the schema states; the withdrawable-balance/credit outcome is behavioral, not parameter guidance.

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 an errand (ACT) no Human has claimed off the board'), names the underlying endpoint POST /api/v1/acts/{id}/withdraw, and explicitly separates itself from the sibling cancel_act. An agent can distinguish this from cancel_act or decline_work without opening any 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?

Gives an explicit precondition (only errands no Human has claimed) and an explicit exclusion with a named alternative ('Once a Human has claimed it, cancel it with cancel_act instead'). The when-not case is routed to the correct sibling, which is exactly what usage guidance should do.

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