Casefile

Overview Schema Source Related Servers Discussions Admin

Move task to project

move_task

Moves a task to another project, records the move and reason, and keeps its status, links, parent, children, and case intact; children stay in their original project.

Instructions

Moves a task to another project, recording the move, both keys and the reason as a moved entry of the task.

The task gets the next number of the new project, or its own earlier key there when it returns to a project it has been in: a task holds at most one key per project. The key it leaves goes to previous_keys and keeps addressing the task in every call that takes a key; no other task ever gets it. Status, sections, links, parent, children and case stay as they are, and a closed task moves too. One key moves one task: its children stay in their project.

Moving into or out of a frozen project fails with project_archived.

A list of keys moves each task on its own, in list order, so new numbers follow that order; each moved task gets its own moved entry with the one reason. The answer is results, one per listed key, repeats included: moved, already (the task is in that project already) or error with the code a single move would give, such as task_not_found or project_archived of the task's own project. A refusal of one task leaves the others moved. A blank reason, an unknown or archived target project and a list size out of range refuse the whole call before any move.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	Yes	Task key `PROJECT-N`, case-insensitive, or a list of 1 to 100 keys; a previous key of a moved task addresses it as well. A list outside that range is refused with `task_move_batch_size_invalid` before any move
`reason`	Yes	Why the task moves; a blank one is refused with `task_move_reason_required`. Filed in the `moved` entry of the task's case
`project`	Yes	Key of the project the task moves to, case-insensitive. An unknown key is refused with `project_not_found`, the project the task is already in with `task_already_in_project`

Output Schema

TableJSON Schema

Name	Required	Description
`no`	No	Number of the `moved` entry in the task's case
`key`	No	Key the task got in the new project
`results`	No	One outcome per listed key, in list order
`version`	No	Task version after the move
`previous_keys`	No	Keys the task had before, in the order they were left

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.2Sep 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only give the generic mutation profile (readOnly=false, destructive=false, idempotent=false). The description goes far beyond by disclosing key-reassignment mechanics (`previous_keys`, one key per project), that status/sections/links/children stay intact, closed tasks move, frozen projects fail, and that a batch refusal of one task leaves others moved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but well-front-loaded: the core action and key mechanics lead, with error/batch semantics after. Four paragraphs is long for a 3-parameter tool, but nearly every sentence carries distinct behavioral information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still enumerates `results` states (`moved`/`already`/`error`) and failure codes. Combined with the mutation semantics and batch rules, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the 3 baseline is already met by the schema. The description adds integration meaning: that `reason` is filed in the `moved` entry of the case, that a key list follows list order, and that prior keys continue to address the task — context not present in the schema text itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Moves a task to another project') and immediately enriches it with scoping rules that no sibling like update_task or create_task shares. An agent can distinguish this from every sibling on the strength of the first clause alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Rich operational context: when a move fails (`project_archived`), how batches behave, and what refusals are pre-validated. It does not, however, explicitly name an alternative tool or state when to prefer this over update_task, so it stops short of the 5-tier routing guidance.

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