Delegate a task to the tester agent

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

With no annotations, the description carries the full burden and does well: it discloses the internal pipeline (detect test command, write tests, run build/tests, verify only test files changed, apply verified files to the checkout), which tells the agent this mutates the checkout and is gated by verification. It also surfaces the `watch` field in the response that no schema documents. Failure semantics, repair attempts, and timeout behavior are not covered.

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 what it does and the taskId return, then the pipeline, then the follow-on calls. The final sentence about `watch` and opening a terminal is somewhat chatty but does convey actionable response information, so it earns most of its space.

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?

A 9-parameter mutation tool with no annotations and no output schema; the description covers purpose, sequencing, the side-effect envelope, and the undocumented `watch` return field. Gaps remain around failure/repair behavior, idempotency and timeout semantics, which an agent needs to call it robustly.

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 coverage is 78%, so the baseline is 3. The description only reinforces taskType (already fully documented in the schema as "Only \"tests\" runs today") and adds no meaning for continueFrom, idempotencyKey, maxRepairAttempts or timeoutMinutes.

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 (starts), resource (a task in an isolated workspace) and immediate return value (taskId), plus the only currently supported taskType. This clearly distinguishes it from wait_for_task, get_task_result, cancel_task and the other siblings.

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?

Explicitly routes the agent through the follow-on sequence: "Follow with wait_for_task, then get_task_result." It does not state when *not* to use the tool (e.g. when to use continueFrom vs. a fresh task, or when cancel_task is appropriate), so it falls short of a full 5.

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