get_tasks

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

With no annotations provided, the description carries the full burden. It discloses a critical side effect: 'THIS STARTS THE BATTERY.' It also reveals the scale (80+ tasks, ~30 dimensions), the live tracker behavior, and the continue_run payload cap. It doesn't describe the exact return shape, but it does say it returns all tasks with their prompts, which is sufficient for a fetch tool.

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?

The description is dense but every sentence adds value: the side-effect warning, the operator tracker best practice, the return content, the dimension paging option, and the continue_run payload cap. It is somewhat long, but the length is justified by the important operational warnings. It is front-loaded with the most critical warning.

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 fetch tool with no output schema and no annotations, the description covers the key operational context: side effects, scale, paging, and follow-up actions. It doesn't describe the exact response format, but it does say tasks come with prompts, and the sibling list plus the mention of submit_answers gives the agent enough to proceed. The main gap is not describing what a task object looks like, but that is minor given the tool's role.

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 both parameters. The description adds context for dimension (paginate a large battery) and run_token (returned by start_verification), but doesn't add format or syntax details beyond the schema. Baseline 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 clearly states the tool fetches tasks for an active verification run and explicitly warns that calling it starts the battery. It distinguishes itself from siblings by naming submit_answers and continue_run as the follow-up actions, and by mentioning dimension-based paging. The verb 'fetch' plus the resource 'tasks for an active verification run' is specific and unambiguous.

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?

The description gives explicit best-practice guidance: share the live tracker link before starting, use dimension to paginate, and split large batches when using continue_run due to the ~32 KB payload cap. It also tells the agent what to do after fetching (answer and submit via submit_answers), which is clear usage direction.

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