An AI client can create activities from a description and make a targeted change to an existing plan. Rillsoft Project calculates the dates. Creating activities, assigning roles, staffing them and saving are separate actions. These two examples show the arguments and the checks between actions.
Prerequisites: a connected MCP client, test data, approved write access and an understanding of undo and file limits. Do not run these writes against someone else’s project or an unprotected original. Every JSON line is a separate tools/call parameter object; replace UUID placeholders with results from your session.
Example 1: build a small plan from a description#
Starting point: a dedicated, empty test session with the appropriate resource pool. Save any existing unsaved plan first, or discard it only after an explicit decision. The new project’s file does not exist yet.
User request: “Create a project called Demo with design followed by review. Design takes 16 working hours and review 8 working hours. Start on 2 November 2026 at 08:00. Do not assign employees or save yet.”
Before executing, clarify: Which calendar applies? Are these hours duration or effort? Which role and how many people are needed? May the current dataset be closed? Here the hours are activity durations; role assignment follows only after confirmation. The start is after the documented editorial date. For a later replay, agree the start and status date again.
Create the project and activities#
After approval to create the test project:
{"name":"rillsoft_project_create","arguments":{"name":"Demo"}}
{"name":"rillsoft_project_update","arguments":{"start":"02.11.2026 08:00"}}
{"name":"rillsoft_task_create","arguments":{"name":"Design","start":"02.11.2026 08:00","durationHours":16}}
{"name":"rillsoft_task_create","arguments":{"name":"Review","start":"02.11.2026 08:00","durationHours":8}}Record the returned UUIDs as <DESIGN_UUID> and <REVIEW_UUID>. English activity names keep the technical example identical in DE and EN. Then link the existing activities finish-to-start:
{"name":"rillsoft_task_dependency_create","arguments":{"predecessorUuid":"<DESIGN_UUID>","successorUuid":"<REVIEW_UUID>","type":"finish_start"}}
{"name":"rillsoft_project_tree_get","arguments":{}}
{"name":"rillsoft_project_conflict_list","arguments":{}}Check: The tree must contain two activities with durations of 16 and 8 hours and the finish-to-start dependency. Review follows the calculated finish of Design. No fixed finish date is promised: calendar, status date, fixed constraints and existing settings affect the calculation. Compare names, durations, the link and calculated dates with the Gantt chart.
Set role demand separately#
Read the roles in the actual pool. Set demand only after confirming role and quantity:
{"name":"rillsoft_resource_pool_catalog_list","arguments":{"types":["role"]}}The following example applies only if returned role 12001 is the approved Mechanical design role from the machinery sample pool:
{"name":"rillsoft_task_role_assignment_set","arguments":{"taskUuid":"<DESIGN_UUID>","roleId":12001,"quantity":1}}
{"name":"rillsoft_project_tree_get","arguments":{}}
{"name":"rillsoft_project_conflict_list","arguments":{}}A role assignment creates demand. It does not yet staff the activity with an employee. An open staffing balance may therefore be correct; it is not a failure to create the activity.
Save only after approving the result#
Confirm a new, unused file path, then approve the disk write separately:
{"name":"rillsoft_project_file_save_as","arguments":{"path":"C:/MCP-Test/Demo.rpj"}}The directory must exist. Saving does not create an undo step. Tested on 19 October 2026 in DE and EN, build 10.0.626: Design runs from 2 November at 08:00 to 3 November at 17:00; Review runs on 4 November from 08:00 to 17:00. Saving and reopening preserved activity data; the old undo history was no longer available.
A larger case already executed: Create a plan from a description was tested on 5 October 2026 against build 10.0.624: Packaging cell P-80 with 3 phases, 8 sections, 26 activities, 4 milestones, 38 dependencies and 26 role assignments. Rillsoft Project calculated completion on 20 January 2027. This interpretation places acceptance after the trial run; the supplied reference project finishes one working day earlier. That earlier run complements the separate small-example test of 19 October 2026.
Example 2: make a targeted change to an existing activity#
Starting point: a copy of an existing project; the selected activity has a duration of 16 hours. Read the tree, identify its UUID and record duration, start, finish, fixed state, successors and conflicts.
User request: “Following the review, design needs 24 rather than 16 hours. Change only the duration, show the impact and do not save yet.”
The client confirms the activity, duration versus effort and permission to write. It does not assign its own successor dates:
{"name":"rillsoft_project_tree_get","arguments":{}}
{"name":"rillsoft_task_update","arguments":{"uuid":"<DESIGN_UUID>","durationHours":24}}
{"name":"rillsoft_project_tree_get","arguments":{}}
{"name":"rillsoft_project_conflict_list","arguments":{}}Check: Duration is now 24 hours, with the same activity and dependencies. Compare the application’s calculated start/finish dates and new conflicts with the previous state. A fixed successor or calendar may produce a different effect from the unconstrained example. A rejection does not authorise removing a fixed constraint automatically.
To test recovery, undo exactly this last change, provided no other editing has occurred since:
{"name":"rillsoft_history_undo","arguments":{}}
{"name":"rillsoft_project_tree_get","arguments":{}}Duration must return to 16 hours; compare successor dates and assignments with the initial tree too. One undo reverses the latest mutation, not all calls in the example. DE/EN run on 19 October 2026, build 10.0.626: after the change, Design finishes on 4 November at 17:00 and Review on 5 November at 17:00. Undo restores the entire previous tree, including successor dates. Call rillsoft_project_file_save only after confirming both the intended final state and saving.
From role demand to confirmed employee assignment#
The documented staffing workflow starts on a copy of the supplied Packaging cell P-80, not the small Demo project. First read candidates and conflicts:
{"name":"rillsoft_task_resource_candidate_list","arguments":{"type":"employee"}}
{"name":"rillsoft_project_conflict_list","arguments":{}}Propose staffing per activity using role, open balance, free, availability, alreadyAssigned and scheduleConflict. A suitable candidate is not yet assigned. After approval of automatic staffing of the open slots, make a separate call:
{"name":"rillsoft_task_resource_assignment_fill","arguments":{"type":"employee","mode":"automatic"}}
{"name":"rillsoft_task_resource_candidate_list","arguments":{"type":"employee"}}
{"name":"rillsoft_project_conflict_list","arguments":{}}
{"name":"rillsoft_project_tree_get","arguments":{}}automatic authorises the assistant to choose within the current dataset. Approval limited to named individuals does not authorise this broader call; use targeted assignments for that case. Candidate listing and the staffing assistant are licence-dependent. The assistant requires progress of 0% under the contract.
Runtime evidence, 29 September 2026, build 10.0.624, DE and EN: 34 slots in 24 activities staffed using 19 personnel resource IDs (two entries share a name, so this is not a count of distinct people), with no personal overload afterwards. Four activities remained open or partly staffed; the conflict list also contains machine demand. Its total must therefore not be presented as the number of unstaffed activities. The assistant creates one undo step; the run did not save. Staff open roles explains the remaining gaps.
Next, check resource capacity: absence of personal overload does not establish that every role demand is covered. Rillsoft Project describes the product features and how to obtain it.
- Product version
- Rillsoft Project 10.0.626
- Last verified
- 2026-10-19