Skip to main content
Glama
rillsoft

Rillsoft Project MCP server

Official

Move element

rillsoft_element_move

Move tasks or subprojects within Rillsoft Project, reassigning WBS codes while preserving dependencies, assignments, and valid display rows.

Instructions

Moves elements - here an element is a task or a subproject. Give exactly one of position with newParentUuid, direction, or extractFromSubproject. RP reassigns the WBS codes; dependencies and assignments survive. Display rows stay valid: where only part of a row moves away, the row is split cleanly. In a portfolio no element changes its project and none goes directly below the portfolio, as in the user interface; with direction the projects themselves can be reordered at portfolio level. One undo step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uuidNoUUID of the task or subproject; give either uuid or uuids. After a rillsoft_task_split one UUID stands for every part of that task, and they then move together
uuidsNoUUIDs of several elements that move together. This is the only way to move a display row built from different tasks in one piece; a nested selection is resolved for you, so a child moves with its subproject
numberNonarrows an ambiguous UUID down to one part; only together with uuid
positionNozero-based target position below the parent; empty appends at the end
directionNoa relative step by one display row, as in the user interface. Only together with uuid. Where the element sits at the edge already, the answer is moved:false and no undo step is created
newParentUuidNoUUID of the new parent subproject; empty keeps the current parent and changes the position only
extractFromSubprojectNotrue = one level up, below the grandparent

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
wbsNoWBS code
nameNoname
uuidNoUUID of the element
movedYesfalse = the row was already at the edge; 'reason' says why
startNostart, DD.MM.YYYY hh:mm
finishNofinish, DD.MM.YYYY hh:mm
numberNonumber of the element; unique even for split tasks
reasonNowhy nothing was moved; only with moved:false
elementsNoall moved elements with their new parent
parentUuidNoUUID of the parent project or subproject

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv10.0.626

TDQS

A4.1/5.0
Behavior5/5

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

Adds substantial behavioral context beyond the annotations: WBS codes are reassigned, dependencies and assignments survive, display rows split cleanly when partially moved, portfolio-level restrictions apply, direction can reorder projects at portfolio level, and the operation is one undo step. Annotations only give basic flags, so the description carries useful operational detail.

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?

The description is front-loaded with the core purpose and parameter rule, then layered with behavioral details. It is appropriately sized for a complex move operation, though the abbreviation 'RP' is unexplained and a couple of clauses could be tighter.

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 rich schema, output schema, and annotations, the description covers the key behavioral constraints an agent needs: parameter combination rules, data preservation, undo behavior, display-row integrity, and portfolio limitations. Nothing critical appears missing for correct invocation.

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 schema already documents parameters in detail. The description still adds meaning by tying 'position' to 'newParentUuid', clarifying the role of 'direction' for portfolio-level project reordering, and explaining the element concept for uuid/uuids, though much of the combination logic is already in the schema.

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

Purpose4/5

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

States a specific verb and resource ('Moves elements') and clarifies that an element is a task or subproject, which helps distinguish the resource. However, it does not explicitly differentiate from siblings like rillsoft_element_reorder, so an agent may still need to infer which move/reorder tool to pick.

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

Usage Guidelines3/5

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

The description gives clear parameter combination rules ('exactly one of position with newParentUuid, direction, or extractFromSubproject') and some portfolio context, but it does not state when to use this tool instead of alternatives such as rillsoft_element_reorder or rillsoft_element_subproject_group. Usage is largely implied.

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

Deploy Server

Other Tools