Warum sind Tool Routing und Intent Lock beim MCP-Server-Design wichtig?

Das Model Context Protocol (MCP) ermöglicht es einem Sprachmodell, Tools in externen Systemen über eine standardisierte Schnittstelle aufzurufen. In der Praxis ist nicht das Protokoll selbst, sondern das serverseitige Tool-Design entscheidend: Tool-Namen, Parameter-Schemata und Fehlermeldungen formen das Verhalten des Modells direkt.

Beim Testen eines Multi-Domain-MCP-Servers tritt ein typisches Problem auf: Während ein Benutzer in einer Domain sucht, ruft das Modell aufgrund von Namens- oder Parameterähnlichkeiten ein Tool aus einer anderen Domain auf. Dies wird als Intent Drift bezeichnet. Beispielsweise könnte die Anfrage eines Benutzers, der nach einer Fernbusverbindung sucht, an ein Tool zur Fahrzeugzuweisung weitergeleitet werden, da die Parametersätze ähnlich sind. Dies liegt weniger an einem Fehler des Modells als an der Unklarheit des Schnittstellendesigns.

Was ist Intent Lock? Dabei wird die aktive Domain der Sitzung serverseitig gespeichert und bei jedem Tool-Aufruf eine Übereinstimmung mit dieser Domain geprüft. Wenn ein Benutzer sich in der Bus-Domain befindet, wird ein Aufruf an das Mietwagen-Tool abgelehnt und dem Modell ein klarer Fehler zurückgegeben: Domain stimmt nicht überein, rufen Sie zuerst das Tool zum Domain-Wechsel auf. Dadurch wird ein Absichtswechsel zu einem expliziten statt einem impliziten Schritt.

Die zweite Verteidigungslinie ist das Schema. Das Hinzufügen einer obligatorischen Domain-Information zu jedem Anfrage- und Antwortobjekt stellt sicher, dass das Modell bei jedem Aufruf erneut deklariert, in welchem Kontext es arbeitet. Wenn die Deklaration mit dem Sitzungsstatus in Konflikt steht, stoppt der Server den Vorgang. Dies verlagert die Validierung auf den Server, anstatt sich auf eine clientseitige Regel zu verlassen.

Der dritte Punkt ist die Namensdisziplin. Die Verwendung von Namen mit Domain-Präfixen wie `bus_search`, `flight_search`, `car_rental_search` anstelle von allgemeinen Namen wie `suche_starten`, `suchen`, `abfragen` vergrößert den Abstand zwischen ähnlichen Tools. Auch die Beschreibungstexte müssen ebenso klar sein; zu schreiben, was ein Tool nicht tut, ist genauso wertvoll wie zu schreiben, was es tut.

Datums- und Zeitfelder sind eine separate Fehlerquelle. Ein Tool, das Freitext-Datumsangaben akzeptiert, führt dazu, dass das Modell lokalisierte Formate generiert. Die Erzwingung von ISO-8601 und die explizite Anforderung der Zeitzone vereinfachen sowohl die Validierung als auch die Fehlermeldungen. Ebenso reduziert die Angabe von Einheiten in numerischen Feldern (Anzahl der Personen, Anzahl der Nächte, Währung) die Unklarheit.

Sicherheitsseitig sind OTP oder ähnliche Verifizierungsflüsse ein korrekter Ansatz für Tools, die Transaktionen initiieren. Die Verifizierung muss jedoch auf Transaktionsebene und nicht auf Tool-Ebene verbindlich sein: Ohne eine verifizierte Sitzungs-ID sollten keine Buchungs-, Zahlungs- oder Stornierungsaufrufe akzeptiert werden. Die Autorisierung auf Basis des vom Modell generierten Textes ist eine vom Protokoll unabhängige Sicherheitslücke.

Fehlermeldungen sind die Lernoberfläche des Modells. Anstelle einer allgemeinen 400-Antwort erhöht die Rückgabe strukturierter Fehler, die angeben, welches Feld fehlt und welches Format erwartet wird, die Wahrscheinlichkeit, dass das Modell beim nächsten Versuch den richtigen Aufruf generiert, erheblich. Ebenso sollten Ratenbegrenzungen und Wiederholungsrichtlinien dokumentiert werden; das Modell kann nur aus dem Fehlertext erkennen, dass es warten muss.

Kurze Checkliste für sicheres Tool Routing: domainbasierte Tool-Benennung, Intent Lock auf Sitzungsebene, obligatorische Domain-Information im Schema, serverseitige Validierung, explizites Tool zum Domain-Wechsel, ISO-8601-Datumsformat, Autorisierungskontrolle auf Transaktionsebene, strukturierte Fehlermeldungen, Dokumentation von Limits und Wiederholungsversuchen.

Der gemeinsame Punkt dieser Elemente ist, falsches Verhalten serverseitig unmöglich zu machen, anstatt zu hoffen, dass sich das Modell korrekt verhält. Beim Entwurf eines MCP-Servers lautet die Frage: Welcher ist der plausibelste falsche Aufruf, den das Modell generieren könnte, und auf welcher Ebene stoppt das System ihn?