delegate_task

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

No annotations are provided, so the description carries the full disclosure burden — and it does substantial work: it reveals git worktree isolation "branching from cwd," post-run checks semantics, memory persistence modes (auto infers an opaque Git checkout identity, explicit requires memory_project, off disables memory), and the privacy guarantee that "Raw prompts are never stored in memory." It also discloses the handoff constraint requiring "a configured, provider-specific quota signature" to rotate agents. Material behaviors remain undisclosed — notably what write=false vs true controls and how background dispatch behaves — so it is strong but not exhaustive.

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?

Tight prose blocks each cover a distinct concern — purpose, agent selection, worktree isolation, checks, memory, on_limit — with the core purpose front-loaded in the first sentence. The length (roughly 150 words) is justified by 16 parameters and zero schema descriptions, and there are no filler sentences. A bulleted layout would improve scannability, but nothing here 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?

The output schema relieves the return-value burden, and the description covers the most behaviorally complex parameters well. But for a 16-parameter tool with no annotations and 0% schema coverage, key semantics are still missing: the default on_limit='stop' behavior, what the write flag controls, background/async execution semantics, and effort/model/agent_name overrides. The description is adequate for an expert caller but incomplete for an agent that must reason correctly about all 16 fields.

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 description must compensate, and it does for the least obvious parameters: agent selection with capability-based auto default, required_capabilities, exclude_agents, memory_mode with its auto/explicit/off semantics, memory_project overrides, worktree isolation, checks as post-run shell commands, and the on_limit handoff path. However, several parameters (background, write, effort, model, agent_name, prompt) receive no clarification, leaving gaps an agent must infer from parameter names alone.

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+target: "Delegate a task to a headless CLI agent or role." The 'headless' qualifier differentiates this execution-side dispatching from contextual siblings like route_task and the memory tools, though no sibling is named explicitly in the purpose statement. The rest of the description reinforces the purpose by explaining how automatic agent selection delegates to installed workers.

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 when-to conditions: pass required_capabilities "when the orchestrator already knows what the task needs," use exclude_agents to keep the human-facing orchestrator out of the worker pool, and opt into on_limit='handoff' only with worktree=True. It also directs the caller to "read their outcome with job_review before spending anything on the job's output," which is a useful follow-up pointer. It never names an alternative tool to choose instead (such as preferring route_task for routing-only decisions), so it stops short of explicit when-not guidance.

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