Skip to main content
Glama
rillsoft

Rillsoft Project MCP server

Official

Update task

rillsoft_task_update
Idempotent

Change a task's planning data such as name, dates, duration, notes, task type, and personnel effort redistribution; one undo step, conflicts rolled back.

Instructions

Changes the planning data of a task: name, dates, duration, notes, fixing, display row, task kind and the dynamic redistribution of the personnel effort. It changes the task itself - moving it in the structure goes through rillsoft_element_move, its progress through rillsoft_task_progress_set, its assignments through the rillsoft_task_*_assignment_set family, and a subproject through rillsoft_subproject_update. One undo step; conflicts are rolled back for you.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNocode of the task, the free text field of the task dialog; an empty string clears it. RP does not check it for uniqueness
nameNonew name
uuidYesUUID of the task
fixedNofix the start date
notesNonew notes
startNonew start, DD.MM.YYYY hh:mm
finishNonew finish, DD.MM.YYYY hh:mm
numberNonarrows an ambiguous UUID down to one part. After a rillsoft_task_split all parts carry the same UUID (they keep the baseline reference); the number from rillsoft_project_tree_get is unique per part
sameRowNotrue = draw on one display row together with the WBS predecessor, false = a row of its own (the 'Show on one row' switch of the task dialog)
fixedTypeNotask type: duration, effort, duration_effort (defaults to the application default from the settings). It says which quantity RP holds fixed while computing: duration keeps the duration, effort keeps the effort, duration_effort keeps both. This matches the choice in the task dialog
calendarIdNocalendar of this task, an id from rillsoft_calendar_list; 0 = none of its own, the calendar of the enclosing subproject or project applies. An id that does not exist is refused with unknown_id
durationHoursNonew duration in hours (0 = milestone)
dynamicRedistributionNospread the personnel effort of this task dynamically over the people of one qualification - the switch on the 'Personnel' tab of the task dialog. Three conditions decide whether it takes effect, and two of them make the call fail rather than promise something that never happens: scheduling has to be capacity_driven (with deadline_driven nothing redistributes at all, the same refusal as at the project), and the project must not carry the switch itself (while it does, it wins, and the task dialog locks its box the same way - switch it off through rillsoft_project_update first). The third one is not an error: without named people on the task - a role alone is not enough - the switch stays without effect. Read both sides back through rillsoft_project_tree_get: dynamicRedistribution is this switch, dynamicRedistributionEffective is what the scheduling really applies. Switching it off puts the distribution back to static

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
wbsYesWBS code
nameYesname
uuidYesUUID of the element
startYesstart, DD.MM.YYYY hh:mm
finishYesfinish, DD.MM.YYYY hh:mm
numberYesnumber of the element; unique even for split tasks

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv10.0.626

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false), so safety is covered by structured data. The description adds genuine behavioral context beyond that: 'One undo step; conflicts are rolled back for you' discloses atomicity/rollback semantics, and the dynamicRedistribution note spells out that two precondition failures hard-fail the call while a missing named person silently no-ops. However, no permission/auth requirements or partial-update semantics (what happens to unspecified fields) are stated, so it is not fully load-bearing.

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 verb and the field inventory, then routing, then transactional behavior; no filler sentences. It leans on long, dense compound sentences rather than shorter scannable ones, which costs a little readability but not substance.

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?

Output schema exists, so return values need not be described, and annotations cover the safety profile. Combined with a 13-parameter schema fully documented at 100%, the description still adds the two things an agent needs most: where this tool's responsibility ends (sibling routing) and how failure/rollback behaves.

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 description coverage is 100% and the per-parameter schema text is unusually rich (including the dynamicRedistribution precondition chain and fixedType enum semantics), so the schema does the heavy lifting. The description only re-lists the affected field names rather than adding syntax, format or interaction details beyond the schema, which matches the baseline-3 rule for high coverage.

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?

Opens with a specific verb+resource ('Changes the planning data of a task') and enumerates exactly which fields it owns: name, dates, duration, notes, fixing, display row, task kind, dynamic redistribution. It explicitly carves out the sibling surfaces it does NOT touch (element_move, task_progress_set, the *_assignment_set family, subproject_update), so an agent can separate it from adjacent update tools without opening schemas.

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?

Provides explicit routing rules: structural moves go to rillsoft_element_move, progress to rillsoft_task_progress_set, assignments to the rillsoft_task_*_assignment_set family, subproject changes to rillsoft_subproject_update. This is a when-not-to-use-this-here map naming the exact alternatives, which is the strongest form of usage guidance.

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