apply_taskApply a worktree-isolated task's changes to your working tree without committing, so you can inspect the diff before keeping or discarding it.
Apply a worktree-isolated task's changes to the user's working tree (not committed).
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | task_id from start_task | |
| keep_worktree | No |
Changes observed during successful MCP inspections.
v1.2.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds real context by stating changes land uncommitted in the working tree and come from a worktree-isolated task, but it omits whether existing uncommitted edits are overwritten, whether the worktree survives, and how failures surface.
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 zero filler; the effect on the working tree and its uncommitted status are both stated up front. Nothing is repeated from annotations.
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 destructive mutation with no output schema and one undocumented parameter, the description covers the core effect but not enough: conflict/overwrite behavior, worktree fate, and the keep_worktree choice are all missing. Annotations carry the safety signal, which keeps this from being worse.
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 only 50% and the description adds nothing about parameters, leaving keep_worktree with no semantics in either place — an agent cannot tell whether it keeps the worktree after applying or deletes it. The word 'worktree-isolated' gestures at the concept but never explains the flag.
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 (apply) and resource (a worktree-isolated task's changes) plus the exact destination (the user's working tree, not committed), so scope is unambiguous. It does not differentiate itself from siblings such as get_task_diff or discard_task, which would have pushed it to a 5.
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?
No when-to-use guidance is given: it never says at what point in the start_task → wait_task → apply_task lifecycle this should be called, nor when to prefer discard_task instead. The only procedural hint is the schema's 'task_id from start_task', which is not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.