delegate

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

The description goes beyond the annotations by explaining the iterative test-feedback loop, the replacement of '{repo}' in the test command, and the fact that it returns a diff and test output. It adds value about the execution model that the annotations don't convey. It doesn't contradict the annotations (destructiveHint=false), which is fine. However, it doesn't mention potential side effects or cleanup of the worktree, but the isolated worktree implies safety.

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 well-structured and efficient: a one-sentence purpose, a clear explanation of the workflow, specific details on the test_command semantics, and a concise summary of the return value. Every sentence adds necessary information without fluff. The most important details (the loop, the replacement) are front-loaded.

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 tool with 3 parameters (one required), no output schema, and no sibling descriptions, the description is quite complete. It explains the main behaviors and parameters. It falls short of a 5 because it doesn't mention the maximum number of rounds explicitly (only the variable name), or whether the repository is cleaned up after. But these are minor given the complexity.

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 explain parameters. It explains test_command in detail (shell command, placeholder replacement, example usage) and mentions repo_path defaults to current directory. The task parameter is obvious from the purpose. This compensates well for the lack of schema descriptions.

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 tool's purpose: to hand a coding task to a local model for execution in an isolated git worktree. It specifies the verb 'hand' and the resource 'coding task', and differentiates itself from siblings by mentioning the workflow (editing, testing, feedback loop) that leads to review actions. However, it doesn't explicitly name sibling tools like 'revise' or 'accept', so differentiation is implicit rather than direct.

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 description explains the workflow: the tool runs a test command after each attempt, feeds failures back to the model, and up to a certain number of rounds. It mentions the returned id for accept/revise/discard, which implies when to use this tool (to delegate a task) versus siblings (to act on the result). It doesn't explicitly say when NOT to use it, but the context is clear enough for an agent to decide.

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