Kapitel 8: Die Tool-Falle – Probleme bei zu vielen Werkzeugen

In den vorangegangenen Kapiteln haben wir gelernt, wie einfach es ist, MCP-Server und Tools zu erstellen. Doch Vorsicht: Mehr ist nicht immer besser. In diesem Kapitel besprechen wir das Phänomen der "Tool-Fatigue" bei LLMs und wie man damit umgeht.

Das Problem: Wenn das Modell den Wald vor lauter Bäumen nicht sieht

Stell dir vor, du verbindest 20 MCP-Server mit jeweils 50 Tools. Das LLM hat nun 1.000 Werkzeuge zur Auswahl. Dies führt zu drei kritischen Problemen:

Context Window Inflation: Jede Tool-Definition (Name, Beschreibung, Parameter) verbraucht Token. Bei 1.000 Tools ist ein großer Teil des Gedächtnisses (Context Window) des Modells bereits belegt, bevor der Benutzer überhaupt die erste Frage gestellt hat.
Modell-Konfusion (Halluzinationen): Je mehr Tools mit ähnlichen Namen oder Beschreibungen existieren, desto eher wählt das Modell das falsche Werkzeug aus. Es beginnt zu "raten" oder vermischt Parameter.
Latenz: Das Modell benötigt mehr Zeit, um die riesige Liste der Tools zu verarbeiten, bevor es mit der Generierung beginnt. Die Antwortzeiten steigen spürbar.

Strategien zur Lösung

Wie gehen wir mit dieser Komplexität um? Es gibt drei bewährte Ansätze im MCP-Ökosystem:

1. Relevanz-Filterung (Client-seitig)

Ein intelligenter MCP-Client injiziert nicht alle Tools auf einmal. Stattdessen nutzt er ein kleineres, schnelles Modell (oder eine Vektor-Suche), um basierend auf der User-Anfrage nur die 5-10 relevantesten Tools auszuwählen und an das Haupt-LLM weiterzugeben.

2. Hierarchische Tools (Routing)

Anstatt 100 spezialisierte Tools anzubieten, bietet der Server ein einziges "Router-Tool" an.

Schlecht: get_sales_2023, get_sales_2024, get_sales_prognosis...
Gut: Ein Tool query_data(category, year), das intern auf dem Server entscheidet, welche Logik aufgerufen wird.

3. Klare Abgrenzung durch Prompts

Wie in Kapitel 6 gelernt, können Prompts dem Modell helfen, sich zu fokussieren. Ein Prompt kann dem Modell sagen: "Du bist heute nur für die Buchhaltung zuständig. Ignoriere alle Tools, die nichts mit Finanzen zu tun haben."

4. Slash-Commands & Gezielte Tool-Auswahl

Ein sehr effektives Muster in modernen Chat-Clients ist die Kombination von Benutzer-Interaktion und technischer Filterung.

Anstatt dass das LLM aus einer riesigen Liste das richtige Werkzeug erraten muss, gibt der Benutzer durch einen Slash-Command (z. B. /execute_js) die Richtung vor. Dies ermöglicht einen hochoptimierten Flow:

Präzise Identifikation: Sobald der User /execute_js tippt, weiß der Client exakt, welches Tool im nächsten Schritt benötigt wird.
Context-Anreicherung via prompts/get: Der Client ruft vom Server den passenden Prompt für dieses Tool ab. Dieser enthält oft spezifische System-Anweisungen oder Hilfestellungen.
Reduzierter Fokus: Der Client sendet an das LLM nur noch:
- Eine kleine Liste von Standard-Tools (baseTools).
- Das vom User gewählte Tool als forcedTool (das Modell wird angewiesen, genau dieses Tool zu nutzen).
- Den Text aus dem Prompt-Abruf als zusätzliche Instruktion.

Vorteil: Die Token-Last sinkt drastisch, die Latenz wird minimiert und die Wahrscheinlichkeit, dass das Modell ein falsches Tool wählt, geht gegen Null.

5. Agent Skills & Progressive Disclosure (Neu)

Ein moderner Ansatz, der vor allem in fortgeschrittenen Agent-Systemen (wie dem Gemini CLI oder Claude) zum Einsatz kommt, ist das Muster der Agent Skills.

Hierbei werden Experten-Anleitungen und spezialisierte Tools nicht direkt in den System-Prompt geladen. Stattdessen nutzt man ein zweistufiges Verfahren:

Discovery: Im System-Prompt stehen nur Name und Kurzbeschreibung der verfügbaren Skills (niedrige Token-Last).
Activation: Wenn das Modell merkt, dass es einen Skill benötigt, nutzt es ein Tool, um die vollständige SKILL.md nachzuladen.

Dieser Ansatz der Progressive Disclosure (schrittweise Offenlegung) hält den Kontext sauber und fokussiert das Modell erst dann auf Details, wenn sie wirklich relevant sind. (Details siehe Kapitel 23).

Testing der Tool-Überlastung mit `mcp-tester`

Mit unserem Tool kannst du genau prüfen, wie dein Server reagiert, wenn er unter Last steht oder sehr viele Definitionen liefert.

Tool-Discovery Benchmarking

Prüfe, wie lange der Handshake dauert, wenn dein Server viele Tools zurückgibt:

time ./bin/mcp-tester list --profile heavy-server

Ambiguitäts-Test

Erstelle ein Test-Skript, das versucht, das Modell zu verwirren. Bietet dein Server zwei sehr ähnliche Tools an? Teste mit dem mcp-tester, ob das Modell (oder dein Skript-Ablauf) zuverlässig das richtige Tool trifft.

Caching Problem bei dynamischen Tools

Viele MCP-Server bieten dynamische Tools an, die sich je nach Kontext ändern können. Dies kann zu Problemen führen, wenn der Client die Tools zwischenspeichert. Insebsondere haben Provider unterschiedliche Ansätze, wie sie mit dynamischen Tools umgehen. Und wie sie effektive Caching implementieren. Das problem (Chat) . Dort sendet man im grunde den kompletten Chatverlauf mit. Solange sich die Tools nicht ändern ist das kein Problem. Aber wenn sich die Tools ändern, dann muss man den Chatverlauf anpassen - dies führt aber u.U. dazu, dass ein evtl. vorhandener Cache nicht wiederverwendet werden kann.

Die Kunst besteht darin, die Tools so zu gestalten, dass sie sich nicht so oft ändern. Und dass man den Chatverlauf so gestalten kann, dass man den Cache wiederverwenden kann. Optimierte Chat Workflows achten daher z.Bsp. darauf dass sich die Tools nicht so oft ändern. Und dass man den Chatverlauf so gestalten kann, dass man den Cache wiederverwenden kann.

Es gibt auch "proprietäre" Ansätze, um dieses Problem zu umgehen. Z.B. kann man den Chatverlauf so gestalten, dass man den Cache wiederverwenden kann (z.bsp. Cache hints).

Fazit

Ein guter MCP-Server zeichnet sich nicht durch die Anzahl der Tools aus, sondern durch deren Qualität und Eindeutigkeit. Jedes Tool sollte einen klaren, einzigartigen Zweck erfüllen. Wenn du merkst, dass dein Modell Fehler macht, ist es oft an der Zeit, die Tool-Liste zu entschlacken oder die Beschreibungen präziser zu formulieren.

← Inhaltsverzeichnis | Nächstes Kapitel: Rückgabewerte →