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

Annotations only declare readOnlyHint=false/openWorldHint=true/non-destructive/non-idempotent. The description goes far beyond: real money at stake, escrow-gated opening, exact payment amounts and time windows, emergency 80/20 fee split, review-window winner selection, fallback to best-graded entry, and full refund when no valid entry exists. This is exactly the behavioral context a money-moving mutation needs.

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 parameter contract before the payment mechanics, and every clause carries information the agent needs (rails, defaults, refund path). It is a single dense run-on block rather than scannable structure, which costs it a point, but little is wasted.

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 high-complexity, no-output-schema tool with nine params, the description covers funding flow, escrow timing, deadline semantics, entrant behavior, grading, payoff split, and auth — nothing an agent needs in order 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 description coverage is only 11%, so the description must compensate — and it does, supplying constraints the schema lacks (brief ≤4000 chars and 'never instructions', reward floor $5, deadline 1–168 with default 48, max_entrants 1–16 with default 4) plus the meaning of capability, output_schema, rail, and payer_wallet. This effectively documents all nine parameters.

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?

Opens with a specific verb+resource ('Post a task') and immediately enumerates the full input contract, so an agent knows exactly what this call creates. It is clearly distinguishable from the surrounding task-lifecycle siblings (task_enter, task_submit, task_pick, task_fund), which are all referenced by role in the text.

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 concrete conditions for each rail ('signet' pulls immediately; 'usdc' returns an order to pay within 30 min; 'x402' requires a follow-up task_fund call) and an explicit auth precondition (own signed-in JWT, never rk_ key or connected app). It stops short of naming alternatives or excluding cases, e.g. when to prefer this over create_task.

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