delegate_task

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that execution is asynchronous, that the caller must poll get_task(), and that the immediate result is only a queued task_id. It omits permission/auth requirements, failure semantics, and interaction with cancel_task, but the core behavioral model is unusually clear.

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?

Front-loads the core action and the async polling requirement in the first two sentences, then uses compact Args/Returns blocks. Efficient overall, with minor redundancy in restating the return payload that an output schema already covers.

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 6-parameter, annotation-free tool, the description supplies the async model, parameter meanings, defaults, and expected return keys. Because an output schema exists the Returns block is redundant but harmless; the remaining gap is the absence of guidance distinguishing this tool from its task-variant siblings.

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 is the only documentation and it covers all six parameters, adding meaning beyond the schema types: timeout defaults to the global default, depth is flagged as advanced with a recommended value, and mode enumerates five delegation modes. It is a solid compensation for the coverage gap, though 'context' type (schema says string, text says JSON object) could be clarified further.

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?

States a specific verb and resource ('Delegate a task to a configured assistant and return a structured task id') and immediately characterizes the operation as asynchronous. An agent can distinguish this from siblings like list_tasks or cancel_task without opening any schema.

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 clear operational guidance for the async lifecycle ('poll get_task() for status') and notes 'leave 0 for top-level tasks' for depth. However, it never explains when to choose this tool over the look-alike siblings parallel_task, review_task, debate_task, or pipeline_task, even though the 'mode' argument lists the same concepts (delegate, parallel, review, debate, pipeline) — the routing decision is left ambiguous.

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