Skip to main content
Glama
Sign In

Onplana

by io.github.Onplana
OverviewDiscussionsAdmin

move_task

DestructiveIdempotent

Move a task and its direct subtasks to another project in the same workspace; subtasks of those subtasks stay in the source project. The task keeps its id, comments, attachments, history, assignee, tags, custom field values and dependencies, and its timesheet hours move with it, which a new task plus a delete of the old one would lose. A sprint and an epic belong to one project, so both are cleared on every task that moves; a subtask moved on its own leaves its parent; collaborators who are not in the target project are removed. Links to tasks left behind are kept and span the two projects. The result counts what was cleared, and Undo moves the task back and puts back its sprint, epic, parent, place and collaborators where they still exist. Requires permission to edit any task (task.edit.any) in both projects. Refused while the task is mirrored from Microsoft Planner, and while an accounting export holds its hours. To move a task into a sprint or an epic in its own project, use move_task_to_sprint or move_task_to_epic. dryRun: true returns the same counts and writes nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "taskId": "<taskId>",
      "targetProjectId": "<targetProjectId>"
    },
    "name": "move_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskIdYesThe task to move. Its direct subtasks move with it.
restoreNoFilled by Undo from the recorded move. Refused on any other call.
targetProjectIdYesThe project to move it to. Use list_projects to find project ids.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag destructiveHint=true and idempotentHint=true; the description goes far beyond by enumerating what survives the move (id, comments, attachments, history, assignee, tags, custom fields, dependencies, timesheet hours), what is destroyed (sprint, epic, parent link, non-target collaborators), and what persists across projects (links to tasks left behind). It also discloses the Undo path and the exact refusal conditions, which no structured field conveys.

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?

Front-loaded with the action and its subtask scope, then ordered by consequence: preservation, cleared fields, link behavior, result/Undo, permissions, refusals, alternatives, dryRun. Every sentence carries unique information, though the dense semicolon-chained middle sentences make it heavier to scan than necessary.

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?

For a destructive, cascade-affecting cross-project move with no output schema, it covers preservation semantics, side effects, authorization, refusal states, reversibility, and even the shape of the result ('counts what was cleared'). Nothing an agent needs to decide or call correctly is missing.

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 taskId and targetProjectId are already documented, but the description adds real meaning to 'restore' by explaining that Undo puts back sprint, epic, parent, place and collaborators only 'where they still exist'. The gain is capped because dryRun is described as a callable option while it is absent from the properties list under additionalProperties=false, so an agent could pass a key the schema rejects.

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?

Names a specific verb and resource ('Move a task and its direct subtasks') plus the destination constraint ('another project in the same workspace'), and immediately bounds the scope by excluding deeper descendants. It also explicitly routes sprint/epic moves to move_task_to_sprint and move_task_to_epic, so the agent can separate it from the closest siblings without opening a schema.

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

Usage Guidelines5/5

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

States the conditions that select other tools ('To move a task into a sprint or an epic in its own project, use move_task_to_sprint or move_task_to_epic') and the conditions that block this one (Planner mirroring, an accounting export holding hours, missing task.edit.any in either project). It also documents the dryRun trial path, which is exactly the guidance an agent needs before a destructive move.

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

All Onplana toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources