Semantic Tool Discovery -- Vektorbasierte Werkzeugauswahl fuer MCP-Agenten
Sarat Mudunuri, Jian Wan, Ally Qin und Srinivasan Manoharan adressieren ein wachsendes Skalierungsproblem bei LLM-Agenten: Wenn Agenten ueber das Model Context Protocol (MCP) auf Dutzende bis Hunderte von Tools zugreifen, explodiert der Token-Verbrauch und die Entscheidungsqualitaet sinkt. Die Autoren schlagen eine Architektur vor, die per Dense-Embedding-Retrieval dynamisch nur die semantisch relevantesten Tools auswaehlt -- mit dramatischen Effizienzgewinnen.
Kernaussagen
Das Grundproblem ist quantifizierbar: Ein LLM-Agent, der alle verfuegbaren Tools im Kontext mitfuehrt, verbraucht pro Anfrage Tausende Tokens allein fuer Tool-Beschreibungen. Bei Unternehmenseinsaetzen mit vielen MCP-Servern summiert sich das auf geschaetzte 1,5 Millionen Dollar monatliche API-Kosten. Gleichzeitig leidet die Genauigkeit, weil das Modell zwischen zu vielen Optionen waehlen muss.
Die Loesung: Tool-Beschreibungen werden als Dense Vectors (text-embedding-ada-002, 1536 Dimensionen) in einer Vektordatenbank (Milvus) indexiert. Bei einer Nutzeranfrage generiert das System einen Query-Vektor, fuehrt eine Aehnlichkeitssuche durch und liefert nur die Top-K-Kandidaten an das LLM. Schema-Informationen wie Name, Beschreibung und Parameter fliessen dabei als strukturiertes Textdokument in die Embedding-Berechnung ein.
Die Evaluation ueber 140 Queries gegen 121 Tools aus fuenf MCP-Servern (GitHub, Slack, MySQL, Filesystem, Time/Weather) zeigt: Bei K=3 erreicht das System eine Hit-Rate von 97,1%, einen MRR von 0,91 und eine F1 von 58,4% -- bei gleichzeitiger Token-Reduktion von 99,6%. Die Retrieval-Latenz liegt unter 91 Millisekunden.
Ein aufschlussreiches Detail: Die Leistung variiert je nach semantischer Trennschaerfe der Tool-Beschreibungen. GitHub- und MySQL-Tools mit klar abgegrenzten Funktionen erreichen bereits bei K=1 ueber 90% Praezision. Filesystem-Tools mit ueberlappenden Beschreibungen (read, write, copy, move) schneiden schlechter ab und benoetigen hoehere K-Werte.
Methodik
Die Architektur besteht aus vier Komponenten. Die Tool-Indexing-Pipeline entdeckt Tools ueber MCP-Server, extrahiert Schemas und erzeugt strukturierte Textdokumente im Format "Tool: {name} Purpose: {description} Capabilities: {details} Parameters: {params}". Diese werden als Vektoren in Milvus gespeichert.
Die Query-Verarbeitung generiert Dense Vectors fuer Nutzeranfragen, fuehrt Dot-Product-Aehnlichkeitssuchen durch und filtert optional ueber Schwellenwerte. Die selektierten Tools werden LLM-spezifisch formatiert und in den Kontext injiziert. Eine optionale Feedback-Schleife sammelt Invocation-Daten und Task-Erfolgsraten, um Retrieval-Parameter iterativ zu verfeinern.
Die Evaluation deckt fuenf MCP-Server mit unterschiedlichen Domaincharakteristiken ab. Gemessen werden Precision@K, Recall@K, F1@K, Hit-Rate, MRR, Token-Reduktionsrate und End-to-End-Latenz fuer K-Werte von 1 bis 10. Als LLM dient GPT-4o.
Zu den dokumentierten Schwaechen gehoeren ambigue Queries ("Help me with my project"), die ohne Kontext keine sinnvolle Tool-Zuordnung erlauben, sowie Cross-Domain-Anfragen, die Tools aus mehreren Servern benoetigen und manchmal nicht alle relevanten Domains im Top-K abdecken.
Relevanz fuer die Praxis
MCP-Skalierung ist ein reales Problem. Mit ueber 10.000 aktiven MCP-Servern und 97 Millionen monatlichen SDK-Downloads Anfang 2026 wird die Frage, wie Agenten effizient mit grossen Tool-Katalogen umgehen, immer dringlicher. Naive Ansaetze, die alle Tools im Kontext mitschicken, skalieren nicht.
K=3 als pragmatische Daumenregel. Die Ergebnisse legen nahe, dass drei Tools pro Anfrage den besten Kompromiss aus Treffsicherheit und Effizienz bieten. Darueber hinaus sind die Zugewinne marginal. Das ist eine nuetzliche Heuristik fuer eigene Implementierungen.
Qualitaet der Tool-Beschreibungen entscheidet. Der staerkste Praediktor fuer Retrieval-Qualitaet ist die semantische Trennschaerfe der Tool-Beschreibungen. Teams, die MCP-Server entwickeln, sollten in praezise, unterscheidbare Beschreibungen investieren -- das zahlt sich direkt in besserer Tool-Auswahl aus.
Erweiterbar auf Multi-Agent-Routing. Die Autoren skizzieren, wie der Ansatz auf hierarchisches Agent-Tool-Routing erweitert werden kann: Zuerst den richtigen Agenten finden, dann innerhalb dessen Tool-Katalog die passenden Tools. Das ist besonders fuer Unternehmensszenarien mit verteilten Zustaendigkeiten relevant.