Skip to main content
Glama

move_task

Move tasks between projects while preserving status, links, and history. Records the move with reason, supports batch keys, and returns per-task results.

Instructions

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

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 missing main scope, 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
NameRequiredDescriptionDefault
keyYesTask 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
reasonYesWhy the task moves; a blank one is refused with `task_move_reason_required`. Filed in the `moved` entry of the task's case
projectYesKey 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
NameRequiredDescriptionDefault
noNoNumber of the `moved` entry in the task's case
keyNoKey the task got in the new project
resultsNoOne outcome per listed key, in list order
versionNoTask version after the move
previous_keysNoKeys the task had before, in the order they were left

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only provide generic hints (readOnly=false, destructive=false, etc.), so the description carries the behavioral disclosure burden. It does so extensively: renumbering, `previous_keys`, preservation of status/sections/links/parent/children/case, closed-task moves, frozen-project failures, partial batch moves, and whole-call refusals. There is no contradiction with the annotations.

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

Conciseness5/5

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

The description is dense but every sentence earns its place. It front-loads the core action, then methodically covers single moves, batch behavior, error codes, and atomic refusal conditions without filler. The paragraph structure aids scanning.

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?

Given the tool's complexity, the description is complete: it covers auth scope, single and batch moves, key reissuing, preservation of task properties, frozen-project errors, response `results`, and whole-call refusals. Since an output schema exists, the description need not enumerate the full return shape beyond `results`.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It explains that previous keys keep addressing the task, that a task holds at most one key per project, how list order determines new numbers, and the exact per-key versus whole-call error semantics. This is far more than the schema descriptions alone provide.

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?

The first sentence states a specific action and resource: 'Moves a task to another project' and distinguishes the operation by detailing recording of the move and the `moved` entry. The description further clarifies scope with 'One key moves one task' and behavior for frozen projects, leaving no ambiguity about what the tool does.

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?

The description provides clear context for when to use the tool: moving tasks between projects, including closed tasks and batch moves. It notes the `main` token requirement and the `project_archived` failure condition, but it does not explicitly name alternatives or state when not to use this tool versus a sibling.

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