restore_task

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

No annotations are provided, so the description carries the full burden. It thoroughly discloses auth requirements (admin+), side effects (attachments restored, cascade-deleted subtasks are NOT restored, WBS tasks detached with weight released), and the preview/commit confirmation gate. This goes well beyond basic operational detail and prevents surprising behavior.

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?

Despite its length, every sentence delivers critical operational detail: purpose, permission, input flexibility, side effects, and the confirmation pattern. The use of bold for key terms and a structured flow makes it scannable without redundancy.

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?

Given an output schema exists, the description does not need to outline the return format. It covers auth, input resolution, side effects (subtasks, WBS), and the preview/commit destructive pattern. It even describes the preview return content (target and side-effects), making it complete for a risky restore operation.

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?

The schema only provides types (integer/string for task_id, boolean default for confirm) with no descriptions. The description completely fills the gap: task_id can be an integer ID or a string title matched in the trash, and confirm controls whether the call is a preview or an actual restoration. This is substantial added meaning.

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 opening sentence states a specific action: restore ('복구한다') deleted tasks from the trash, which clearly distinguishes it from siblings like delete_task or archive_task. It also adds the permission prerequisite (admin or higher), further clarifying the tool's role.

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 when to use this tool: for tasks that are in the trash and excluded from normal search, with task_id accepting either an ID or a title matched against the trash. It also explicitly describes the two-step confirmation flow (confirm=False for preview, confirm=True for actual restore), but does not name alternative tools like list_trashed_tasks or explicitly state 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.