MCP-Clients: Wann fragt die KI, bevor sie Daten ändert? 2026

2026-09-29

Jeder MCP-Client, der 2026 eine Rolle spielt, fragt nach, bevor ein Assistent ein Werkzeug ausführt, das etwas ändert. Dieser Teil der Antwort ist langweilig und beruhigend. Der nützliche Teil ist, was nach der ersten Rückfrage passiert, denn niemand klickt auf Dauer vierzigmal am Tag auf „Allow“: Jeder Client bietet einen Weg, nicht mehr gefragt zu werden, und wie eng dieser Weg ist, unterscheidet sich zwischen den Clients deutlich.

Kurz gesagt: Claude Code, Zed, Cursor und Devin Desktop lassen Sie einzelne MCP-Werkzeuge per Namen vorab freigeben. Codex, die Engine hinter der ChatGPT-Desktop-App, kann stattdessen anhand der Kennzeichnungen des Servers selbst entscheiden — und bei allem fragen, was nicht als Read-only markiert ist. VS Code macht beides auf Dialogebene und ergänzt Schalter für den ganzen Workspace. Keiner dieser Ansätze ist falsch, aber sie versagen auf unterschiedliche Weise, und welches Versagen Sie kümmern sollte, hängt davon ab, wer den Server geschrieben hat.

Dieser Vergleich ergänzt unsere Übersicht, welche MCP-Clients einen lokalen Server starten können. Jene beantwortet „startet er überhaupt“, diese beantwortet „was passiert, wenn der Assistent beschließt, etwas zu ändern“. Alles Folgende wurde am 29. September 2026 mit der Dokumentation des jeweiligen Anbieters abgeglichen.

Die Kurzfassung

Zwei Spalten tragen den Großteil der Aussage. „Feinste dauerhafte Freigabe“ sagt Ihnen, ob Sie search vertrauen können, ohne share zu vertrauen. „Entscheidet anhand von Annotationen“ sagt Ihnen, ob der Client diese Trennung für Sie vornimmt — anhand von Kennzeichnungen, die der Server über sich selbst geschrieben hat.

Codex und die ChatGPT-Desktop-App: vier Modi und eine Kennzeichnung

Codex hat den explizitesten Ansatz, und weil die ChatGPT-Desktop-App, Codex CLI und die IDE-Erweiterung sich eine Konfigurationsdatei teilen, gilt er für alle drei. Jeder MCP-Server erhält einen default_tools_approval_mode, und jedes Werkzeug kann ihn mit tools.<tool>.approval_mode überschreiben. Dokumentiert sind die Werte auto, prompt, writes und approve.

Spannend ist writes. In den Worten von OpenAI „fragt er bei Werkzeugen nach, die nicht als Read-only markiert sind“. Suchen läuft still, alles andere hält an und fragt, und ein Werkzeug ganz ohne Annotation gilt als Schreibzugriff — der sichere Standard, wenn ein Server nichts über sich sagt. Zusätzlich zu den Modi hält die Codex-Dokumentation zu Freigaben fest, dass destruktive MCP-Werkzeugaufrufe immer eine Freigabe erfordern, wenn das Werkzeug eine destruktive Annotation angibt, es sei denn, es gibt zugleich eine Lese-Annotation an.

Eine Änderung, die Sie bei einer älteren Konfiguration kennen sollten: Codex unterstützt approval_policy = "untrusted" nicht mehr, und die abgeschaffte Einstellung kann den Start des Clients verhindern. Vertrauen für ein Projekt wird jetzt stattdessen über dessen trust_level gesetzt.

ChatGPT im Web folgt demselben Prinzip. Im Entwicklermodus, verfügbar für Konten mit Pro, Plus, Business, Enterprise und Education, „erfordern Schreibaktionen standardmäßig eine Bestätigung“; ChatGPT beachtet readOnlyHint und behandelt jedes Werkzeug ohne diesen Hinweis als Schreibaktion. Eine Entscheidung lässt sich pro Werkzeug für den Rest einer Unterhaltung merken, länger nicht.

Claude Code und Claude Desktop: Regeln, die Sie per Namen schreiben

Claude Code liest keine Annotationen, um zu entscheiden. Es nutzt Berechtigungsregeln in drei Listen — allow, ask und deny —, die in fester Reihenfolge ausgewertet werden: erst deny, dann ask, dann allow. MCP-Werkzeuge heißen mcp__<server>__<tool>, also gibt mcp__notes__search ein Werkzeug frei, mcp__notes__get_* eine ganze Familie, und mcp__notes oder mcp__notes__* deckt den ganzen Server ab. Der Standardmodus heißt jetzt Manual; zu den lockereren Modi gehören acceptEdits, auto, bei dem ein Klassifikator die Aktionen statt Ihnen prüft, und bypassPermissions.

Zwei Details neigen sich zur Sicherheit. Server aus einer im Projekt eingecheckten .mcp.json brauchen Ihre Freigabe, bevor sie sich überhaupt verbinden. Und ein Server-Autor kann ein Werkzeug mit _meta["anthropic/requiresUserInteraction"] kennzeichnen; dann zeigt Claude Code bei jedem Aufruf seine Rückfrage — selbst in acceptEdits, auto und bypassPermissions.

Die Connector-Einstellungen von Claude Desktop unter Customize → Connectors gruppieren die Werkzeuge eines Servers in Kategorien wie Read-only und Write/Delete, und jede Kategorie oder jedes einzelne Werkzeug lässt sich auf Always allow, Needs approval oder Blocked stellen.

Cursor, VS Code, Zed und Devin Desktop: die Editoren

Cursor sagt es klar: „Cursor bittet standardmäßig um Freigabe, bevor MCP-Werkzeuge verwendet werden.“ MCP folgt denselben Run Modes wie Terminalbefehle. In Auto-review laufen Aufrufe aus der Allowlist sofort, alles andere geht durch ein Klassifikator-Modell; Run Everything führt jeden Werkzeugaufruf ohne Rückfrage aus. Die Allowlist nimmt Einträge server:tool mit Wildcards. Eine Falle: Bleibt die Werkzeugliste eines Servers in der Allowlist leer, sind alle Werkzeuge dieses Servers erlaubt.

VS Code nennt seine Standardstufe Manual permissions: Alles, was nicht automatisch freigegeben ist, braucht eine Bestätigung. Im Dialog können Sie eine einzelne Nutzung freigeben oder die Freigabe für die Sitzung, den Workspace oder alle künftigen Aufrufe erteilen, und Freigaben pro Werkzeug lassen sich für jeden MCP-Server festlegen. Allow all entfernt die Rückfragen ganz, und Assisted permissions, bei dem ein Modell jeden Aufruf beurteilt, ist als experimentell gekennzeichnet. Eine Ausnahme verdient Aufmerksamkeit: MCP-Server, die in einem Agent-Plugin stecken, „gelten mit der Installation des Plugins implizit als vertrauenswürdig“ und überspringen die separate Vertrauensabfrage beim Start. Die Installation des Plugins ist die Vertrauensentscheidung.

Zed hat das am besten lesbare Regelsystem. agent.tool_permissions.default steht auf confirm, solange Sie es nicht ändern, mit allow und deny als Alternativen. Regeln benennen MCP-Werkzeuge als mcp:<server>:<tool_name> und können immer erlauben, immer bestätigen lassen oder immer verbieten, wobei deny Vorrang hat. Die Rückfrage selbst bietet „Allow once“, „Deny once“ und „Always for“ für das Werkzeug an; bei MCP-Werkzeugen gibt es nur die Option auf Werkzeugebene.

Devin Desktop, das frühere Windsurf, hat mit dem Namen auch das Modell gewechselt. Sein Agent Devin Local „ersetzt die Stufen der automatischen Ausführung durch ein feiner abgestuftes Berechtigungssystem“ und fragt standardmäßig vor dem Aufruf jedes MCP-Werkzeugs. Aus der Rückfrage heraus können Sie ein Werkzeug oder alle Werkzeuge dieses Servers erlauben, für die Sitzung oder dauerhaft, und Deny-Regeln stechen alles andere. Admins in Enterprise können bestimmte Server oder Werkzeuge für die ganze Organisation vorab freigeben.

Was Annotationen können und was nicht

Die MCP-Spezifikation gibt Servern ein Vokabular, um ihre Werkzeuge zu beschreiben: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Sie sagt Clients auch, wie weit sie dem glauben sollen: Clients „MÜSSEN Werkzeug-Annotationen als nicht vertrauenswürdig betrachten, sofern sie nicht von vertrauenswürdigen Servern stammen“. Und sie verlangt einen Menschen in der Schleife, der jeden Werkzeugaufruf ablehnen kann.

Das rückt die beiden Ansätze oben ins rechte Licht. Ein Client, der anhand von Annotationen entscheidet, wie der Modus writes von Codex, ist bequem bei einem Server, dem Sie vertrauen: Sie konfigurieren eine Zeile, und zu jedem neuen schreibenden Werkzeug, das der Server hinzufügt, wird automatisch nachgefragt. Bei einem Server, dem Sie nicht vertrauen, ist er genau so sicher wie die Ehrlichkeit des Servers. Ein Werkzeug, das Daten ändert und sich Read-only nennt, läuft ohne Rückfrage.

Ein Client, bei dem Sie Werkzeuge benennen müssen, wie Claude Code oder Zed, versagt andersherum. Ihm ist egal, was der Server behauptet, aber ein neues schreibendes Werkzeug aus einem Update ist nur abgedeckt, wenn Ihre Regel breit genug war, um es zu erfassen — oder eng genug, um es zu verfehlen, sodass wieder gefragt wird. Namensbasierte Regeln schreibt man am sichersten als „erlaube diese Lesezugriffe“, nicht als „erlaube diesen Server“.

Eine vernünftige Einrichtung für einen Server, der liest und schreibt

Unabhängig vom Client decken dieselben vier Gewohnheiten den Großteil des Risikos ab:

1. Lesezugriffe per Namen erlauben, nicht den ganzen Server. Suchen und Transkripte lesen tut ein Assistent den ganzen Tag; dort kostet eine Rückfrage am meisten und schützt am wenigsten.
2. Eine Rückfrage auf allem lassen, was teilt oder ersetzt. Veröffentlichen für andere und Überschreiben von Text sind die zwei Arten von Änderungen, die Sie nicht rückgängig machen, indem Sie einen Wert zurücksetzen.
3. Sich nur bei vertrauenswürdigen Servern auf Annotationen verlassen. Bei einem Server aus einer Registry, den Sie nie benutzt haben, benennen Sie seine Werkzeuge stattdessen in Regeln.
4. Einem weniger vertrauenswürdigen Client eine Read-only-Instanz geben. Unterstützt der Server einen Read-only-Modus, lässt sich ein Client aufs Lesen beschränken, während ein anderer vollen Zugriff behält.

Warnsignale: ein Allowlist-Eintrag in Cursor für einen Server mit leerer Werkzeugliste, ein VS-Code-Plugin, das niemand im Team geprüft hat, und „Always allow“, geklickt bei einem Werkzeug, dessen Namen Sie nicht gelesen haben.

So sieht das in Speak-Y aus

Der MCP-Server von Speak-Y ist für beide Arten von Clients geschrieben. Lesende Werkzeuge — Aufnahmen durchsuchen, Transkripte, Zusammenfassungen und Aufgaben lesen, Tags und Kanäle auflisten — tragen readOnlyHint und lesen die Bibliothek direkt von Ihrem Rechner. Werkzeuge, die etwas ändern — Tags, Titel, Sprechernamen, Neutranskription, Teilen in einen Team-Kanal — sind als datenändernd deklariert und laufen über die gestartete Speak-Y-App, wo jeder Aufruf protokolliert wird und wo sie sich abschalten lassen.

Zwei davon sind absichtlich mit destructiveHint gekennzeichnet: retranscribe, weil es den aktuellen Text einer Aufnahme samt manueller Korrekturen ersetzt, und share_to_channel, weil Kollegen eine Aufnahme lesen können, bevor Sie sie zurücknehmen. Im Modus writes von Codex kommen diese Rückfragen ohne jede Konfiguration; in Claude Code oder Zed erlauben Sie die lesenden Werkzeuge per Namen und lassen den Rest auf ask.

Wenn ein Client nur lesen können soll, starten Sie den Server in dessen Konfiguration mit --read-only: Die ändernden Werkzeuge werden ihm gar nicht erst angeboten, es gibt also nichts, was sich versehentlich freigeben ließe. Die Einrichtung ist ein Klick unter Einstellungen → Integrationen, und der MCP-Server ist in jedem Tarif kostenlos, auch in Free.

Die Freigabe-Rückfrage ist nur eine der Kontrollen, die einen schreibenden Assistenten sicher nutzbar machen. Die anderen — welche Änderungen umkehrbar sind und was das Protokoll festhält — behandelt was Schreibzugriff über MCP sicher macht, und die MCP-Dokumentation enthält die Einrichtung pro Client.

FAQ

Fragen MCP-Clients nach, bevor sie ein Werkzeug ausführen, das Daten ändert?

Jeder große Client fragt standardmäßig. Claude Code, Cursor, VS Code, Zed und Devin Desktop zeigen vor jedem MCP-Werkzeug eine Rückfrage, bis Sie es vorab freigeben, und der Entwicklermodus von ChatGPT verlangt eine Bestätigung für jedes Werkzeug, das nicht als Read-only markiert ist. Der Unterschied liegt darin, wie eng Sie danach vorab freigeben können: pro Werkzeug, pro Server, pro Sitzung oder dauerhaft. Geprüft am 29. September 2026.

Welche MCP-Clients entscheiden anhand der Annotation readOnlyHint, wann sie fragen?

Codex und ChatGPT tun das ausdrücklich. Der Freigabemodus writes von Codex fragt bei Werkzeugen nach, die nicht als Read-only markiert sind, und fragt immer vor einem Werkzeug, das sich selbst als destruktiv ausweist; der Entwicklermodus von ChatGPT behandelt jedes Werkzeug ohne readOnlyHint als Schreibaktion. Claude Code, Cursor, VS Code und Zed dokumentieren Annotationen nicht als Grundlage der Freigabe; die Regeln schreiben Sie selbst, nach Werkzeugnamen.

Kann ich lesende Werkzeuge automatisch freigeben und trotzdem vor Schreibzugriffen gefragt werden?

Ja, in jedem Client dieses Vergleichs, aber der Mechanismus unterscheidet sich. In Claude Code, Zed, Cursor und Devin Desktop geben Sie die lesenden Werkzeuge per Namen frei, etwa mcp__server__search in Claude Code oder mcp:server:search in Zed. In Codex erledigt der Modus writes das in einer Zeile und verlässt sich darauf, dass der Server seine lesenden Werkzeuge ehrlich kennzeichnet.

Sind Werkzeug-Annotationen wie readOnlyHint eine Sicherheitsgarantie?

Nein. Die MCP-Spezifikation schreibt vor, dass Clients Werkzeug-Annotationen als nicht vertrauenswürdig behandeln müssen, sofern sie nicht von vertrauenswürdigen Servern stammen. Ein Server, der ein schreibendes Werkzeug als Read-only markiert, hebelt jede Client-Richtlinie aus, die auf diesem Hinweis beruht. Behandeln Sie Annotationen als Komfort für Server, denen Sie bereits vertrauen, und nennen Sie bei allen anderen die Werkzeuge in den Regeln ausdrücklich.

Wie verbindet man einen Server für Meeting-Notizen am sichersten mit einem KI-Assistenten?

Geben Sie nur die lesenden Werkzeuge vorab frei, lassen Sie eine Rückfrage auf allem, was Daten ändert, und geben Sie Clients, denen Sie weniger vertrauen, eine Read-only-Instanz. Bei Speak-Y entfernt ein Start des Servers mit --read-only in der Konfiguration eines Clients die ändernden Werkzeuge komplett aus diesem Client, während ein anderer Client mit eigenen Rückfragen vollen Zugriff behält.