Wenn ein KI-Agent 1.000 MCP-Tools hat: Auswahl, Kontext und Fähigkeiten
Das Verbinden von Agenten mit vielen MCP-Servern führt zu einer Überflutung mit Tools, einem übermäßig großen Kontext und schlechten Auswahlmöglichkeiten. Warum Entdeckungsfunktionen, Fähigkeiten und Gateways wichtiger sein können als reiner Zugriff.
Mehr Tools für einen KI-Agenten klingen nach reinem Vorteil – zumindest, bis die Anzahl 1.000 erreicht. Ab diesem Punkt ändert sich die Fragestellung. Es geht nicht mehr darum, „Kann der Agent das tun?“, sondern darum, „Kann der Agent das richtige Tool finden und es richtig verwenden?“. Genau da wird MCP interessant.
MCP macht die Bereitstellung von Tools einfach
Eine große Stärke des Model Context Protocols besteht darin, dass Funktionen über eine gemeinsame Schnittstelle zu Agenten gelangen. Ein SaaS-Produkt könnte create_customer, get_customer, update_customer, create_invoice, refund_payment und search_orders bereitstellen. Ein anderer MCP-Server könnte GitHub abdecken, ein dritter Slack, ein vierter eine interne Datenbank. Jeder davon funktioniert für sich allein gut. Probleme entstehen, wenn ein Agent mit vielen Servern verbunden ist und die Anzahl schnell steigt. Zehn Tools sind kein Problem, hundert fangen an, Probleme zu verursachen, und tausend stellen eine ganz andere Art von Herausforderung dar.
Die Tool-Explosion
Stellen Sie sich in die Lage des Agenten mit 1.000 Werkzeugen vor. Sie müssten herausfinden, was jedes Werkzeug tut, welche miteinander verbunden sind, welche verwendet werden sollen, welche Parameter jedes Werkzeug benötigt, welche zuerst ausgeführt werden sollten und ob mehrere das gleiche Aufgaben erledigen. Der Agent kann technisch gesehen auf alles zugreifen, doch Zugang bedeutet nicht notwendigerweise Benutzerfreundlichkeit. Mehr Werkzeuge bedeuten mehr Fähigkeiten und auch mehr Auswahlmöglichkeiten – und mehr Auswahlmöglichkeiten können die Entscheidungsfindung erschweren.
Kontext wird ergänzt
Jedes Werkzeug benötigt eine Beschreibung. Für ein Werkzeug könnte das ein Name sein:
create_invoice
und eine kurze Definition:
Creates an invoice for a customer.Parameters:
- customer_id
- amount
- currency
- due_date
Multiplizieren Sie das mit 1.000. Selbst kurze Beschreibungen ergeben zusammen eine große Menge an Kontext, wodurch bereits allein die Angabe dessen, was das Modell tun kann, viele Token verbraucht wird – und die meisten dieser Tools haben nichts mit der zu bewältigenden Aufgabe zu tun. Wenn ein Benutzer nach dem Status einer Bestellung fragt, gibt es keinen Grund dafür, dass der Agent 500 Tools für Abrechnungen, GitHub, CRM und Bereitstellung durchgehen muss.
Die eigentliche Herausforderung besteht darin, das richtige Tool auszuwählen
Nehmen wir an, der Agent sieht Folgendes:
get_customer
get_customer_details
lookup_customer
search_customer
find_customer
Sie klingen alle gleich. Welchen soll es denn aufrufen? Stellen Sie sich das nun mit Hunderten von Tools vor. Das Modell kann die Tools durchaus perfekt aufrufen. Schwierig ist es, aus einem riesigen Werkzeugkasten eines auszuwählen. Es ist, als würde man einem Entwickler 10.000 Funktionen in die Hände drücken und ihm alles Gute wünschen – möglich, aber nicht angenehm.
Mehr Tools, mehr Fehler
Die Auswahl ist oft nicht binär, denn mehrere Tools könnten funktionieren:
search_orders
get_order
list_orders
find_order_by_customer
Ein Agent kann ein gültiges Werkzeug auswählen und es ineffizient nutzen, mehrere Werkzeuge aufrufen, obwohl eines ausreichen würde, oder sie in der falschen Reihenfolge aufrufen. Die gesamte Kette erstreckt sich von der Verfügbarkeit der Werkzeuge über die Auswahl, dann die Sequenzierung bis hin zur Ausführung. MCP hilft hauptsächlich bei der ersten Stufe. Der Rest hängt vom Agenten sowie von der umgebenden Architektur ab.
Sollten Agenten weniger Werkzeuge erhalten?
Nicht unbedingt. Das Ziel ist es nicht, das zu begrenzen, was ein Agent tun kann, sondern zu vermeiden, dass er alles gleichzeitig verstehen muss. Eine Person, die ein Zahlungsproblem behebt, öffnet nicht alle internen Werkzeuge und liest die Dokumentation – sie verwendet nur diejenigen, die mit Zahlungen zu tun haben. Agenten könnten genauso vorgehen. Das Muster des Laden aller Werkzeuge und anschließenden Auswählens könnte durch Entdecken, Auswählen, Laden und Ausführen ersetzt werden, was ein interessanteres Design darstellt.
Wo Skills hineinpassen
Fähigkeiten hängen direkt miteinander zusammen. Eine Fähigkeit kann den Kontext für eine bestimmte Art von Aufgabe liefern. Eine Fähigkeit zur Abrechnung mit Kunden kann beispielsweise dem Agenten mitteilen, den Kunden zu finden, die Mitgliedschaft zu überprüfen, ausstehende Rechnungen anzusehen, die richtige Abrechnungsmaßnahme zu bestimmen, bei Bedarf um Genehmigung zu bitten und anschließend das entsprechende Tool zu verwenden.
Der Agent muss nicht mehr über jedes Tool im System nachdenken. Er erhält eine kleinere, relevantere Auswahl für die Aufgabe. Anstelle dessen:
Agent
↓
1,000 tools
Der Ablauf könnte wie folgt sein:
Agent
↓
Relevant Skill
↓
Relevant tools
↓
MCP
↓
API / System
Fähigkeiten ersetzen MCP nicht, da sie unterschiedliche Probleme adressieren. MCP verbindet den Agenten mit Funktionen, während Fähigkeiten ihm beibringen können, wie er diese nutzen kann. Die Idee, Fähigkeiten anstelle von MCP zu verwenden, ist noch experimentell und in Entwicklung – daher sollte man sie eher als eine entstehende Richtung denn als etablierte Architektur betrachten.
Gateways können ebenfalls wichtig sein
Eine weitere Richtung sind MCP-Gateways. Anstatt einen Agenten direkt mit Dutzenden von MCP-Servern zu verbinden, steht ein Gateway dazwischen:
Agent
↓
MCP Gateway
↓
MCP Servers
↓
APIs / Systems
Ein Gateway könnte potenziell Aufgaben wie Authentifizierung, Routing, Zugriffskontrolle, Überwachbarkeit, Erkennung von Tools sowie die Verwaltung vieler Server übernehmen. Je größer die MCP-Einsatzumgebungen werden, desto wertvoller wird das.
Das eigentliche Problem ist die Irrelevanz
Es geht nicht um 1.000 Tools an sich, sondern um 1.000 irrelevante Tools. Wenn eine Aufgabe tatsächlich tausend Tools erfordert, dann sei es so. Wenn jedoch nur zwölf benötigt werden und der Agent tausend Tools verarbeiten muss, um sie zu finden, handelt es sich um unnötige Komplexität. Das Prinzip lautet: Agenten benötigen keinen Zugriff auf alles, nur auf das, was im Moment wichtig ist.
Das wird voraussichtlich zu einer zentralen Herausforderung in der MCP-Architektur, da Agenten immer mehr Systeme anbinden. MCP hat die erste Frage gelöst – nämlich wie Agenten standardisierten Zugang zu Tools erhalten. Die nächste Frage ist, wie all diese Tools intelligent verwaltet werden können, und das erscheint deutlich schwieriger. Es wurde einfach, Agenten Tools zur Verfügung zu stellen. Die eigentliche Herausforderung besteht darin, ihnen zur richtigen Zeit die richtigen Tools zu geben.