cancel_task_bounty

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

With no annotations, the description carries the full burden. It does disclose the key behavior beyond the name: funds are refunded to the creator and the tool prevents permanent lockup, plus a cost hint ([Free / $0.0000 USDC]). It omits irreversibility, authorization requirements beyond the creator_id, failure modes (already-claimed escrow), and any confirmation/return behavior.

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?

Cost/scope prefix is front-loaded, the purpose sentence follows, and the Args block is terse. The 'Keywords' line is arguably redundant agent-facing filler, but it is short and the overall payload is compact with no wasted sentences.

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 fund-moving mutation with no annotations and no output schema, the description covers the side effect, the reason to call it, and both argument meanings. It still leaves gaps an agent might need: whether the caller must be the creator, what happens if the bounty is already claimed or not expired, and whether the refund is atomic/reversible.

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%, so the description must compensate, and it documents both parameters: escrow_id as the target escrow to cancel and creator_id as 'EVM wallet address of the task creator requesting refund'. The EVM-address format hint on creator_id is genuinely additive, though escrow_id's semantics ('target escrow ID') remain thin.

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 (cancels) and resource (open or expired task bounty) plus the side effect (refunds funds to the creator). The 'task bounty' scoping distinguishes it from siblings such as cancel_rfp, release_task_bounty, and claim_task_bounty without the agent needing to open another 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?

Implies when to use it via 'open or expired task bounty' and 'unclaimed or expires past its TTL', which gives the triggering condition. However, it never names the alternative tools (release_task_bounty, claim_task_bounty) or states when not to cancel, so the routing decision is left to inference.

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