MCP-Fehler, Undo und sichere Schreibzugriffe

Bei einem fehlgeschlagenen MCP-Aufruf müssen Sie zuerst unterscheiden: Hat der Transport den Aufruf abgewiesen, hat Rillsoft Project ihn fachlich abgelehnt oder fehlt lediglich die Antwort? Eine unterbrochene Verbindung beweist nicht, dass eine Änderung unterblieben ist. Vor einem erneuten Schreibaufruf lesen Sie deshalb den betroffenen Zustand.

Diese Referenz ergänzt den MCP-Vertrag und die Claude-Einrichtung. Vertragsstand: generierter Werkzeugkatalog aus Build 10.0.626, Quellenabgleich 19.10.2026. Die unten ausdrücklich genannten Prüflücken sind keine bestandenen Laufzeittests.

Situation, Antwort, sichere Reaktion

#

Die HTTP-Fälle stammen aus der Produktdokumentation zum Zugriffsschutz. Die Codes stammen aus dem Entwicklervertrag; nicht jeder Fehler hat denselben Antwortaufbau. Für Nur-Lesen wird hier bewusst kein unbestätigter Code ergänzt. Am 19.10.2026 wurde in DE und EN (Build 10.0.626) der Antwortkörper eines Schreibaufrufs absichtlich verworfen. Die anschließende Leseabfrage erkannte die bereits erfolgte Änderung von 16 auf 32 Stunden. Ohne Wiederholung stellte Undo den Ausgangsbaum wieder her. Das prüft den Umgang mit einer verlorenen Antwort, nicht einen Serverabsturz oder jede mögliche Netzunterbrechung.

Protokollfehler und Werkzeugfehler getrennt auswerten

#

Ein JSON-RPC-Fehler steht im Feld error. Ein fachlich abgelehnter Werkzeugaufruf kann dagegen einen regulären JSON-RPC-result liefern, darin aber isError: true. Prüfen Sie beide Ebenen. structuredContent beschreibt erfolgreiche Ausgaben und ist kein Ersatz für die Fehlerprüfung.

Dieses absichtlich ungültige Argumentbeispiel gehört ausschließlich auf einen Testbestand:

{"name":"rillsoft_task_create","arguments":{"name":"Date check","start":"32.13.2020"}}

Der dokumentierte maschinenlesbare Code ist invalid_date_format. Der deutsche Laufzeittext im bestehenden Vertragsnachweis lautet:

Ungültiger Wert für 'start': '32.13.2020' — erwartet wird DD.MM.YYYY hh:mm oder YYYY-MM-DDThh:mm

Verwenden Sie für die Fehlerbehandlung den Code, nicht einen Vergleich des deutschen Satzes. Die englische Fassung zeigt den englischen Nachweis. Meldungen folgen der Sprache des gestarteten Rillsoft Project; eine Website-Übersetzung ändert die Produktsprache nicht.

Schreibfreigabe vor Änderung, Speicherfreigabe vor Dateiaktion

#

Vor einer Änderung müssen Ausgangsdatei, Zielobjekt und gewünschte Wirkung feststehen. Lesen Sie die UUID aus dem aktuellen Baum und zeigen Sie den Vorschlag mit alten und neuen Werten. Fragen Sie bei fehlender Dauer, unklarer Person, nicht passender Rolle oder unklarem Termin nach. Eine allgemeine Verbindungserlaubnis entscheidet diese fachlichen Fragen nicht.

Für eine freigegebene Änderung der Dauer sieht der getrennte Ablauf so aus; <TASK_UUID> wird aus dem aktuellen Baum ersetzt:

{"name":"rillsoft_project_tree_get","arguments":{}}
{"name":"rillsoft_task_update","arguments":{"uuid":"<TASK_UUID>","durationHours":24}}
{"name":"rillsoft_project_tree_get","arguments":{}}
{"name":"rillsoft_project_conflict_list","arguments":{}}

Jede Zeile ist ein einzelner tools/call-Parameterblock. Erst wenn das Ergebnis fachlich geprüft und das Speichern freigegeben ist, folgt rillsoft_project_file_save beziehungsweise bei einer neuen Datei rillsoft_project_file_save_as mit bestätigtem absolutem Pfad. Überschreiben ist eine eigene Entscheidung. Die Projektbeispiele führen diese Schritte im Zusammenhang aus.

Was Undo zurücknimmt

#

Ein mutierender Werkzeugaufruf entspricht laut Vertrag einem Undo-Schritt. Die Historie wird mit der Oberfläche geteilt: Zwischenzeitliche Handarbeit kann der neueste Schritt sein. Deshalb Undo niemals nach einer angenommenen Aufrufzahl auf einen unbekannten Zustand anwenden.

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

Vergleichen Sie den Baum mit dem vor der Änderung gespeicherten Vergleichszustand. Prüfen Sie die betroffenen Felder und Folgetermine. Eine Erfolgsmeldung von Undo allein belegt nicht, dass sämtliche Änderungen eines längeren Dialogs zurückgenommen sind. Ein Aufbau mit vielen Werkzeugaufrufen benötigt entsprechend viele Bearbeitungsschritte; der Assistent zum Personalzuordnen kann dagegen mehrere Zuordnungen in einem Schritt vornehmen.

Speichern, Dateiwechsel und Sitzung sind eigene Grenzen

#

Vor einem Dateiwechsel wird die Analyseansicht zurückgesetzt. Bei einem Wiederherstellungstest arbeiten Sie ausschließlich mit einer Kopie: Ausgangszustand lesen, genau eine Änderung ausführen, Undo ausführen und vergleichen; separat speichern und wieder öffnen, anschließend erneut vergleichen. Der dokumentierte Durchstich enthält diesen Datei-Roundtrip. Die Wiederholung an Testkopien vom 19.10.2026, Build 10.0.626, bestand in beiden Sprachen: Undo stellte den vollständigen Baum wieder her, Speichern/Wiederöffnen erhielt die Vorgangsdaten und leerte die alte Historie. Ungültiges Datum und Schemafehler ließen den Baum unverändert. Ein Serverabsturz während einer Änderung wurde nicht provoziert.

Vorgehen bei unklarem Schreibausgang

#

1. Keine weiteren Schreibaufträge senden. Aufruf, Argumente und Zeitpunkt ohne Zugangsdaten festhalten.
2. Nach Wiederherstellung der Verbindung das tatsächlich geöffnete Projekt identifizieren.
3. Den betroffenen Vorgang und seine Zuordnungen lesen. Wurde er neu angelegt, anhand des vorherigen Baums und der erhaltenen UUID prüfen, ob er bereits existiert; Namen allein sind nicht eindeutig.
4. Entspricht der Zustand dem Ziel, nicht erneut schreiben. Ist er unverändert, einen neuen Versuch erst nach geklärter Ursache und Freigabe ausführen. Bei unklarem oder teilweise abweichendem Zustand anhalten und die Abweichung zeigen.
5. Nach Korrektur Folgetermine und Konflikte prüfen; Speichern bleibt separat.

Diese Schritte sind ein Verfahren zur Zustandsprüfung, keine Zusage atomarer Wiederholung. Produktumfang und Lizenzmöglichkeiten beschreibt Rillsoft Project.

Produktversion

Rillsoft Project 10.0.626

Zuletzt geprüft

2026-10-19