reject_task

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

With no annotations, the description carries the full burden. It discloses that the tool moves the task file from _lifecycle/review/ to _lifecycle/active/, appends a transition event, and is a recall mechanism. It also notes the v2 no-op behavior. Could mention authorization requirements beyond the default actor role.

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 concise with two short paragraphs. The first sentence gives the main action. Every subsequent sentence adds necessary detail: lifecycle path, transition event, purpose, and version behavior. No redundant information.

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 the complexity of lifecycle management and version differences, the description is quite complete. It covers the lifecycle transition, file paths, event logging, and v2 no-op. It could mention prerequisites like the task must be in review state, but overall it is adequate.

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 covers 100% of parameters, but the description adds valuable context: it explains that 'task_id' can be ID or full filename, that 'actor' defaults to ADMIN, and that 'note' is strongly recommended and mandatory in practice. This goes beyond the schema's 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?

The description clearly states the tool rejects/recalls a task under review, moving it from 'review' to 'active' lifecycle. It distinguishes itself from siblings like approve_task and archive_task by describing the specific lifecycle transition and mentioning it is the FCoP v3 recall mechanism.

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 usage when a task under review needs rework by ADMIN. It explicitly notes that on v2 projects it is a no-op, providing important context. However, it does not explicitly state when not to use or list alternative tools for similar purposes.

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