Skip to main content
Glama
Sign In

OrgGen AI

by ai.orggen
OverviewDiscussionsAdmin

move_task_to_project

Destructive

Moves a task from the ACTIVE project to ANOTHER project, PRESERVING its identifier, its creation date, its emitter, its status and its assignees. This is the action that was missing when a block moves house: after create_nested_project or link_project_to_cell, blocks get recreated but the tasks stayed behind, and recreating them by hand BREAKS the id convergence of create_tasks (a sync replay would duplicate them). A user story takes its subtasks along; a lone subtask is refused. You need WRITE access to both projects, and agent writes must not be locked on the target. Refuses — without writing anything — if the target project already holds a task with the same identifier. The response declares what did NOT follow, and — separately — what followed but loses its meaning in the target project.

Input Schema

NameRequiredDescriptionDefault
cellIdNoThe block of the TARGET project to link the task to. THREE states, and they differ: OMITTED = the task keeps its block link if the target project holds a block with the SAME identifier, otherwise it is detached (keeping its memory: it will relink by itself if that block is created there later); `null` = detach explicitly; an identifier = link to THAT block, which must exist in the target project. Affects only the named task — its subtasks always follow the "omitted" rule.
taskIdYesID of the task to move, in the ACTIVE project. Its identifier is PRESERVED on the other side — this is what keeps the `id` convergence of create_tasks valid. If it is a user story, its subtasks go WITH it.
targetProjectIdYesID of the project that must RECEIVE the task. The caller must have write access on both projects. Identifiers are read with list_projects.
expectedProjectIdNoUUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / cellId / description
      Previous value: -"Le bloc du projet CIBLE auquel rattacher la tâche. TROIS états, et ils diffèrent : OMIS = la tâche garde son ancrage si le projet cible porte un bloc de MÊME identifiant, sinon elle se détache (en gardant sa mémoire : elle se rattachera toute seule si ce bloc y est créé plus tard) ; `null` = détache explicitement ; un identifiant = ancre à CE bloc, qui doit exister dans le projet cible. N’affecte que la tâche nommée — ses sous-tâches suivent toujours la règle « omis »."New value: +"The block of the TARGET project to link the task to. THREE states, and they differ: OMITTED = the task keeps its block link if the target project holds a block with the SAME identifier, otherwise it is detached (keeping its memory: it will relink by itself if that block is created there later); `null` = detach explicitly; an identifier = link to THAT block, which must exist in the target project. Affects only the named task — its subtasks always follow the \"omitted\" rule."
    • changedInput schema / properties / expectedProjectId / description
      Previous value: -"UUID du projet visé par CET appel. Cible RÉELLEMENT ce projet au lieu du projet de session. Refusé sans rien modifier si l'accès n'est pas accordé."New value: +"UUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted."
    • changedInput schema / properties / targetProjectId / description
      Previous value: -"ID du projet qui doit RECEVOIR la tâche. L’appelant doit avoir un accès en écriture sur les deux projets. Les identifiants se lisent avec list_projects."New value: +"ID of the project that must RECEIVE the task. The caller must have write access on both projects. Identifiers are read with list_projects."
    • changedInput schema / properties / taskId / description
      Previous value: -"ID de la tâche à déplacer, dans le projet ACTIF. Son identifiant est PRÉSERVÉ de l’autre côté — c’est ce qui garde valide la convergence par `id` de create_tasks. Si c’est une US, ses sous-tâches partent AVEC elle."New value: +"ID of the task to move, in the ACTIVE project. Its identifier is PRESERVED on the other side — this is what keeps the `id` convergence of create_tasks valid. If it is a user story, its subtasks go WITH it."
  2. Changed1 schema field changed
    • changedInput schema / properties / targetProjectId / description
      Previous value: -"ID du projet qui doit RECEVOIR la tâche. Il te faut un accès en écriture sur les deux projets. Appelle list_projects pour les identifiants."New value: +"ID du projet qui doit RECEVOIR la tâche. L’appelant doit avoir un accès en écriture sur les deux projets. Les identifiants se lisent avec list_projects."
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Despite annotations already flagging destructiveHint=true, the description adds substantial behavioral context: the operation is atomic (refuses without writing anything on duplicate identifier), permissions required on both projects, and the response reports what did not follow and what followed but loses meaning. No contradiction with 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?

Front-loaded with the core action and preservation guarantees, then flows into motivation, constraints, refusal behavior and response semantics. Despite being a single dense paragraph, every sentence adds decision-relevant information and nothing is wasted.

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 mutation with no output schema, the description covers the required permissions, atomic refusal conditions, subtask propagation rules, and what the response will report. An agent has everything needed to decide whether to call it and what to expect.

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

Parameters3/5

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

Schema coverage is 100%, so each parameter is already fully documented, including cellId's three-state semantics and the identifier preservation on taskId. The description reinforces the identifier-preservation behavior but does not add new parameter-level syntax or format details beyond the schema; baseline 3 is appropriate when the schema does the heavy lifting.

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 from the ACTIVE project to ANOTHER project) and enumerates exactly what is preserved (identifier, creation date, emitter, status, assignees). It clearly distinguishes itself from siblings like create_nested_project, link_project_to_cell and create_tasks by explaining the gap it fills.

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?

Explicitly describes when to use it (after a block moves house via create_nested_project or link_project_to_cell) and why the alternative of recreating tasks by hand is wrong. It also gives concrete when-not conditions: lone subtasks are refused, missing write access on either project is refused, agent writes locked on target are refused, and duplicate identifiers abort the move without writing.

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

All OrgGen AI 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