MCP-Fehleranalyse: Wenn der Tool-Aufruf im Chat scheitert

Bei einem fehlerhaften MCP-Aufruf gilt oft der Prompt als Hauptverdächtiger. Diese Diagnose greift zu kurz: Zwischen der Anfrage im Chat und der sichtbaren Antwort liegen mehrere Übergaben, an denen Daten verändert, abgelehnt oder falsch interpretiert werden können. Wer sofort am Prompt formuliert, repariert häufig an der falschen Stelle.

Eine belastbare MCP-Fehleranalyse verfolgt deshalb genau einen fehlgeschlagenen Aufruf durch die gesamte Kette. Entscheidend ist die erste Übergabe, an der das tatsächliche Verhalten vom erwarteten Verhalten abweicht. Dort liegt der Fehler oder zumindest der erste brauchbare Hinweis darauf.

Warum ein funktionierender MCP-Server noch nichts beweist

Das Model Context Protocol, kurz MCP, ermöglicht einer KI-Anwendung, verfügbare Werkzeuge zu erkennen und über einen MCP-Server aufzurufen. Ein Werkzeug kann beispielsweise einen Auftragsstatus abrufen, einen Datensatz suchen oder einen internen Vorgang anstoßen.

Ein erfolgreicher Verbindungstest bestätigt lediglich, dass Client und Server grundsätzlich miteinander sprechen können. Er beweist nicht, dass das erwartete Tool sichtbar ist, das Modell dieses Tool auswählt, passende Argumente übermittelt oder die aufrufende Identität auf das Zielsystem zugreifen darf.

Für die Fehlersuche solltest du den Ablauf daher in sechs Stationen betrachten:

1. Der Client verbindet sich mit dem MCP-Server.
2. Der Server stellt die verfügbaren Tools und ihre Eingabeschemata bereit.
3. Das Modell entscheidet, ob und welches Tool es aufruft.
4. Der Client übermittelt den Tool-Namen und die Argumente.
5. Der Server validiert und verarbeitet den Aufruf, gegebenenfalls zusammen mit einem nachgelagerten System.
6. Das Tool-Ergebnis fließt zurück und wird vom Modell in eine Antwort übersetzt.

Die sichtbare Chat-Antwort ist nur das Ende dieser Kette. Sie kann falsch sein, obwohl der Tool-Aufruf korrekt war. Umgekehrt kann eine plausibel klingende Antwort einen fehlgeschlagenen oder sogar vollständig ausgebliebenen Aufruf verdecken.

Lege zuerst einen reproduzierbaren Fehlerfall fest

Eine wechselnde Unterhaltung ist keine brauchbare Testgrundlage. Formuliere stattdessen einen einzelnen Fall, den du wiederholt unter möglichst gleichen Bedingungen ausführen kannst. Je kleiner der Fall, desto leichter lässt sich die fehlerhafte Übergabe erkennen.

Für diesen Testfall hältst du mindestens fest:

• die genaue Nutzereingabe,
• das erwartete Tool,
• die erwarteten Argumente,
• das fachlich erwartete Ergebnis,
• die verwendete Benutzer- oder Dienstidentität,
• den betroffenen Mandanten oder Datenbereich, falls vorhanden,
• einen Zeitpunkt, eine Anfragekennung oder eine andere eindeutige Zuordnung.

Eine gute Erwartung lautet nicht lediglich „Der Assistent soll den Auftrag finden“. Sie lautet beispielsweise: „Für die Eingabe mit der Auftragsnummer A-1842 soll das Tool für die Statusabfrage mit dem Argument order_number aufgerufen werden und den hinterlegten Lieferstatus zurückgeben.“ Damit kannst du jede Übergabe gegen ein konkretes Soll prüfen.

Verwende für Tests keine unnötigen personenbezogenen oder vertraulichen Daten. Eine eindeutige, harmlose Testreferenz erleichtert die Suche in Protokollen, ohne nebenbei ein Datenschutzproblem zu erzeugen. Das wäre ein recht teurer Tausch für eine bessere Logzeile.

Finde die erste fehlerhafte Übergabe

Prüfe den Aufruf in seiner tatsächlichen Reihenfolge. Springst du direkt zu den Serverprotokollen, obwohl das Modell gar kein Tool ausgewählt hat, suchst du dort vergeblich.

Das Tool wird nicht angeboten

Kontrolliere zuerst, welche Tools der Client in genau dieser Sitzung kennt. Fehlt das erwartete Tool bereits in der Liste, liegt der Fehler vor der Modellauswahl. Mögliche Ursachen sind eine fehlgeschlagene Verbindung, unpassende Berechtigungen, eine abweichende Serverkonfiguration oder eine Einschränkung der bereitgestellten Tools.

Die Tool-Liste sollte zusammen mit Namen, Beschreibung und Eingabeschema betrachtet werden. Ein bloßer Serverstatus sagt nicht, ob das betreffende Tool tatsächlich für diese Verbindung verfügbar ist.

Das Tool ist sichtbar, wird aber nicht aufgerufen

Ist das Tool vorhanden, aber das Modell antwortet ohne Aufruf oder wählt ein anderes Werkzeug, prüfst du die Tool-Beschreibung und die Abgrenzung zu ähnlichen Tools. Namen wie search, lookup und get_data helfen Menschen und Modellen ungefähr gleich wenig.

Die Beschreibung sollte knapp erklären, für welchen fachlichen Zweck das Tool gedacht ist, welche Eingaben es benötigt und wann ein anderes Tool vorzuziehen ist. Erst wenn diese Angaben eindeutig sind, lohnt sich eine Anpassung der übergeordneten Anweisung oder des Prompts.

Das richtige Tool erhält falsche Argumente

Zeichne den übermittelten Tool-Namen und die exakten Argumente auf. Prüfe anschließend, ob Pflichtfelder fehlen, Werte im falschen Feld landen oder Freitext verwendet wird, obwohl nur bestimmte Werte zulässig sind.

Ein Eingabeschema sollte fachliche Erwartungen ausdrücken, statt jede beliebige Struktur anzunehmen. Erforderliche Felder gehören als solche markiert, begrenzte Werte als feste Auswahl definiert und unbekannte Felder nach Möglichkeit abgelehnt. Eine klare Validierungsfehlermeldung ist hilfreicher als ein erfolgreicher Aufruf mit leerem Ergebnis.

Der Server akzeptiert den Aufruf, liefert aber einen Fehler

Ab diesem Punkt unterscheidest du zwischen einem Fehler im MCP-Server und einem Fehler des nachgelagerten Systems. Der Server kann korrekte Argumente empfangen und dennoch an einer Datenbank, einer internen API oder einer Berechtigungsprüfung scheitern.

Relevant sind hier der interne Verarbeitungsschritt, der Status des Zielsystems und die tatsächlich verwendete Identität. Ein direkter Test mit deinem persönlichen Entwicklerzugang ist kein Gegenbeweis, wenn der Chat eine eingeschränkte Dienstidentität verwendet. Beide Aufrufe sehen fachlich gleich aus, besitzen aber unterschiedliche Rechte.

Das Tool liefert korrekte Daten, die Antwort bleibt falsch

Vergleiche das rohe Tool-Ergebnis mit der endgültigen Chat-Antwort. Sind die benötigten Daten im Ergebnis vorhanden, verschiebt sich die Analyse zur Ergebnisdarstellung und Interpretation.

Problematisch sind unnötig verschachtelte Antworten, mehrdeutige Feldnamen und große Datenpakete, in denen die relevante Information untergeht. Ein Tool für eine Statusabfrage sollte einen klar bezeichneten Status liefern und nicht vorsorglich den halben Auftrag exportieren. Prüfe außerdem, ob das Modell angewiesen ist, fehlende Daten offen zu benennen, statt eine plausible Ergänzung zu formulieren.

Der direkte Tool-Test trennt Serverfehler von Integrationsfehlern

Rufe das betroffene Tool zusätzlich mit einem geeigneten MCP-Testclient direkt auf. Verwende dabei dieselben Argumente und möglichst dieselbe Identität wie im fehlerhaften Chat-Aufruf.

Das Ergebnis schafft eine klare Grenze:

• Der direkte Aufruf scheitert ebenfalls: Untersuche Eingabevalidierung, Serverlogik, Berechtigungen und das angebundene Zielsystem.
• Der direkte Aufruf funktioniert mit denselben Bedingungen: Untersuche Tool-Bereitstellung, Auswahl, Argumenterzeugung und Verarbeitung des Ergebnisses im KI-Client.
• Der direkte Aufruf funktioniert nur mit einer anderen Identität: Der Fehler liegt sehr wahrscheinlich in den Berechtigungen oder im Benutzerkontext.

Wichtig ist der Zusatz „mit denselben Bedingungen“. Ein Test gegen eine andere Umgebung, mit einem Administratorkonto und manuell korrigierten Argumenten belegt lediglich, dass irgendein Aufruf funktioniert. Für den konkreten Supportfall ist das wenig ergiebig.

Ein typischer Fehlerfall: Die Auftragssuche liefert nichts

Angenommen, ein Assistent soll den Status zu Auftrag A-1842 abrufen. Das passende Tool ist sichtbar und wird aufgerufen. Trotzdem behauptet die Antwort, der Auftrag existiere nicht.

Die Prüfung ergibt folgenden Ablauf:

1. Das Modell wählt das richtige Tool zur Auftragssuche.
2. Es übermittelt A-1842 im allgemeinen Feld query.
3. Der Server wertet ausschließlich das Feld order_number aus.
4. Weil dieses Feld fehlt, führt der Server eine leere Suche aus.
5. Das Tool meldet technisch erfolgreich eine leere Ergebnisliste.
6. Das Modell formuliert daraus, dass kein Auftrag gefunden wurde.

Der erste Fehler entsteht bei den Argumenten. Eine Prompt-Ergänzung könnte das Verhalten zufällig verbessern, würde die schwache Schnittstelle aber nicht beseitigen. Die belastbare Korrektur besteht darin, order_number als erforderliches Feld zu definieren, das allgemeine Feld nicht zu akzeptieren und bei fehlender Auftragsnummer einen verständlichen Validierungsfehler zurückzugeben.

Danach braucht es mindestens zwei Prüfungen: Der ursprüngliche Fall muss funktionieren, und ein Aufruf ohne Auftragsnummer muss kontrolliert scheitern. Nur den erfolgreichen Weg zu testen, lässt denselben Fehler unter einer neuen Form zurückkommen.

Welche Korrektur zu welcher Fehlerstelle passt

Die gefundene Übergabe bestimmt die Maßnahme. So vermeidest du Änderungen an mehreren Stellen, nach denen zwar alles wieder läuft, aber niemand erklären kann, warum.

• Verbindung oder Tool-Bereitstellung: Prüfe Erreichbarkeit, Authentifizierung, Freigaben und die tatsächlich angebotene Tool-Liste.
• Falsche Tool-Auswahl: Schärfe Namen und Beschreibungen, trenne überlappende Werkzeuge und entferne unnötige Auswahlmöglichkeiten.
• Falsche Argumente: Präzisiere das Eingabeschema, kennzeichne Pflichtfelder und liefere konkrete Validierungsfehler.
• Fehler bei der Ausführung: Untersuche Serverlogik, Zielsystem, Mandantenkontext und Berechtigungen.
• Falsche Interpretation: Vereinfache das Ergebnisformat, benenne Zustände eindeutig und prüfe die Anweisungen zur Verwendung des Ergebnisses.

Bei schreibenden Tools gehört außerdem die Frage dazu, ob ein wiederholter Aufruf dieselbe Aktion doppelt ausführen kann. Automatische Wiederholungen sind bei reinen Lesezugriffen meist weniger heikel als bei Bestellungen, Freigaben oder Änderungen an Kundendaten. Ein technischer Fehler darf nicht unbemerkt zwei fachliche Vorgänge erzeugen.

Was du für die Übergabe an Entwicklung oder Support dokumentierst

„MCP geht nicht“ beschreibt ein Gefühl, keinen Fehler. Eine brauchbare Übergabe enthält genug Informationen, damit eine andere Person denselben Fall nachvollziehen kann, ohne zunächst den gesamten Chat nach Hinweisen zu durchsuchen.

• exakte Eingabe und erwartetes Ergebnis,
• sichtbare Tool-Liste für die betroffene Sitzung,
• ausgewähltes Tool und übermittelte Argumente,
• Validierungs- oder Serverfehler,
• bereinigtes Ergebnis des nachgelagerten Systems,
• rohes Tool-Ergebnis und sichtbare Chat-Antwort,
• verwendete Identität und betroffener Datenbereich,
• erste nachweisbare Abweichung vom erwarteten Ablauf.

Protokolle müssen dabei bereinigt werden. Zugangsdaten, Sitzungsschlüssel, personenbezogene Inhalte und vollständige interne Datensätze gehören nicht in Tickets oder Chatkanäle. Für die Diagnose reichen häufig Feldnamen, Statusangaben, gekürzte Kennungen und relevante Fehlermeldungen.

Wann der Fehler als behoben gilt

Eine einzelne erfolgreiche Wiederholung ist noch kein ausreichender Abschluss. Prüfe den ursprünglichen Fehlerfall unter denselben Benutzer- und Berechtigungsbedingungen. Ergänze danach einen negativen Fall mit fehlenden oder ungültigen Eingaben und einen benachbarten gültigen Fall.

Bei schreibenden Tools kontrollierst du zusätzlich, ob Wiederholungen oder Verbindungsabbrüche doppelte Aktionen auslösen. Bei lesenden Tools prüfst du, ob „nicht gefunden“, „nicht berechtigt“ und „Zielsystem nicht erreichbar“ als unterschiedliche Zustände erkennbar bleiben. Diese Unterscheidung verhindert, dass der Assistent technische Fehler als fachliche Auskunft verkauft.

Nach der Fehlerbehebung sollte die betroffene Übergabe außerdem in die Freigabeprüfung einfließen. Die Checkliste zur Freigabe eines MCP-Servers im Unternehmen hilft dir dabei, Berechtigungen, Datenzugriffe und betriebliche Grenzen vor dem breiteren Einsatz zu prüfen.

Fazit: Folge dem Aufruf, nicht deinem ersten Verdacht

Wenn ein MCP-Tool im Chat scheitert, ist der Prompt nur eine von mehreren möglichen Ursachen. Verfolge einen reproduzierbaren Fall von der Tool-Bereitstellung über Auswahl, Argumente und Serverausführung bis zur endgültigen Antwort.

Die erste fehlerhafte Übergabe entscheidet über die passende Korrektur. Dadurch bleibt aus einem vagen „Der Assistent findet den Auftrag nicht“ ein klar prüfbarer Fehler: Das Tool fehlt, wurde nicht gewählt, erhielt falsche Daten, durfte nicht zugreifen oder lieferte ein Ergebnis, das anschließend falsch interpretiert wurde. Genau diese Trennung macht MCP-Fehler beherrschbar.