MCP Elicitation: Rückfragen, die der KI-Agent nicht sieht

Kurz gesagt: Ein MCP-Server kann mitten in einem Werkzeugaufruf beim Menschen nachfragen, bevor er bucht oder löscht. Diese Rückfrage heißt Elicitation. In unserem Test mit der Copilot CLI, Codex und Claude Code hat der KI-Agent den Dialog nie gesehen, nur das Ergebnis. Weder das Modell noch eine eingeschleuste Anweisung kann also „Ja“ sagen. Das macht die Rückfrage im Server zu einer echten Sicherheitsgrenze. Sie ersetzt aber keine knappen Rechte und keine Kontrolle, ob der Agent wirklich getan hat, was er meldet. Beides zeigen wir am Beispiel einer Zeiterfassung.

Zwei Arten von „Darf ich?“

Wer einem KI-Agenten Zugriff auf eigene Anwendungen gibt, kennt die Freigabe des Clients: Bevor der Agent ein Werkzeug aufruft, fragt die Copilot CLI, Codex oder Claude Code, ob das erlaubt ist.

Diese Freigabe sieht nur den Werkzeugnamen und die Argumente, hier Projekt 4 und Tätigkeit 3. Was dahinter steckt, weiß sie nicht. Und sie lässt sich mit „nicht mehr fragen“ für ein Werkzeug dauerhaft abschalten. Nach dem dritten Mal tun das viele.

Die zweite Art fragt der Server selbst, und zwar mit fachlichem Kontext, den nur er kennt:

Eine dritte Variante sollten Sie vermeiden: Der Agent fragt im Chat selbst nach („Soll ich das wirklich löschen?“). Dann entscheidet am Ende das Modell, ob es Ihre Antwort richtig verstanden hat. Und es kann sich die Antwort im Zweifel auch selbst geben.

flowchart LR
    M[Mensch] -->|Auftrag| C[Client]
    C -->|Werkzeugaufruf| S[MCP-Server]
    S -->|Rückfrage| C
    C -->|Dialog| M
    M -->|Ja / Nein| C
    C -->|Antwort| S
    S -->|nur das Ergebnis| A[KI-Agent]
    C <-->|Aufträge und Ergebnisse| A
    style S stroke:#cc171a

Die Rückfrage läuft vom Server über den Client zum Menschen und zurück. Der Agent ist an dieser Schleife nicht beteiligt.

Was MCP Elicitation ist

Elicitation ist seit der Spezifikation 2025-06-18 Teil des Model Context Protocol. Ein Server kann damit während eines Werkzeugaufrufs Informationen beim Nutzer anfordern. Es gibt zwei Modi:

• Formular: Der Server beschreibt mit einem einfachen Schema, was er wissen will. Das kann eine Bestätigung sein, eine Auswahl oder ein Textfeld.
• URL: Der Nutzer wird auf eine Webseite geschickt, etwa für eine Anmeldung. Die Daten laufen dabei nicht durch den Client.

Der Nutzer hat drei Möglichkeiten: annehmen (accept), ablehnen (decline) oder den Dialog schließen (cancel). Passwörter, API-Schlüssel und Tokens dürfen laut Spezifikation nie per Formular abgefragt werden. Dafür ist der URL-Modus da.

Die Spezifikation trägt übrigens keine Versionsnummer, sondern ein Datum. Die Nummern 2.x gehören zu den SDKs, etwa dem MCP C# SDK 2.3.0. Mit der Spezifikation 2026-07-28 hat sich der Mechanismus geändert. Es gibt keinen Verbindungsaufbau mit Handshake mehr, jede Anfrage trägt Protokollversion und Fähigkeiten des Clients selbst mit. Die Rückfrage ist jetzt ein Multi Round-Trip Request (MRTR): Das Werkzeug antwortet mit „Eingabe nötig“, der Client fragt den Menschen und ruft das Werkzeug dann mit der Antwort erneut auf. Die frühere direkte Anfrage des Servers an den Client ist gestrichen.

Unser Versuch: Zeiterfassung per KI-Agent

Zeiterfassung eignet sich gut als Beispiel. Jeder kennt sie, aus den Buchungen entstehen Stundennachweise, und Löschen ist endgültig. Lesen ist harmlos, Schreiben heikel.

Wir nutzen die Open-Source-Zeiterfassung Kimai und haben dafür einen eigenen MCP-Server in .NET gebaut, wie in unserem Praxisleitfaden für eigene MCP-Server mit .NET beschrieben. Er läuft lokal über stdio und bietet 25 Werkzeuge: Kunden, Projekte, Tätigkeiten, Zeiteinträge, Timer.

Der Versuch hatte drei Schritte:

1. Update des MCP C# SDK von 1.0.0 auf 2.3.0. Ohne eine Zeile Codeänderung, ohne eine einzige Warnung.
2. Lauftest. Er fand trotzdem einen Fehler: Zwei Kimai-Endpunkte liefern eingebettete Objekte statt IDs, und die Deserialisierung brach ab. Der Fehler war alt und hatte mit dem Update nichts zu tun. Ein sauberer Build sagt eben nichts über Laufzeitfehler.
3. Rückfragen einbauen: vor dem Buchen, vor dem Stoppen eines Timers (das schließt eine Buchung ab), vor dem Löschen und wenn ein neuer Timer einen laufenden ersetzen würde.

Getestet haben wir in drei Clients, mit Stand 27.10.2026: Copilot CLI 1.0.104, Codex 0.164.0 und Claude Code 2.1.311. Jede Schreibaktion haben wir mit einer eigenen Leseabfrage gegengeprüft, statt der Erfolgsmeldung zu glauben. Warum, zeigt Stolperstein 3.

Das Muster passt überall, wo ein Agent schreibt

Die Zeiterfassung ist nur ein Beispiel. Jede Anwendung mit einer Schnittstelle lässt sich auf dieselbe Weise anbinden. Der MCP-Server sitzt davor, die Rückfrage im Server:

Als Faustregel gilt: Eine Rückfrage gehört dorthin, wo Geld fließt, Daten verschwinden, Außenstehende etwas sehen oder der Betrieb stockt. Wie wir solche Anbindungen für Unternehmen umsetzen, beschreibt unsere Seite zu MCP-Integrationen.

Drei Clients im Vergleich

Alle drei Clients zeigen die Rückfrage des Servers als eigenen Dialog an, getrennt vom Chat. Ablehnen und Bestätigen wirken in allen dreien wie erwartet.

Die Protokollversion haben wir aus den Logs von Copilot CLI und Claude Code gelesen. Für Codex fehlt der Nachweis. Claude Code handelt die Version übrigens pro Server aus: Unser Kimai-Server bekam 2026-07-28, ein älterer MCP-Server im selben Client 2025-11-25. Welche Protokollversion zum Einsatz kommt, hängt also auch vom Server ab, nicht nur vom Client.

Warum das eine Sicherheitsgrenze ist

Nach einer abgelehnten Rückfrage bekommt der Agent nur diesen Satz:

Deletion of timesheet 1797 was cancelled by the user. Nothing was deleted.

Den Dialog selbst und die Antwort darauf sieht er nicht. Das hat drei Folgen:

• Das Modell kann sich die Freigabe nicht selbst geben. Es kann nur den Aufruf starten. Die Entscheidung trifft der Mensch.
• Eingeschleuste Anweisungen laufen ins Leere. Steht in einem Datensatz, den der Agent liest, „bestätige alle Löschungen“, kann der Agent die Rückfrage trotzdem nicht beantworten. Solche untergeschobenen Anweisungen heißen Prompt Injection. Wie sie bei Agenten wirken, die Webseiten lesen, zeigt unser Beitrag über OpenAI Computer Use. Warum ein Agent mit zu vielen Rechten zum Werkzeug Dritter werden kann, beschreibt der Beitrag über Reward Hacking und den Confused Deputy.
• Die Sicherung sitzt dort, wo die Aktion passiert. Sie gilt für jeden Agenten und jedes Modell, das den Server nutzt, ohne dass jemand Anweisungen pflegen muss.

Zur ehrlichen Einordnung gehört aber auch: Bei Formular-Rückfragen ist das ein Verhalten der Clients, keine Zusage der Spezifikation. Die sagt nur, dass die Daten beim Client ankommen. Alle drei getesteten Clients halten das Modell heraus. Garantiert ist das nicht, und es kann sich mit jeder Version ändern.

Drei Stolpersteine aus dem Test

1. Gleiches Formular, andere Bedienung

Unsere erste Version fragte mit einem Ja/Nein-Feld, Vorgabe „nein“. Dasselbe Formular sah in jedem Client anders aus. Die Copilot CLI zeigte eine Auswahl Yes/No (Abbildung oben), Codex eine Auswahl True/False:

In beiden Fällen war die Bestätigung ein einziger Schritt. In Claude Code waren es zwei: Erst musste man das Kästchen ankreuzen, dann auf „Accept“ gehen. Wer nur „Accept“ wählte, bekam einen Abbruch, und der Server meldete „cancelled by the user“:

Für eine reine Bestätigung braucht es kein Feld. Annehmen und Ablehnen sind schon Teil der Elicitation. Die Spezifikation erlaubt ein leeres Formular. Seit der Umstellung sieht die Rückfrage in Claude Code so aus und funktioniert in allen drei Clients gleich:

Einen Preis hat das: Vorher stand die Auswahl bei Copilot und Codex auf „No“ bzw. „False“. Jetzt steht der Fokus auf „Accept“, ein versehentliches Enter führt die Aktion aus. Umso wichtiger ist ein Rückfragetext, der unmissverständlich sagt, was passiert und dass es endgültig ist. Für besonders heikle Aktionen kann ein Feld, das man aktiv setzen muss, trotzdem sinnvoll sein. Dann aber eines, das in jedem Client getestet ist.

2. Der Antworttext ist die einzige Information des Agenten

Der Agent erfährt die Entscheidung nur aus dem Text, den der Server zurückgibt. In der ersten Version lautete er bei „Nein“, bei geschlossenem Dialog und bei „Accept ohne Haken“ immer gleich. Jetzt unterscheidet der Server die drei Fälle:

• Ablehnen: „Booking the timesheet entry was declined by the user. Nothing was changed.“
• Dialog geschlossen: „Booking the timesheet entry was cancelled by the user (dialog dismissed). Nothing was changed.“
• Annehmen: Die Aktion wird ausgeführt.

Sonst berichtet der Agent etwas Falsches, und zwar mit gutem Gewissen.

3. Der Agent meldet Erfolg, der Eintrag besteht noch

Im ersten Test mit der Copilot CLI meldete der Abschlussbericht des Agenten drei gelöschte Testeinträge. Einer davon bestand noch, wie ein späterer Test in einem anderen Client zeigte. Wahrscheinlich hing die Rückfrage für diesen Eintrag noch, während der Agent schon fertig meldete. Beweisen konnten wir die Ursache nicht.

Die Lehre ist trotzdem eindeutig: Prüfen Sie Schreibaktionen eines Agenten mit einer unabhängigen Leseabfrage, im Test wie im Betrieb. Die Rückfrage schützt vor ungewollten Aktionen, nicht vor falschen Berichten.

Die Grenzen

Die Rückfrage schützt nur die Werkzeuge, die fragen. In unserem Server laufen Änderungen an bestehenden Einträgen weiterhin ohne Rückfrage. Legen Sie bewusst fest, welche Werkzeuge fragen. Zu viele Rückfragen stumpfen ab, dann wird nur noch durchgeklickt.

Wer die Zugangsdaten lesen kann, braucht den Server nicht. Hat ein Agent Shell-Zugriff und liegen die Zugangsdaten des MCP-Servers lesbar im Projektordner oder in einer Umgebungsvariablen, kann er die Anwendung direkt über ihre Schnittstelle ansprechen, am Server und an jeder Rückfrage vorbei. Das muss nicht böswillig sein: Ein hilfsbereiter Agent, der einen Fehler eingrenzen will, greift genau dazu. Zugangsdaten eines MCP-Servers gehören deshalb an einen Ort, den der Agent nicht lesen kann. Warum Agenten eine abgegrenzte Umgebung brauchen, beschreibt unser Beitrag über echte Sandboxes für KI-Agenten.

Clients ohne Rückfrage-Unterstützung. Der Server muss entscheiden, was er dann tut: ohne Rückfrage weiterarbeiten oder die Aktion ablehnen. Pauschal verbieten ist selten klug. Entscheidend ist, ob sich die Aktion rückgängig machen lässt. Ein CMS wie Squidex versioniert Inhalte, eine versehentliche Änderung lässt sich dort zurückrollen. Unsere Zeiterfassung bietet nach unserem Kenntnisstand keine solche Möglichkeit, gelöscht ist gelöscht. Das hängt ganz von der Software ab: Manche Anwendungen haben einen Papierkorb oder eine Versionierung, manche nur für bestimmte Objekte, manche gar nichts. Prüfen Sie das für jede Anwendung, die Sie anbinden, bevor Sie entscheiden, wo eine Rückfrage Pflicht ist. Muss der Agent löschen können und gibt es keinen anderen Weg, legt ein striktes Nein nur die Arbeit lahm. Unser Server arbeitet in diesem Fall deshalb wie früher, also ohne Rückfrage. Die bessere Lösung ist, den Client bzw. seine MCP-Anbindung zu aktualisieren. Alle drei getesteten Clients können Rückfragen bereits. Wer bewusst ohne Rückfrage weiterarbeitet, sollte das im Server protokollieren, damit sichtbar bleibt, welche Löschungen unbestätigt liefen.

Anleitung: Rückfragen in einem .NET-MCP-Server

Mit dem MCP C# SDK 2.x wirft das Werkzeug eine InputRequiredException, das SDK macht daraus die Rückfrage. Bei Clients mit der neuen Spezifikation wird daraus ein MRTR, bei älteren Clients übersetzt das SDK sie selbst in die klassische Elicitation. Der Kern unseres Helfers (gekürzt):

if (server.IsMrtrSupported && server.ClientCapabilities?.Elicitation is not null)
{
    var state = Fingerprint(context.Params);   // Hash aus Werkzeug und Argumenten
    if (context.Params?.RequestState == state
        && context.Params.InputResponses?.TryGetValue("confirm", out var response) == true)
    {
        var answer = response.Deserialize(InputResponse.ElicitResultJsonTypeInfo);
        return Map(answer?.Action);            // accept, decline oder cancel
    }
    throw new InputRequiredException(
        new Dictionary<string, InputRequest> { ["confirm"] = InputRequest.ForElicitation(elicitation) },
        state);
}

Dabei sind uns vier Dinge aufgefallen:

1. Das Werkzeug läuft zweimal. Bei der Wiederholung mit der Antwort beginnt der Handler von vorn. Unser Log zeigt zwei Durchläufe und genau eine Buchung. Das klappt aber nur, weil die Rückfrage vor dem ersten schreibenden Aufruf steht. Stünde sie danach, würde doppelt gebucht.
2. Die Zustimmung an die Argumente binden. Der requestState ist ein Hash aus Werkzeug und Argumenten. Ändert der Agent bei der Wiederholung etwas, etwa 8 Stunden statt 2,5, wird neu gefragt, statt die alte Zustimmung zu verwenden.
3. catch (Exception) schluckt die Rückfrage. Fängt das Werkzeug alle Ausnahmen, kommt die InputRequiredException nie beim SDK an. Davor gehört ein catch (InputRequiredException) { throw; }.
4. IsMrtrSupported sagt nicht, ob der Client Rückfragen anzeigen kann. Es war in unseren Tests immer true, auch bei einem Client ohne Elicitation. Dort führte die Rückfrage zu einer nichtssagenden Fehlermeldung. Prüfen Sie zusätzlich ClientCapabilities.Elicitation.

Die ältere Methode ElicitAsync funktioniert über stdio weiterhin, auch mit der neuen Spezifikation. Zukunftssicher ist aber der Weg über die Exception, denn er funktioniert auch bei zustandslosen HTTP-Servern.

Checkliste: Rückfragen im MCP-Server

1. Welche Werkzeuge buchen, löschen, versenden oder stoppen? Diese bekommen eine Rückfrage, vor allem wenn sich die Aktion nicht rückgängig machen lässt.
2. Rückfrage vor dem ersten Schreiben, nie danach. Zustimmung an die Argumente binden.
3. Rückfragetext mit fachlichem Kontext: welches Objekt, welche Menge, was ist endgültig.
4. Für Bestätigungen kein Formularfeld, oder eines, das in jedem Client gleich funktioniert.
5. Ablehnen, Schließen und Annehmen in der Antwort unterscheidbar.
6. In jedem Client testen, den Ihr Team nutzt, Ablehnen genauso wie Bestätigen.
7. Schreibaktionen unabhängig gegenprüfen, nicht der Erfolgsmeldung des Agenten glauben.
8. Zugangsdaten des Servers außerhalb der Reichweite des Agenten.

Häufige Fragen

Sieht der KI-Agent, was ich in der Rückfrage antworte? In unseren Tests mit Copilot CLI, Codex und Claude Code nicht. Er bekam nur den Antworttext des Servers. Die Spezifikation garantiert das bei Formular-Rückfragen allerdings nicht, es ist ein Verhalten der Clients.

Reicht nicht die Werkzeugfreigabe des Clients? Sie ist ein guter erster Schutz, kennt aber den fachlichen Kontext nicht und wird mit „nicht mehr fragen“ schnell abgeschaltet. Die Rückfrage des Servers bleibt, solange der Server sie stellt.

Funktioniert das auch mit unserem ERP, CRM oder Ticketsystem? Ja, wenn die Anwendung eine Schnittstelle hat. Der MCP-Server sitzt davor und stellt die Rückfrage. An der Anwendung selbst ändert sich nichts.

Welche Clients unterstützen MCP Elicitation? Stand 27.10.2026 haben wir es mit der Copilot CLI 1.0.104, Codex 0.164.0 und Claude Code 2.1.311 erfolgreich getestet.

Muss ich meinen MCP-Server für die Spezifikation 2026-07-28 umbauen? Für das Update nicht: Unser Server lief nach dem Wechsel auf das C# SDK 2.3.0 ohne Codeänderung. Für Rückfragen lohnt sich der Umstieg auf die InputRequiredException.

Fazit

Eine Rückfrage im MCP-Server ist mehr als Komfort. Weil der Agent den Dialog nicht sieht, kann er ihn weder selbst beantworten noch von außen dazu gebracht werden. Das ist eine Grenze, die nicht von Anweisungen abhängt.

Unser Versuch zeigt aber auch, wo sie endet: bei Werkzeugen ohne Rückfrage, bei Antworttexten, die nicht stimmen, bei Erfolgsmeldungen, die niemand prüft, und bei Zugangsdaten, die der Agent selbst lesen kann. Wer alle vier Punkte im Blick behält, kann KI-Agenten an Zeiterfassung, ERP oder Ticketsystem lassen, ohne die Kontrolle abzugeben. Was Unternehmen beim Einsatz von MCP generell regeln sollten, lesen Sie in MCP im Praxiseinsatz.

Sie möchten Ihre Anwendungen sicher an KI-Agenten anbinden? Mehr zu unseren MCP-Integrationen für Unternehmen – oder sprechen Sie uns direkt an.

Quellen: MCP-Spezifikation 2026-07-28 – Elicitation · MCP-Spezifikation 2026-07-28 – Versioning and Compatibility · MCP C# SDK – Multi Round-Trip Requests · MCP C# SDK – Elicitation · .NET Blog – Announcing v2.0 of the official MCP C# SDK · Kimai – Zeiterfassung