MCP-Fehleranalyse: Falsche Tool-Antworten eingrenzen

Nach einer falschen Antwort gilt oft das Sprachmodell als Schuldiger. Diese Diagnose ist bequem, aber häufig zu grob: Bei einem Aufruf über das Model Context Protocol (MCP) können Tool-Auswahl, Eingabeparameter, Benutzerkontext, Backend-Abfrage, Rückgabeformat oder abschließende Interpretation fehlerhaft sein. Solange du diese Stationen nicht getrennt prüfst, behandelst du eher Vermutungen als Ursachen.

Die zentrale Regel für die MCP-Fehleranalyse lautet deshalb: Sichere den vollständigen Ablauf und prüfe jede Grenze einzeln. Entscheidend ist nicht, an welcher Stelle der Fehler sichtbar wird, sondern an welcher Stelle erstmals falsche oder unvollständige Daten auftauchen.

Eine falsche Antwort besteht aus mehreren möglichen Fehlern

Betrachte eine beispielhafte interne Anfrage: Eine Person fragt, welche Rechnung eines bestimmten Kunden noch offen ist. Der Assistent ruft ein MCP-Tool zur Rechnungssuche auf und nennt anschließend eine bereits bezahlte Rechnung.

Das sichtbare Ergebnis ist eindeutig falsch. Die Ursache bleibt zunächst offen. Denkbar sind unter anderem folgende Abläufe:

• Die Anwendung hat ein unpassendes Tool ausgewählt.
• Der Kundenname wurde dem falschen Datensatz zugeordnet.
• Der Parameter für den Rechnungsstatus fehlte oder hatte einen falschen Wert.
• Der MCP-Server hat mit dem falschen Mandanten- oder Benutzerkontext gearbeitet.
• Das angebundene System hat veraltete oder widersprüchliche Daten geliefert.
• Die Tool-Antwort war korrekt, wurde aber auf dem Weg zum Modell gekürzt oder verändert.
• Das Modell hat ein Feld wie Fälligkeitsdatum, Zahlungsdatum oder Status falsch interpretiert.

Diese Ursachen erfordern unterschiedliche Korrekturen. Ein ausführlicherer Prompt repariert keine falsche Datenbankabfrage. Zusätzliche Wiederholungen helfen ebenfalls wenig, wenn derselbe Aufruf jedes Mal denselben fachlich falschen Datensatz liefert.

Die Rohantwort ist der wichtigste Trennpunkt

Beginne mit der Rohantwort des Tools, bevor du Prompts, Tool-Beschreibungen oder Modelle änderst. Sie trennt zwei große Fehlerbereiche voneinander.

Enthält die Rohantwort bereits falsche Daten, liegt die Ursache vor oder innerhalb des MCP-Servers. Dann prüfst du Parameter, Berechtigungen, Kontext, Geschäftslogik und das angebundene System.

Enthält die Rohantwort die richtigen Daten, entsteht der Fehler danach. Dann kommen eine Umwandlung durch den MCP-Client, abgeschnittene Inhalte, ein missverständliches Rückgabeformat oder die Interpretation durch das Modell infrage.

Wichtig ist die tatsächlich übertragene Antwort. Eine korrekte Datenbankzeile oder eine richtige Antwort des Drittsystems genügt nicht, wenn der MCP-Server daraus ein mehrdeutiges oder unvollständiges Ergebnis baut.

So sicherst du eine belastbare Ablaufspur

Für die Analyse brauchst du eine zusammenhängende Ablaufspur, häufig auch Trace genannt. Sie verbindet alle Stationen eines einzelnen Vorgangs über eine gemeinsame Vorgangskennung. Sichere mindestens:

1. Die ursprüngliche Anfrage: Halte die konkrete Nutzerfrage und den dafür relevanten Gesprächskontext fest.
2. Die verfügbaren Tools: Dokumentiere, welche Tools die aufrufende Anwendung in diesem Moment verwenden konnte und welche Beschreibungen sie erhalten hat.
3. Das ausgewählte Tool: Erfasse den exakten Tool-Namen. Ähnlich benannte Werkzeuge können zu falschen Zuordnungen führen.
4. Die übergebenen Argumente: Speichere die tatsächlich gesendeten Werte nach der Validierung, nicht nur die vom Nutzer formulierte Anfrage.
5. Den Ausführungskontext: Dazu gehören Mandant, Benutzerrolle, Berechtigungen und andere fachlich relevante Einschränkungen.
6. Die unveränderte Tool-Antwort: Sichere Status, strukturierte Nutzdaten und Fehlermeldungen, bevor ein Client sie zusammenfasst oder umformt.
7. Die sichtbare Endantwort: Nur so kannst du feststellen, welche Behauptung später hinzugefügt, ausgelassen oder falsch abgeleitet wurde.

Vollständig bedeutet dabei nicht, wahllos sämtliche Inhalte zu protokollieren. Zugangsdaten, Tokens und unnötige personenbezogene Daten gehören nicht in Diagnoseprotokolle. Du brauchst eine durchgängige fachliche Spur, keine heimliche Zweitkopie des gesamten Systems.

Reproduziere den Tool-Aufruf ohne das Modell

Sobald Tool-Name und Argumente bekannt sind, wiederholst du den Aufruf möglichst ohne freie Modellauswahl. Damit beantwortest du eine konkrete Frage: Liefert das Tool bei identischer Eingabe und identischem Kontext erneut das falsche Ergebnis?

Bleibt das Ergebnis falsch, kannst du Modell und Formulierung der Nutzerfrage vorerst aus der Untersuchung nehmen. Prüfe nun den MCP-Server und dessen Abhängigkeiten. Liefert der direkte Aufruf dagegen ein korrektes Ergebnis, vergleichst du beide Abläufe. Oft unterscheidet sich mindestens ein zunächst unscheinbarer Faktor:

• eine andere Kunden- oder Vorgangs-ID,
• ein fehlender Filter,
• ein abweichender Benutzer oder Mandant,
• eine andere Sprache oder Zeitzone,
• ein nicht identischer Datenstand,
• eine Umwandlung der Antwort durch den Client.

Bei schreibenden oder löschenden Tools solltest du die Reproduktion nicht unkontrolliert im Produktivsystem durchführen. Nutze eine sichere Testumgebung, einen Lesemodus oder eine Vorschaufunktion, sofern der Ablauf das erlaubt. Fehleranalyse ist kein überzeugender Grund, denselben falschen Auftrag zweimal auszuführen.

Fünf Fehlerklassen führen schneller zur Ursache

Wenn die Ablaufspur vorliegt, ordnest du den Vorfall einer Fehlerklasse zu. Diese Einteilung verhindert, dass mehrere Ebenen gleichzeitig verändert werden.

Das falsche Tool wurde ausgewählt

Prüfe, ob sich Namen und Beschreibungen mehrerer Tools fachlich überschneiden. Ein Werkzeug zum Suchen offener Rechnungen und ein allgemeines Werkzeug zur Kundensuche können für das Modell ähnlich wirken, obwohl ihre Ergebnisse unterschiedlich zu behandeln sind.

Die Korrektur gehört in die Tool-Abgrenzung: eindeutiger Name, klare Beschreibung, konkrete Einsatzgrenzen und keine unnötig ähnlichen Werkzeuge im selben Kontext. Ein größerer allgemeiner Systemprompt verdeckt die Unschärfe häufig nur.

Das richtige Tool erhielt falsche Argumente

Vergleiche die gesendeten Argumente mit der Nutzerabsicht. Freitextwerte wie Kundennamen sind riskanter als stabile interne IDs. Prüfe außerdem Standardwerte, optionale Filter und stillschweigende Umwandlungen. Ein fehlender Statusfilter kann formal gültig sein und trotzdem zu einem fachlich falschen Ergebnis führen.

Verbessere an dieser Grenze das Eingabeschema. Pflichtfelder sollten tatsächlich erforderlich sein. Begrenzte Werte gehören in klar definierte Auswahlmöglichkeiten. Mehrdeutige Angaben sollten eine Rückfrage auslösen, statt unbemerkt geraten zu werden.

Der Server verarbeitet korrekte Argumente falsch

Wenn das Tool mit richtigen Parametern bereits falsche Rohdaten liefert, verfolgst du die Verarbeitung im Server weiter. Prüfe die erzeugte Abfrage, verwendete Identifikatoren, Mandantentrennung, Berechtigungsfilter und fachliche Regeln.

Besondere Aufmerksamkeit verdienen Standardwerte, die erst serverseitig ergänzt werden. Ein Tool kann beispielsweise korrekt nach einem Kunden fragen, während der Server ohne expliziten Standort automatisch den zuletzt verwendeten Standort einsetzt. Der Aufruf bleibt technisch erfolgreich und ist dennoch fachlich unzuverlässig.

Die Rückgabe ist korrekt, aber missverständlich

Eine formal gültige Antwort kann dem Modell mehrere plausible Deutungen anbieten. Freie Beschreibungstexte, uneinheitliche Feldnamen oder fehlende Einheiten erhöhen dieses Risiko. Ein Feld namens date verrät beispielsweise nicht, ob es Rechnungsdatum, Fälligkeit oder Zahlungseingang bezeichnet.

Gib fachlich relevante Werte strukturiert und eindeutig zurück. Stabile IDs, klar benannte Datumsfelder, explizite Statuswerte und getrennte Beträge sind leichter zu prüfen als ein langer Textblock. Die Antwort sollte außerdem erkennen lassen, wenn kein eindeutiger Treffer vorliegt.

Das Modell leitet eine falsche Aussage ab

Sind übertragene Tool-Antwort und fachliche Bedeutung eindeutig korrekt, bleibt die abschließende Verarbeitung. Vergleiche jede konkrete Behauptung der Endantwort mit den gelieferten Feldern. Prüfe auch, ob der Client die Rohantwort vollständig an das Modell weitergegeben hat.

Die Korrektur kann dann in einer klareren Rückgabestruktur oder engeren Anweisung liegen. Für sensible Auskünfte sollte die Anwendung vorgeben, dass nur vorhandene Felder verwendet und Unsicherheiten ausdrücklich benannt werden. Eine solche Vorgabe ersetzt jedoch keine serverseitige Validierung.

Ändere während der Diagnose nur eine Grenze

Bei einem schwer greifbaren Vorfall ist die Versuchung groß, Prompt, Tool-Beschreibung, Schema und Serverlogik gleichzeitig anzupassen. Danach funktioniert das Beispiel vielleicht wieder, aber du weißt weder warum noch ob ein neuer Fehler entstanden ist.

Arbeite stattdessen mit kontrollierten Vergleichen:

1. Sichere einen fehlerhaften Ablauf als Referenz.
2. Formuliere eine konkrete Vermutung über die erste fehlerhafte Grenze.
3. Ändere ausschließlich diese Stelle.
4. Wiederhole denselben Aufruf mit gleichem Kontext.
5. Vergleiche Tool-Auswahl, Argumente, Rohantwort und Endantwort.
6. Behalte die Änderung nur, wenn sie die vermutete Ursache nachvollziehbar beseitigt.

Bei sporadischen Fehlern brauchst du mehrere Ablaufspuren. Vergleiche erfolgreiche und fehlerhafte Aufrufe anhand derselben Merkmale. So werden versteckte Unterschiede wie Benutzerkontext, zeitabhängige Daten, Antwortgröße oder parallele Änderungen sichtbar.

Prüfe nach der Korrektur den fachlichen Vertrag

Ein reparierter Einzelfall ist noch kein belastbarer Nachweis. Lege für das betroffene Tool einige feste Prüffälle an: den ursprünglichen Fehler, einen eindeutigen Standardfall, eine leere Trefferliste und einen mehrdeutigen Fall. Bei schreibenden Tools kommen abgelehnte und unvollständige Eingaben hinzu.

Prüfe dabei nicht nur den Wortlaut der Modellantwort. Relevant sind stabile fachliche Eigenschaften:

• Wurde das vorgesehene Tool ausgewählt?
• Sind die Pflichtargumente korrekt und vollständig?
• Passt der Benutzer- und Mandantenkontext?
• Enthält die Rohantwort die erwarteten Datensätze?
• Lassen sich alle Tatsachen der Endantwort auf konkrete Rückgabefelder zurückführen?
• Wird Unsicherheit erkennbar, wenn die Daten keine eindeutige Antwort erlauben?

Damit wird aus einem Supportfall ein prüfbarer Vertrag zwischen Anwendung, MCP-Server und angebundenem System. Dieser Vertrag ist nützlicher als die Hoffnung, dass eine leicht umformulierte Frage künftig zufällig besser funktioniert.

Fazit: Suche die erste falsche Information

Eine falsche Antwort nach einem MCP-Aufruf beweist weder einen Modellfehler noch einen defekten Server. Die Ursache liegt an der ersten Stelle, an der der Ablauf von der fachlichen Erwartung abweicht.

Sichere deshalb Anfrage, Tool-Auswahl, Argumente, Kontext, Rohantwort und Endantwort unter einer gemeinsamen Vorgangskennung. Reproduziere den Tool-Aufruf ohne freie Modellauswahl und ändere anschließend nur die betroffene Grenze. So wird aus einer diffusen Halluzinationsvermutung ein konkreter Fehler, den du testen und gezielt beheben kannst.