↓ Zum Hauptinhalt springen
Rillsoft AI
Rillsoft verbinden

Entwickler: der Vertrag des MCP-Servers

Projekte mit MCP erstellen und ändern

Einen Projektplan mit MCP erstellen und gezielt ändern: zwei Beispiele mit Werkzeugaufrufen, Ergebniskontrolle und Undo.

Ein KI-Client kann aus einer Beschreibung Vorgänge anlegen und einen vorhandenen Plan gezielt ändern. Rillsoft Project berechnet die Termine. Erstellen, Rollen zuordnen, Personen besetzen und Speichern sind getrennte Aktionen. Die beiden Beispiele zeigen die Argumente und die Kontrollen zwischen diesen Aktionen.

Voraussetzungen: verbundener MCP-Client, Testbestand, freigegebener Schreibzugriff und Kenntnis der Undo- und Dateigrenzen. Führen Sie keinen der Schreibblöcke an einem fremden oder ungesicherten Projekt aus. Alle JSON-Zeilen sind einzelne tools/call-Parameterblöcke; UUID-Platzhalter müssen durch die Ergebnisse Ihrer Sitzung ersetzt werden.

Beispiel 1: aus einer Beschreibung einen kleinen Plan aufbauen
#

Ausgangslage: eine eigens angelegte, leere Testsitzung mit dem passenden Ressourcenpool. Ein vorhandener ungespeicherter Plan wird vorher gesichert oder nach ausdrücklicher Entscheidung verworfen. Die Datei des neuen Projekts existiert zunächst nicht.

Nutzerauftrag: „Lege einen Plan Demo mit Konstruktion und anschließender Prüfung an. Konstruktion dauert 16 Arbeitsstunden, Prüfung 8 Arbeitsstunden. Start ist der 2. November 2026 um 08:00. Noch keine Personen einteilen und nicht speichern.“

Vor der Ausführung klärt der Client: Welcher Kalender gilt? Sind die genannten Stunden Dauer oder Aufwand? Welche Rolle und wie viele Personen werden benötigt? Darf der geöffnete Bestand verlassen werden? Im Beispiel sind es Vorgangsdauern; eine Rollenzuordnung erfolgt erst nach Bestätigung. Der Start liegt nach dem dokumentierten Redaktionsdatum. Bei späterer Wiederholung müssen Start und Statusdatum erneut abgestimmt werden.

Projekt und Vorgänge anlegen
#

Nach Freigabe des neuen Testprojekts:

{"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}}

Notieren Sie die zurückgegebenen UUIDs als <DESIGN_UUID> und <REVIEW_UUID>. Die englischen Vorgangsnamen halten das technische Beispiel in DE und EN identisch. Verknüpfen Sie die vorhandenen Vorgänge anschließend Ende–Anfang:

{"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":{}}

Kontrolle: Der Baum muss zwei Vorgänge mit 16 und 8 Stunden Dauer sowie die Ende–Anfang-Verknüpfung enthalten. Die Prüfung folgt dem berechneten Ende der Konstruktion. Ein fixes Enddatum wird hier nicht versprochen: Kalender, Statusdatum, Fixierungen und vorhandene Einstellungen sind Teil der Rechnung. Vergleichen Sie Namen, Dauern, Verbindung und berechnete Termine mit dem Balkenplan.

Rollenbedarf separat festlegen
#

Lesen Sie die Rollen des tatsächlich verwendeten Pools. Erst nach Bestätigung von Rolle und Menge wird der Bedarf gesetzt:

{"name":"rillsoft_resource_pool_catalog_list","arguments":{"types":["role"]}}

Das folgende Beispiel gilt nur, wenn die zurückgelieferte Rolle 12001 die bestätigte Konstruktion Mechanik des Maschinenbau-Beispielpools ist:

{"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":{}}

Eine Rollenzuordnung legt Bedarf an. Sie besetzt den Vorgang noch nicht mit einer Person. Eine offene Personalbilanz kann daher korrekt sein; sie ist kein Fehler beim Anlegen des Vorgangs.

Speichern nur nach Ergebnisfreigabe
#

Bestätigen Sie einen neuen, noch nicht belegten Dateipfad und erst danach den Schreibvorgang auf den Datenträger:

{"name":"rillsoft_project_file_save_as","arguments":{"path":"C:/MCP-Test/Demo.rpj"}}

Der Ordner muss vorhanden sein. Das Speichern erzeugt keinen Undo-Schritt. Geprüft am 19.10.2026 in DE und EN, Build 10.0.626: Konstruktion 02.11.2026 08:00–03.11.2026 17:00, Prüfung 04.11.2026 08:00–17:00. Speichern und Wiederöffnen erhielten die Vorgangsdaten; die alte Undo-Historie war danach nicht mehr verfügbar.

Bereits ausgeführter größerer Fall: Der Plan aus einer Beschreibung wurde am 05.10.2026 gegen Build 10.0.624 geprüft: Verpackungszelle P-80 mit 3 Phasen, 8 Abschnitten, 26 Vorgängen, 4 Meilensteinen, 38 Verknüpfungen und 26 Rollenzuordnungen. Rillsoft Project berechnete den 20.01.2027 als Abschluss. Die Abnahme liegt in dieser Interpretation hinter dem Probelauf; die Vorlage endet einen Arbeitstag früher. Dieser ältere Lauf ergänzt den gesonderten Nachweis des kleinen Beispiels vom 19.10.2026.

Beispiel 2: einen vorhandenen Vorgang gezielt ändern
#

Ausgangslage: Kopie eines vorhandenen Projekts; der ausgewählte Vorgang hat 16 Stunden Dauer. Lesen Sie den Baum, bestimmen Sie seine UUID und halten Sie Dauer, Start, Ende, Fixierung, Nachfolger und Konflikte fest.

Nutzerauftrag: „Die Konstruktion braucht nach dem Review 24 statt 16 Stunden. Ändere nur die Dauer, zeige die Auswirkungen und speichere noch nicht.“

Der Client bestätigt den richtigen Vorgang, die Bedeutung von Dauer gegenüber Aufwand und die Schreibfreigabe. Er setzt keine eigenen Folgetermine:

{"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":{}}

Kontrolle: Dauer nun 24 Stunden, gleicher Vorgang und gleiche Verknüpfungen. Vergleichen Sie die vom Programm berechneten Start-/Endtermine und neue Konflikte mit vorher. Ein fixierter Folgevorgang oder ein Kalender kann eine andere Wirkung haben als im freien Beispiel. Bei Ablehnung wird nicht automatisch eine Fixierung aufgehoben.

Zur Probe nehmen Sie genau diese letzte Änderung zurück, sofern seitdem keine andere Bearbeitung erfolgt ist:

{"name":"rillsoft_history_undo","arguments":{}}
{"name":"rillsoft_project_tree_get","arguments":{}}

Die Dauer muss wieder 16 Stunden betragen; auch Folgetermine und Zuordnungen werden gegen den Ausgangsbaum geprüft. Ein Undo nimmt die letzte Mutation zurück, nicht sämtliche Aufrufe des gesamten Beispiels. Lauf vom 19.10.2026, Build 10.0.626, DE und EN: Nach der Änderung endet Design am 04.11.2026 um 17:00, Review am 05.11.2026 um 17:00. Undo stellt den gesamten vorherigen Baum einschließlich Folgeterminen wieder her. rillsoft_project_file_save folgt nur, wenn der tatsächlich gewünschte Endzustand und das Speichern bestätigt sind.

Von Rollenbedarf zu bestätigter Personalzuordnung
#

Der belegte Besetzungsablauf beginnt auf einer Kopie der mitgelieferten Verpackungszelle P-80, nicht auf dem kleinen Demo-Projekt. Lesen Sie zuerst Kandidaten und Konflikte:

{"name":"rillsoft_task_resource_candidate_list","arguments":{"type":"employee"}}
{"name":"rillsoft_project_conflict_list","arguments":{}}

Formulieren Sie pro Vorgang einen Vorschlag aus Rolle, offener Bilanz, free, availability, alreadyAssigned und scheduleConflict. Eine geeignete Person ist noch nicht eingeteilt. Nach Bestätigung der automatischen Besetzung der offenen Stellen folgt ein eigener Aufruf:

{"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 ist die Freigabe für die Auswahl durch den Assistenten im aktuellen Bestand. Eine nur für einzelne benannte Personen erteilte Freigabe erlaubt diesen breiteren Aufruf nicht; dafür werden gezielte Zuordnungen verwendet. Kandidatenliste und Besetzungsassistent sind lizenzgebunden. Der Assistent setzt laut Vertrag Fortschritt 0 % voraus.

Laufbeleg vom 29.09.2026, Build 10.0.624, DE und EN: 34 Plätze in 24 Vorgängen mit 19 Personal-Ressourcen-IDs besetzt (zwei Einträge tragen denselben Namen; daraus folgt keine Zahl verschiedener Menschen), anschließend keine persönliche Überlastung. Vier Vorgänge blieben offen oder teilweise besetzt; die Konfliktliste enthält zusätzlich Maschinenbedarf. Deshalb darf ihre Gesamtzahl nicht als Zahl unbesetzter Personalvorgänge ausgegeben werden. Der Assistent erzeugt einen Undo-Schritt; Speichern wurde im Lauf nicht ausgeführt. Die Promptseite Offene Rollen besetzen erläutert die verbliebenen Lücken.

Prüfen Sie anschließend Ressourcenkapazität: keine persönliche Überlastung bedeutet nicht, dass jeder Rollenbedarf gedeckt ist. Produktfunktionen und Bezug stehen bei Rillsoft Project.

Produktversion
Rillsoft Project 10.0.626
Zuletzt geprüft
2026-10-19