Skip to main content
Glama
rillsoft

Rillsoft Project MCP server

Official

Set project properties

rillsoft_project_update
Idempotent

Updates main project properties like name, dates, calendar, color, category, status, customer, priority, and scheduling settings. Adjusts project period and input options, not display timescale.

Instructions

Sets properties of the main project: key data (name, start, finish, fixing), calendar and color, the master-data references category, status, customer, priority and plan variant, plus scheduling mode, input step widths and the two metric switches. This changes the period of the project, not the time scale of the display (use rillsoft_timescale_apply for that). Subprojects go through rillsoft_subproject_update. One undo step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoname of the project
colorNobar color as #RRGGBB or 'automatic'
fixedNofix the project start
startNoproject start, formatted DD.MM.YYYY hh:mm
finishNoproject finish, formatted DD.MM.YYYY hh:mm
priorityNopriority of the project in percent (0 to 100), as in the dialog. In a portfolio refused: the tool addresses the portfolio, the field belongs to each project
statusIdNoid of the project status from rillsoft_resource_pool_catalog_list (types: project_status); 0 = none. In a portfolio refused: the tool addresses the portfolio, the field belongs to each project
calendarIdNoid of the calendar from rillsoft_resource_pool_catalog_list (types: calendar); the main project always carries a concrete id
categoryIdNoid of the project category from rillsoft_resource_pool_catalog_list (types: project_category); 0 = none. In a portfolio refused: the tool addresses the portfolio, the field belongs to each project
customerIdNoid of the customer from rillsoft_resource_pool_catalog_list (types: project_customer); 0 = none. In a portfolio refused: the tool addresses the portfolio, the field belongs to each project
primaryColorNopass the color on to child elements that carry none of their own
effortEditableNoeffort may be entered on the task
schedulingModeNocapacity_driven computes with the calendars and absences of the assigned resources, deadline_driven computes without them. In a portfolio refused: the tool addresses the portfolio, the mode belongs to each project
validationModeNowhat to do where existing elements would fall outside the new period: strict (the default) refuses and names the culprits, extend widens the period to cover what exists, force applies it anyway; effective only together with start or finishstrict
planningVariantNonumber of the plan variant (baseline) of the project; 0 = dynamic. Refused in a portfolio: there is no baseline there, not even per project
timeStepMinutesNoinput time grid in minutes: 1, 5, 10, 15, 30 or 60, at most the grid of the calendar
durationStepUnitNounit used to enter a duration
quantityStepUnitNounit used to enter a quantity
dynamicRedistributionNoredistribute effort dynamically; permitted only with schedulingMode capacity_driven. In a portfolio refused: the tool addresses the portfolio, the switch belongs to each project
outputQuantityEditableNooutput quantity may be entered on the task

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.1/5.0
Behavior4/5

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

Annotations already declare a non-readOnly, idempotent, non-destructive, closed-world mutation, so the safety bar is partly covered. The description adds genuinely new behavioral context beyond the schema by disclosing "One undo step" and clarifying that the period, not the display time scale, is affected.

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 property inventory is front-loaded in the first sentence, followed by two short routing/behavioral sentences. Slightly long enumeration, but each clause maps to real schema content and nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an anyOf-required schema of 20 optional fields, full schema descriptions, an output schema, and annotations supplying the safety profile, the description supplies what an agent needs: purpose, routing to siblings, and undo semantics. Minor gaps remain around partial-update semantics and the anyOf requirement, but the coverage is strong.

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%, so every one of the 20 optional parameters is already documented in the schema, including enum meanings, portfolio refusals and defaults. The description's list of property categories largely restates that structure and adds no format or constraint detail beyond it — the correct baseline of 3.

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 description opens with a specific verb and resource ("Sets properties of the main project") and enumerates the property groups it touches (key data, calendar/color, master-data references, status, customer, priority, plan variant, scheduling mode, step widths, metric switches). It explicitly distinguishes itself from rillsoft_subproject_update and rillsoft_timescale_apply, so an agent can separate it from its nearest siblings without inspecting schemas.

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?

It names alternatives with conditions: time-scale display changes go to rillsoft_timescale_apply, subprojects go to rillsoft_subproject_update. That is clear routing, though it does not state when to prefer this over rillsoft_project_create or the property panel sibling tools.

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