Wir haben unserem MCP-Server einen Rückgängig-Knopf gegeben

Im Juli 2025 löschte der KI-Agent von Replit während eines Code-Freezes die Produktionsdatenbank eines Unternehmens und sagte dem Nutzer dann, die Daten ließen sich nicht wiederherstellen. Es ging doch. Replit hatte ein Rollback, und der Nutzer stellte alles aus einem Checkpoint wieder her. Der Agent wusste nur nicht, dass es diese Funktion gab. Zwei Lehren aus dieser Geschichte haben geprägt, was wir gebaut haben: Der Agent muss wissen, dass es Rückgängigmachen gibt, und Menschen müssen es nutzen können, ohne den Agenten zu fragen.

Wir bauen Privatrak, ein cookieloses Analyse-Tool. Sein MCP-Server lässt Claude, Cursor oder Codex mehr tun, als Ihre Analysen zu lesen. Sie können sie auch einrichten: Feature-Regeln, die benennen, was Menschen anklicken, Funnels, Dashboards, und Klickprobleme als behoben markieren. 17 seiner 44 Tools ändern etwas.

Die meisten MCP-Server mit Schreibzugriff verlassen sich darauf, dass der Client vor jedem Aufruf nachfragt. Wir wollten noch etwas: Hat ein Agent zwanzig Änderungen gemacht, sehen Sie alle in einer Liste und machen sie in einem Schritt rückgängig, ohne zu verlieren, was Sie oder ein Kollege in der Zwischenzeit geändert haben.

Vorher zu fragen reicht nicht

Claude fragt nach, bevor es ein Tool ausführt, das als zerstörerisch markiert ist. Das ist gut, und wir haben unsere Tool-Annotationen dafür sorgfältig gesetzt. Es hängt aber davon ab, dass der Server seine Tools ehrlich beschriftet, und deshalb sagt die MCP-Spezifikation den Clients, diese Beschriftungen als nicht vertrauenswürdig zu behandeln, solange der Server nicht vertrauenswürdig ist. Und es schützt immer nur einen Aufruf, während die Arbeit eines Agenten nicht ein Aufruf ist.

Ein Projekt einzurichten braucht ein Dutzend oder zwanzig Schreibzugriffe: Regeln, einen Funnel, der auf diesen Regeln aufbaut, ein Dashboard, dessen Widgets sie abfragen. Niemand liest die fünfzehnte Bestätigung so sorgfältig wie die erste. Sicherheitsleute nennen das Bestätigungsmüdigkeit (confirmation fatigue), und die Liste der Risiken für KI-Agenten von OWASP führt sie auf. Und die Fehler in einer Einrichtung zeigen sich selten in einem einzelnen Aufruf. Sie zeigen sich später, wenn ein Dashboard das Falsche zählt.

Was Sie dann brauchen, ist keine weitere Bestätigung. Sie müssen alles, was der Agent getan hat, als eine Einheit sehen und diese Einheit zurücknehmen können. Entwickler haben das für Code in der Versionsverwaltung. Für Produkteinstellungen gibt es meist nichts Vergleichbares.

Rückgängigmachen muss im Server leben

Coding-Agenten haben bereits ein Rückgängigmachen. Claude Code und Cursor führen Checkpoints, zu denen man zurückkehren kann. Beide decken aber nur Dateien ab, die der Agent bearbeitet hat. In der Dokumentation von Claude Code steht, dass Änderungen über Befehle nicht erfasst werden, und in der von Cursor, dass das Wiederherstellen eines Checkpoints keine Datenbankmigration rückgängig macht, die der Agent ausgeführt hat. Sobald ein Agent eine API aufruft, kann der Client das nicht mehr zurücknehmen. Das kann nur der Dienst hinter der API.

Auch MCP hilft hier nicht. Die Spezifikation verlangt von Clients, einen Menschen einzubinden und Tool-Aufrufe bestätigen zu lassen, bietet aber nichts für Transaktionen oder Rollback. Wenn Sie also ein Rückgängigmachen für das wollen, was ein Agent in Ihrem Produkt tut, bauen Sie es in Ihren MCP-Server ein. Darum geht es im Rest dieses Artikels.

Eine Aufgabe, ein Lauf

Die Einheit des Rückgängigmachens ist ein Setup-Lauf. Ein Agent startet einen am Anfang einer Aufgabe mit start_setup_run und einer Bezeichnung wie „Checkout tracking“ und gibt dann bei jedem Schreibzugriff seine ID mit. Der Lauf beantwortet die Frage „Was hat der Assistent getan?“

Zwei Regeln machen ihn verlässlich:

• Nichts geschieht außerhalb eines Laufs. Ein schreibendes Tool, das ohne Lauf-ID aufgerufen wird, startet selbst einen Lauf und gibt dessen ID zurück. Auch ein Agent, der die Anweisungen ignoriert, hinterlässt eine Spur, die sich rückgängig machen lässt.
• Läufe, die nichts geändert haben, füllen die Liste nicht. Lehnt die API einen Schreibzugriff ab, löscht das Tool den Lauf, den es dafür gerade gestartet hatte.

In der API schließt sich ein Schreibzugriff einem Lauf über einen Header an, X-Setup-Run-ID, nicht über ein Feld im Body. DELETE hat keinen Body, und alle vierzehn schreibenden Operationen sollten sich auf dieselbe Weise anschließen. Ein Schreibzugriff ohne den Header nimmt genau den Codepfad, den er schon immer nahm, die Läufe haben also nichts verändert, was bereits funktionierte.

Die Läufe erscheinen auch im Dashboard unter Einstellungen, als Änderungen durch KI. Wer den Assistenten verbunden hat, braucht den Assistenten nicht, um rückgängig zu machen, was er getan hat.

Vorher und nachher festhalten, in derselben Transaktion

Jeder Schreibzugriff, der zu einem Lauf gehört, wird zusammen mit einem Protokoll dessen gespeichert, was er geändert hat: dem Zustand vorher und dem Zustand nachher. Beides wird in einer Datenbanktransaktion gespeichert, es geschieht also entweder beides oder keines. Der Lauf ist währenddessen gesperrt, sodass ihn niemand mitten in einem Schreibzugriff rückgängig machen kann.

Der festgehaltene Zustand ist die vollständige Definition: Name und Bedingungen einer Regel, die Schritte eines Funnels, ein Dashboard mit seinen Widgets. Alles, was das Rückgängigmachen zum Wiederaufbau braucht. Die Datenbank erzwingt die Form: Eine Neuanlage hat kein „Vorher“, eine Löschung kein „Nachher“.

Ein Detail kostete uns mehr Zeit als der Rest. Das Rückgängigmachen vergleicht diese Protokolle später mit dem, was jetzt in der Datenbank steht. Lässt sich dasselbe auf zwei gleichbedeutende Arten speichern, schlägt der Vergleich fehl, und jedes Rückgängigmachen sieht nach einem Konflikt aus. Deshalb speichert jeder Schreibzugriff seine Eingabe in genau einer Form.

Rückgängigmachen geht rückwärts

Das Rückgängigmachen spielt die Änderungen des Laufs vom Neuesten zum Ältesten ab, in einer Transaktion:

• Angelegt wird gelöscht.
• Geändert bekommt die Felder zurück, die der Lauf geändert hat.
• Gelöscht wird neu angelegt, mit seiner ursprünglichen ID.

Vom Neuesten zum Ältesten ist wichtig. Ein Agent, der eine Regel angelegt und dann umbenannt hat, muss die Umbenennung vor der Neuanlage zurücknehmen. Und wenn der Lauf etwas angelegt und später selbst gelöscht hat, gibt es dafür gar nichts zu tun.

Die ursprüngliche ID ist wichtiger, als es klingt. Dashboards, Funnels und Links verweisen über die ID auf Dinge. Eine neu angelegte Regel bekommt sogar ihre ursprüngliche Erstellungszeit zurück, weil die Reihenfolge der Regeln entscheidet, welchen Namen die Wegansicht für einen Klick zeigt. Das Rückgängigmachen soll das Projekt genau so zurücklassen, wie es vorher las, nicht nur etwas Gleichwertiges.

Danach wird der Lauf als rückgängig gemacht markiert und sein Bericht gespeichert. Wer erneut fragt, bekommt denselben Bericht, und ein Schreibzugriff, der sich einem rückgängig gemachten Lauf anschließen will, wird abgelehnt.

Nie die Arbeit anderer überschreiben

Das war die schwerste Entscheidung. Zwischen dem Lauf des Agenten und dem Rückgängigmachen arbeiten die Leute weiter. Jemand benennt ein Widget um, das der Agent angelegt hat, oder korrigiert die Bedingung einer Regel. Das Rückgängigmachen darf das nicht zerstören.

Deshalb wird jede Änderung geprüft, bevor sie zurückgenommen wird:

• Eine Neuanlage rückgängig zu machen setzt voraus, dass die Sache noch genau das ist, was der Lauf angelegt hat.
• Eine Änderung rückgängig zu machen setzt voraus, dass jedes Feld, das der Lauf geändert hat, noch den Wert des Laufs hat. Felder, die der Lauf nicht angefasst hat, dürfen sich seitdem geändert haben. Sie gehen ihn nichts an.
• Ein Dashboard, das der Lauf angelegt hat und das jetzt Widgets von jemand anderem enthält, wird nicht gelöscht.
• Etwas neu anzulegen, das die Grenzen des Tarifs überschreiten würde, wird übersprungen, nicht erzwungen.

Schlägt eine Prüfung fehl, wird genau diese Änderung übersprungen und mit dem Grund gemeldet, und der Rest des Laufs wird trotzdem rückgängig gemacht. Wir erwogen, stattdessen das ganze Rückgängigmachen abzubrechen. Dann aber würde ein Widget, das jemand umbenannt hat, die gesamte Einrichtung eines Agenten an Ort und Stelle halten. Überspringen und Melden gibt den Leuten das Rückgängigmachen, um das sie gebeten haben, abzüglich genau der Dinge, die sie seither zu ihren eigenen gemacht haben.

Was als Arbeit eines Menschen zählt, war ebenfalls eine Entscheidung. Ein Widget zu verschieben oder in der Größe zu ändern zählt nicht. Wer ein Widget eines Agenten zur Seite zieht, hat es sich nicht zu eigen gemacht, und es zu löschen zerstört nichts, was er getan hat.

Die Vorschau ist das echte Rückgängigmachen, zurückgerollt

Sie möchten ein Rückgängigmachen sehen, bevor es geschieht. Das MCP-Tool undo_setup_run macht einen Probelauf, wenn nichts anderes gesagt wird, und die Anweisungen des Servers sagen dem Agenten, Ihnen das Ergebnis zuerst zu zeigen. Im Dashboard sagt der Dialog vor der Schaltfläche: „Das passiert beim Rückgängigmachen. Noch wurde nichts geändert.“

Die Vorschau ist keine eigene Vorhersage. Sie führt das tatsächliche Rückgängigmachen aus, jede Prüfung und jeden Schreibzugriff, innerhalb der Transaktion, und rollt die Transaktion dann zurück. Eine Vorhersage, die als eigener Code geschrieben ist, driftet von dem weg, was das Rückgängigmachen wirklich tut, und dann ist die Vorschau genau dann falsch, wenn es darauf ankommt. Ein Codepfad kann sich nicht selbst widersprechen.

Sagen, was nicht zurückkommt

Manches lässt sich nicht exakt rückgängig machen, und so zu tun, als ginge es, ist schlimmer, als es zu sagen.

In Privatrak zählt ein Funnel ab dem Tag, an dem er angelegt wird. Die Daten pro Besucher, mit denen sich frühere Tage neu zählen ließen, werden jede Nacht gelöscht, aus Datenschutzgründen. Das hat zwei Folgen für das Rückgängigmachen:

• Wird ein Funnel rückgängig gemacht, den der Agent angelegt hat, werden auch die Tage gelöscht, die er seither gezählt hat. Die Vorschau sagt, wie viele.
• Ein Funnel, den der Agent gelöscht hat, kommt mit Namen und Schritten zurück, zählt aber ab dem Rückgängigmachen neu. Seine alten Tage sind weg, und der Bericht sagt das.

Die Regel, die wir daraus mitnahmen: Wenn das Rückgängigmachen nicht exakt sein kann, muss die Vorschau sagen, was verloren geht, bevor jemand bestätigt.

Rückgängigmachen ist die letzte Linie, nicht die einzige

Das Rückgängigmachen macht Schreibzugriff vertretbar, steht aber hinter weiteren Schutzmaßnahmen:

• Tools gehen über unsere eigene API. Jedes Tool sendet eine gewöhnliche Anfrage an unsere bestehende API, mit derselben Authentifizierung, Validierung, denselben Tarifgrenzen und derselben Projektzuordnung wie jeder andere Client. Es gibt keinen zweiten Weg zu den Daten, also auch keinen zweiten Satz Regeln, bei dem man etwas falsch machen könnte.
• Schreibzugriff ist eine feste Liste. Eine nur lesende Verbindung erreicht eine feste Liste von API-Endpunkten. Schreibzugriff fügt genau die Endpunkte hinzu, die die schreibenden Tools brauchen, und sonst nichts. Tests schlagen fehl, wenn Tools und Listen auseinanderlaufen, in beide Richtungen.
• Die Menschen entscheiden bei der Anmeldung. Welche Projekte die Verbindung sehen darf und ob sie nur lesen oder auch Änderungen vornehmen darf.
• Jeder Aufruf nennt sein Projekt. Der Server führt kein „aktuelles Projekt“, das ein Chat für einen anderen umschalten könnte.
• Die Hinweise sind ehrlich. Anlegen ist nicht zerstörerisch. Ändern, Löschen und Rückgängigmachen sind es, deshalb fragt Claude vorher nach.

Als wir Privatrak im Connector-Verzeichnis von Claude einreichten, machte das Rückgängigmachen noch etwas möglich: einen Testplan, der alle 44 Tools auf einem gemeinsamen Prüfkonto aufruft und damit endet, alles rückgängig zu machen, was er geändert hat.

Wenn Sie das selbst bauen

1. Wählen Sie die Einheit: eine Aufgabe, ein Lauf. Lassen Sie jeden Schreibzugriff einem Lauf angehören, auch wenn der Agent vergisst, einen zu starten.
2. Halten Sie den ganzen Zustand vorher und nachher fest, in derselben Transaktion wie den Schreibzugriff, in einer festen Form gespeichert, damit Sie später vergleichen können.
3. Machen Sie vom Neuesten zum Ältesten rückgängig, in einer Transaktion, und legen Sie gelöschte Dinge mit ihren ursprünglichen IDs neu an.
4. Prüfen Sie jede Änderung auf Konflikte. Überspringen und melden, nie erzwingen und nie den ganzen Lauf aufgeben.
5. Machen Sie die Vorschau zum echten, zurückgerollten Rückgängigmachen.
6. Sagen Sie, was nicht zurückkommt, bevor es verloren ist.
7. Bringen Sie das Rückgängigmachen dorthin, wo die Menschen sind: ins Tool für den Agenten und in die Oberfläche Ihres Produkts für alle anderen.

Der MCP-Server von Privatrak funktioniert mit Claude, Cursor und Codex. Unsere Dokumentation zeigt, wie Sie ihn verbinden.