jules_batch_dispatch

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds one useful behavioral trait—automatic load-balancing across the account pool—but it does not disclose whether dispatch is asynchronous, whether it returns immediately, what sessions/artifacts it creates, how failures are handled, or how to monitor progress. This is a significant gap for a tool that likely spawns long-running work.

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?

A single, front-loaded sentence conveys the core purpose and the key differentiating behavior, with no filler or redundant restatement of the tool name. Every phrase earns its place.

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?

This tool has no annotations and no output schema, so the description is the sole source of operational context. It is not complete enough for an agent to know what happens after dispatch, whether it should wait, how to check results, or what constitutes success. Given the large sibling set around waiting, streaming, and sessions, the missing behavioral context is material.

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?

The schema description already covers the 'tasks' parameter at a high level, listing source, prompt, and optional title/auto_create_pr. The tool description adds contextual meaning by tying tasks to repositories and account-pool load-balancing, but it does not add per-field detail beyond the schema. Notably, the nested 'require_plan_approval' field is omitted from the schema's task description as well, but the description does not compensate.

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 action ('dispatch') and resource ('multiple coding tasks across repositories'), plus a distinctive feature: automatic load-balancing across Google accounts. The batch/parallel nature implicitly differentiates it from single-task siblings like jules_dispatch_and_wait, but it does not explicitly name an alternative or exclusion.

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 phrase 'dispatch multiple coding tasks across repositories simultaneously' implies the intended use case: when an agent has several tasks to run in parallel. However, there is no explicit guidance about when not to use this tool, whether to prefer queue_tasks or dispatch_and_wait for sequential or single-task flows, or how this relates to the other dispatch siblings.

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