duplicate_task

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

The description discloses key behaviors: the copy includes specific attributes, lands in the same project, links back with a copiedfrom relation, and returns the copy with the id. It also explains the response envelope handling. However, the final sentence about 'A body without the key is passed through whole' is cryptic and could confuse, slightly reducing transparency.

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 somewhat verbose, including details about response envelopes and a cryptic final sentence. It is structured with a clear lead sentence, but the extra detail about envelope removal and the 'body without the key' clause is redundant and could be trimmed for conciseness.

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 simple copy operation, the description covers the essential context: what is copied, where it lands, relation created, and response content. It also mentions the alternative for moving. It lacks potential error scenarios or permission requirements, but these are not critical for a basic copy. The response format is partially explained, though the final sentence is unclear.

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 only parameter is task_id, which is clearly the ID of the task to duplicate from context, but the description does not explicitly mention it. With 0% schema coverage, the description should compensate by naming and explaining the parameter; it does not, leaving some inference required.

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 action: 'Copy a task, with its labels, assignees, attachments, and reminders.' It specifies the resource (task) and scope (same project, with copiedfrom relation). It also distinguishes from siblings like move_task, making the purpose unambiguous.

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 explicit guidance on the primary use case and points to an alternative: 'Vikunja offers no way to duplicate straight into another project; call move_task on the copy for that.' This is helpful for when to use this tool versus move_task. However, it does not contrast with create_task or other task creation methods, leaving some room for ambiguity.

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