Dein MCP-Server Hat ein Geheimes Scoring-Problem

Dein MCP-Server funktioniert perfekt in Demos. Du weißt es, weil du die Demo gebaut hast. Du hast den Prompt handverlesen, das Tool hat gefeuert, das Ergebnis kam sauber zurück. Alle nickten. Ausliefern.

Dann kommt Produktion.

In Produktion wählt das LLM 30% der Zeit das falsche Tool. Benutzer melden seltsame Ergebnisse. Der Agent ruft search auf, wenn er fetch rufen sollte. Er übergibt einen Datumsstring, wo er einen Epoch-Timestamp braucht. Er ignoriert dein leistungsfähigstes Tool komplett, weil er nicht herausfinden kann, wann er es nutzen soll.

Was hat sich geändert? Nichts in deinem Code. Die Handler sind in Ordnung. Die Logik ist in Ordnung. Das Problem war immer da — du hast es nur nie bemerkt, weil Demos gescriptet sind und Produktion nicht. In einer Demo kontrollierst du die Eingabe. In Produktion muss das LLM herausfinden, welches deiner fünfzehn Tools zu einer mehrdeutigen Benutzeranfrage passt. Und es scheitert an diesem Schritt weit öfter als du denkst.

Das ist das geheime Scoring-Problem. Dein Server hat keinen Bug. Er hat eine Qualitätslücke, die nur auftaucht, wenn ein Sprachmodell echte Entscheidungen über deine Tools treffen muss.

Etwas, das die meisten MCP-Entwickler nicht verinnerlichen: Das LLM liest nie deinen Code. Es sieht nie deine Handler-Logik, deine Validierungsregeln, deine sorgfältige Fehlerbehandlung. Alles, was es sieht, ist ein Name, eine Beschreibung und ein Schema.

Das ist alles. Das ist die gesamte Schnittstelle zwischen deinem Tool und der Intelligenz, die entscheidet, ob sie es benutzt.

Wenn zwei Tools ähnliche Beschreibungen haben, rät das LLM. Es fragt nicht nach Klärung. Es markiert keine Mehrdeutigkeit. Es wählt eines und geht weiter. Wenn deine Beschreibung "Dokumente suchen" sagt und ein anderes Tool "Dokumente finden" sagt, wirft das LLM im Grunde eine Münze.

Wenn eine Beschreibung vage ist, halluziniert das LLM die Absicht. Es füllt die Lücken mit Annahmen. "Benutzereinstellungen verwalten" könnte Einstellungen lesen, schreiben, löschen oder exportieren bedeuten. Das LLM wird eine Bedeutung annehmen und sich festlegen, ohne es jemandem zu sagen.

Tool-Auswahl ist ein Sprachproblem, kein Code-Problem. Der Ingenieursinstinkt ist, den Handler zu debuggen. Die eigentliche Lösung liegt fast immer im Text — den zwanzig Worten, die beschreiben, was dein Tool tut und wann man es benutzt. Die meisten Teams schauen nie dorthin, weil sie zu beschäftigt sind, Stack Traces zu lesen.

Ein Qualitäts-Score ist nicht eine einzelne Zahl. Wäre er das, wäre er nutzlos — wie einem Restaurant eine einzige Bewertung zu geben, ohne Essen von Service von Ambiente zu unterscheiden.

Ein echter Qualitäts-Score umfasst sechs Dimensionen, jede unabhängig messbar, jede allein fähig, die Zuverlässigkeit deines Tools zu ruinieren.

Beschreibungsklarheit: Erklärt die Beschreibung, was das Tool tut, wann man es benutzt und wann nicht? Spezifiziert sie das Antwortformat? Ein Score von 40 bedeutet "das LLM wird dieses Tool regelmäßig falsch benutzen." Ein Score von 90 bedeutet "das LLM wählt dieses Tool fast immer korrekt."

Schema-Vollständigkeit: Sind Parameter präzise typisiert? Sind Pflichtfelder wirklich pflicht? Werden Enums verwendet, wo Werte eingeschränkt sind?

Namenskonsistenz: Folgen deine Tools einem vorhersagbaren Muster? Wenn du create_user und delete_user hast, aber dann fetch_all_documents, erzeugt die Inkonsistenz kognitive Mehrbelastung für das Modell.

Überlappungserkennung: Wie viele deiner Tools könnten plausibel zur selben Benutzeranfrage passen? Hohe Überlappung ist der beste Einzelprädiktor für falsche Tool-Auswahl.

Fehlerdokumentation: Beschreibt das Tool, was passiert, wenn etwas schiefgeht?

Beispielabdeckung: Gibt es Nutzungsbeispiele in der Beschreibung? Beispiele sind mehr wert als Absätze voller Erklärungen, weil sie das Verständnis des LLMs in konkreten Mustern verankern.

Machen wir es konkret. So sieht ein Score von 40 versus 90 über jede Dimension aus.

Beschreibungsklarheit bei 40: "Durchsucht die Datenbank." Bei 90: "Volltextsuche über alle indexierten Dokumente. Gibt die Top 10 Ergebnisse nach Relevanz sortiert zurück. Verwenden, wenn der Benutzer Dokumente nach Inhalt finden will. Nicht verwenden für Suche nach exakter ID — stattdessen get_document verwenden."

Schema-Vollständigkeit bei 40: Ein einzelner Parameter "query" als String typisiert, keine Einschränkungen. Bei 90: "query" als nicht-leerer String mit Maximallänge 500, plus optionales "limit" als Integer mit Min 1 Max 100, plus optionales "date_range" mit ISO-8601-Daten.

Benennung bei 40: search, getDoc, user_remove, ListAllItems. Bei 90: search_documents, get_document, remove_user, list_items. Das Muster ist verb_nomen, durchgehend.

Überlappung bei 40: search_documents, find_documents und query_documents existieren alle und tun leicht verschiedene Dinge. Bei 90: Jedes Tool hat einen klaren, nicht überlappenden Zweck.

Der Unterschied ist immer Spezifität. Vage Tools scheitern. Präzise Tools funktionieren. Und die Lücke zwischen 40 und 90 ist meist keine Neuentwicklung — es ist ein Nachmittag sorgfältiger Bearbeitung.

Die meisten Teams debuggen die falsche Schicht. Sie sehen Tool-Auswahlfehler und stürzen sich sofort auf Code. Sie schreiben Handler um, damit sie toleranter sind. Sie fügen Retry-Logik hinzu. Sie wechseln zu einem teureren Modell. Sie bauen aufwendige Routing-Schichten über MCP, um Mehrdeutigkeit darunter zu kompensieren.

All das ist teuer, langsam und behandelt das Symptom statt der Ursache.

Die eigentliche Lösung ist meist eine 20-Wort-Änderung an einer Tool-Beschreibung. Ändere "verwaltet Dokumente" zu "erstellt ein neues Dokument aus dem angegebenen Titel und Body. Gibt die Dokument-ID zurück. Nur zum Erstellen neuer Dokumente verwenden — zum Aktualisieren bestehender Dokumente update_document verwenden."

Diese Änderung hat dreißig Sekunden gedauert. Sie eliminiert eine ganze Kategorie von Auswahlfehlern. Kein Code geändert. Kein Modell-Upgrade nötig.

Quality Scoring sagt dir genau, welche 20 Worte du ändern musst. Es zeigt auf die spezifische Dimension, die versagt, beim spezifischen Tool, das Probleme verursacht, mit einem konkreten Vorschlag, was stattdessen geschrieben werden soll. Es verwandelt ein vages "die KI verwirrt sich ständig" in ein präzises "die Beschreibung deines search_documents erwähnt nicht das Antwortformat, und 34% der Fehler gehen darauf zurück, dass das LLM Ergebnisse falsch interpretiert."

Deshalb zählt Messung. Nicht weil der Score an sich wertvoll ist, sondern weil er ein unsichtbares Problem in ein sichtbares, behebbares verwandelt. Die Teams, die das verstehen, hören auf, Handler umzuschreiben, und fangen an, Beschreibungen umzuschreiben. Sie liefern Fixes in Minuten statt Tagen. Und ihre Tools funktionieren einfach — nicht weil der Code besser ist, sondern weil die Sprache es ist.