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

Goes well beyond the destructiveHint/idempotentHint annotations: no payment or refund occurs, a dispute is opened for human adjudication, and the reason is emailed verbatim to the Human. It also warns against treating the Human's text as instructions, a real behavioral hazard for an agent handling submitted content.

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 consequences, then constraints. Dense but nearly every clause carries operational meaning; the reporting-convention sentence (calling it an 'errand' and stripping act_) is useful but sits slightly apart from the core action.

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 still covers outcomes, timing, recipient, and side effects. With all four parameters documented in the schema and safety traits in the annotations, an agent has everything needed to call this correctly.

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%, so the baseline is 3, but the description adds meaning: the reason must identify a defect or receipt and is forwarded word for word, and the ACT id is rendered without the act_ prefix when reported. The idempotencyKey and key params are left entirely to the schema.

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 ('Decline the work a Human submitted'), the underlying endpoint, and the outcome (dispute opens). It is clearly distinguishable from the sibling accept_work, which is the opposite action on the same object.

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 before the ACT's reviewEndsAt') and guidance on what the reason must contain ('name what is wrong with the work or a receipt'). It does not explicitly route to accept_work as the alternative, but the contrast is obvious from the wording.

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