dispatch_task

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

With no annotations, the description carries the full load, and it does disclose one genuinely valuable behavior: quota exhaustion spawns a new Assignment on another harness and resumes in the same worktree. It is silent on other significant traits an agent needs, notably whether dispatch is asynchronous (returning a task id), that a worktree is created and uncommitted changes may be synced, and any cost or timeout implications across the 29-parameter surface.

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 short and the essential constraint (only objective required) is front-loaded immediately after the purpose statement. The stray line breaks are cosmetic; no sentence is wasted, though the space devoted to four parameters rather than the riskiest ones is a mild misallocation.

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?

The output schema excuse applies to return values, but for a 29-parameter dispatch tool with zero annotation and zero schema description coverage, the description is far too thin. It omits the lifecycle model (async vs blocking), workspace creation side effects, and the meaning of the majority of arguments, so an agent must guess on most of the call surface.

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 0%, so the schema is bare and explanation must come from<|place_holder_mm_span_0442|> text. The description covers only objective, target_harness, model, and task_kind out of 29 parameters. Opaque fields such as checkpoint, trace_chain, call_depth, min_intelligence, routing_mode, on_quota_exhausted, and auto_record_context receive no semantics, leaving most of the parameter surface undefined for the agent.

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 opens with a specific verb+resource, 'Dispatch a ticket,' which makes the core action unambiguous. It does not differentiate this tool from siblings such as parallel_dispatch or preview_routing, and the word 'ticket' is inconsistent with the tool/resource name 'task', but an agent can still tell broadly what the tool does.

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 gives fill-in guidance for defaults ('Leave target_harness at "auto" and model unset', 'pass task_kind when it is known') and states that only objective is required, which is useful. However, there is no when-to-use-this-vs-alternatives guidance at all, so the agent must infer that dispatch_task is the single-task path and parallel_dispatch the multi-task path.

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