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

Beyond the sparse annotations (destructiveHint=false), the description discloses several meaningful behaviors: the merge is squashed to a single commit, the task text is the default message, the delegation worktree is cleaned up afterward, and the call refuses under dirty-tree conditions. These add real operational context the annotations do not provide. The word 'clean up' sits near the line of contradicting destructiveHint=false, but since content is preserved via the merge, it is not a hard contradiction.

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?

Two compact sentences carry the core action first, the commit-message nuance second, and the critical refusal guard last. Every clause earns its place with no filler or restatement of the tool's name.

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 mutation-style operation with no output schema, the description covers the core behavior, a parameter default, a side effect (worktree cleanup), and a precondition guard. The main gaps are the semantics of id and repo_path, and what 'refuses' looks like in practice, but an agent can reasonably invoke the tool knowing it must supply a delegation id.

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 0%, so the description must compensate. It does explain commit_message's role (overrides task text as the message) and implies it is optional. But the required id parameter is never described as the delegation identifier, and repo_path's purpose is left entirely unexplained. Partial compensation only.

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 names a specific verb ('Merge'), a specific resource ('a delegation'), and a precise outcome: a single commit into the current branch plus worktree cleanup. This clearly distinguishes it from sibling tools like delegate, revise, discard, and status, since only accept performs the merge-and-cleanup operation.

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 workflow context (delegation lifecycle) makes the intended use implied, and the refusal condition ('Refuses if the working tree has uncommitted changes') gives a concrete when-not-to-call signal. However, it never names alternatives or explains when to prefer discard or revise over accept, leaving sibling differentiation to inference.

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

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.

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

The annotations already declare destructiveHint=true, and the description adds specificity about what gets destroyed: the delegation's worktree and branch. This is useful context beyond the annotation, though it does not mention irreversibility or potential side effects in detail.

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 a single, tightly worded sentence with no filler. It front-loads the action and immediately communicates the key distinction from merging, making it easy to parse.

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?

While the tool is simple and the destructive annotation covers the main risk, the description leaves parameter semantics undocumented and provides no guidance on how to supply 'id' or 'repo_path'. For a destructive operation, more context about required inputs and effects would be expected.

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?

With 0% schema description coverage, the description carries the full burden for parameter meaning, but it only indirectly suggests that 'id' identifies a delegation. It does not clarify 'repo_path' or confirm how the parameters are used, leaving the agent to guess about the second parameter.

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 states a specific action ('Throw away'), a specific resource ('a delegation's worktree and branch'), and a key constraint ('without merging'). This clearly distinguishes it from the sibling tool 'accept', which would merge the delegation's changes.

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 implies the tool is used when you want to discard a delegation's work rather than merge it, but it does not explicitly state when to use this tool versus alternatives like 'revise' or 'accept'. There is no direct guidance on when not to use it.

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

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

Beyond the annotations (destructiveHint=false), the description discloses meaningful behavior: the model retries, tests are re-run, and the tool returns the updated diff and test output. This adds useful context about what happens when the tool is invoked, though it does not mention any side effects on existing delegation state.

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 two sentences with no fluff. It front-loads the action and effect, then states the return value, making it quick for an agent to parse and act on.

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 description covers the main workflow and return value, but leaves repo_path undefined and does not explain when to use this tool versus accept/discard. For a 3-parameter tool with no output schema and minimal annotations, these are meaningful gaps that could hinder correct invocation.

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, but it only loosely implies that 'id' refers to a delegation and 'feedback' is the review feedback. The 'repo_path' parameter is entirely unexplained, leaving an agent without enough information to populate all parameters correctly.

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 states a specific action ('Send review feedback on a delegation'), identifies the resource (delegation), and explains the effect (the local model tries again and tests are re-run). This clearly distinguishes it from sibling tools like accept, discard, and status, which handle different outcomes.

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 gives clear context for when to use the tool: when review feedback should be sent to trigger another attempt. It does not explicitly name alternatives or exclusions, but the behavior is distinct enough from accept/discard/status that an agent can infer the appropriate use case.

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

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

Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds the useful scoping constraint of pending delegations but does not detail return format or pagination; for a simple read-only listing this is acceptable.

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?

A single front-loaded sentence with no filler. The verb, resource, and filter are immediately clear, and every word earns its place.

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 one-parameter, read-only listing tool with a defined output schema and a clear description of what is returned, no additional invocation-critical information is missing. The tool is simple enough that this description is self-contained.

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%, and the description does not explain repo_path, its expected format, or why it is optional. The parameter name and default provide some clue, but the description does not fully compensate for the missing schema detail.

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 the specific verb 'List', the resource 'delegations', and the scope 'in this repository' with a clear status filter: 'not been accepted or discarded.' This distinguishes it from sibling tools like accept and discard.

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 clearly implies this tool is for viewing pending delegations before accepting or discarding them. It does not explicitly name alternatives or exclusions, but the status filter gives sufficient usage context.

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