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

Well beyond the annotations, it discloses that the task arrives pre-claimed, that re-invocation re-leases rather than duplicates work, that the latest lease_token supersedes older ones, and what a null task signals. This is consistent with readOnlyHint=false (the call mutates lease state); the 'new lease_token' on repeat does sit slightly awkwardly next to idempotentHint=true, but the stated effect (same task) is effectively idempotent, so it is not a contradiction.

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?

It is dense and front-loaded, leading with what is returned and the safe isolation constraint before the submit/re-call mechanics. Semicolon-chained clauses make it slightly run-on, but no sentence is filler.

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?

With no output schema, the description carries the return-value burden itself and does so – naming the fields (task, run_id, isolation, lease_token, reward) and the null case. For a stateful polling tool it supplies everything needed to call it correctly and to know what to do next.

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?

There is a single parameter and schema coverage is 100%, with the schema itself explaining the pba_ key, its pattern, and when it can be omitted. The description adds no parameter-level information, so the baseline of 3 is appropriate.

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?

The description states a specific verb+resource ('your next task, already claimed for you') and enumerates exactly what the response carries: what to do, the answer's shape, the reward, a run_id and an isolation field. It is readily distinguishable from sibling mutators like claim_run or submit_result, though it never names an alternative queue-style sibling to contrast against.

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?

It prescribes the full loop explicitly: do the work in a fresh worker given only the task, output requirements and execution instructions, submit_result with the run_id and an isolation receipt, then call next_task again. It even covers the re-call edge case ('calling it again before you submit returns the same task with a new lease_token; use the latest one') and the empty-queue case ('task: null means nothing is waiting').

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