126 MCP-Tools entwickelt: Keine optimale Lösung für Agenten

Dies ist eine 10-teilige Serie, die aufzeigt, wie Apidog Apidog CLI entwickelt hat, ein Befehlszeilentool für API-Tests und API-Lebenszyklusmanagement. Lesen Sie der Reihe nach oder springen Sie zu einem beliebigen Beitrag, der Sie interessiert:

Als MCP zum Branchen-Hotspot wurde, bauten wir einen kompletten MCP-Server mit 126 generierten Tools. Hier ist, was schiefging – und warum mehr Tools nicht gleichbedeutend mit einer besseren Agenten-Aktivierung sind.

Der MCP-Hype

Anfang 2025 wurde MCP (Model Context Protocol) zu einem Branchen-Hotspot.

Anthropic bewarb das Protokoll. Cursor, Claude Code, Antigravity, verschiedene Agent IDEs und zahlreiche SaaS-Produkte folgten schnell. Das Protokoll versprach eine standardisierte Methode für KI-Agenten, sich mit externen Tools und Datenquellen zu verbinden.

In dieser Zeit wurde fast jedes Produkt mit einer API dieselbe Frage gestellt:

"Haben Sie MCP?"

Für Apidog schien diese Wahl besonders naheliegend.

Warum MCP die Antwort zu sein schien

Apidog selbst hatte eine umfassende Reihe von API-Entwicklungsfunktionen angesammelt:

• API-Dokumentation
• Schema-Definitionen
• Mock-Server
• Testfälle
• Testszenarien
• Testsuiten
• Testberichte
• Import-/Export-Workflows
• Zusammenarbeit in Branches
• Und vieles mehr

Wenn Agenten der neue Software-Einstiegspunkt werden sollten – eine neue Art, wie Benutzer mit Produkten interagieren –, dann schien die Bereitstellung dieser Funktionen über MCP eine notwendige Voraussetzung zu sein.

Wir glaubten, dass Agenten, wenn wir unsere Fähigkeiten als MCP-Tools verpacken könnten, in der Lage wären,:

• API-Dokumentation abzufragen
• Testfälle zu erstellen
• Testszenarien auszuführen
• Projektdaten zu importieren/exportieren
• Umgebungen und Variablen zu verwalten
• In Branches zusammenzuarbeiten

Die Logik war einfach: mehr exponierte Funktionen = bessere Agenten-Aktivierung.

Was wir tatsächlich gebaut haben

Das haben wir nicht auf die leichte Schulter genommen.

Apidog MCP war keine einfache Demo mit einer Handvoll handgeschriebener Endpunkte. Es war ein kompletter MCP-Server:

Sitzungssystem

Der MCP-Client initialisiert zunächst eine Sitzung. Der Server generiert eine sessionId und speichert den Sitzungsstatus über Redis. Nachfolgende Anfragen greifen weiterhin mit der sessionId zu.

Mit anderen Worten, es war kein einmaliger HTTP-Aufruf, sondern ein Sitzungssystem auf Protokollebene.

Tool-Kategorien

Auch die Tool-Schicht wurde nicht mit wenigen festen Endpunkten handgeschrieben. Wir haben die Tools von Apidog in mehrere Kategorien unterteilt:

Die letzte Kategorie: 126 generierte Tools.

Jedes generierte Tool hatte:

• Einen eindeutigen Identifikator
• Einen spezifischen API-Pfad
• Eine HTTP-Methode (GET, POST, PUT, DELETE, etc.)
• Ein vollständiges Eingabe-Schema mit Feld-Beschreibungen, Typen und Enum-Werten
• Eine definierte Rückgabestruktur

Progressive Offenlegung

Um den Tool-Expositionsdruck zu reduzieren, haben wir auch eine dynamische Erkennungsebene gebaut:

Der Agent konnte:

1. Zuerst nach verfügbaren Endpunkt-Tools suchen (listOpenApiEndpoints)
2. Dann die OpenAPI-Details eines spezifischen Tools abrufen (getOpenApiDetails)
3. Schließlich den eigentlichen HTTP-Aufruf per Tool-ID ausführen (executeOpenApi)

Dies war unser Versuch der progressiven Offenlegung. Wir haben nicht einfach alle zugrundeliegenden Endpunkte direkt und explizit offengelegt. Wir hofften, dass Agenten zuerst suchen, dann Details abrufen und schließlich ausführen würden.

Die Wand zufälliger Tools

Doch bei der Bearbeitung realer Aufgaben traten schnell Probleme auf.

Betrachten Sie eine einfache Benutzeranfrage:

"Helfen Sie mir, einen Test für diesen Endpunkt hinzuzufügen und die Verifizierung auszuführen."

Aus Implementierungssicht ist dies eine vernünftige Anfrage. Apidog verfügt über die Fähigkeiten, um:

• Endpunkte zu finden
• Testfälle zu erstellen
• Testszenarien auszuführen
• Berichte zu generieren

Doch aus der Perspektive des Agenten löst diese einfache Anfrage tatsächlich eine Reihe fortlaufender Beurteilungen aus:

Der Agent muss nicht nur das richtige Tool finden. Er muss zuerst das Problem "welches Tool soll verwendet werden" lösen, bevor er überhaupt mit der Lösung des Benutzerproblems beginnen kann.

Aus Implementierungssicht können all diese Probleme durch Tools gelöst werden. Aus der Agenten-Erfahrungsperspektive bilden sie eine Wand zufälliger Tools.

Die vier strukturellen Probleme

Durch praktische Tests und internes Feedback haben wir vier strukturelle Probleme des MCP-Ansatzes identifiziert.

Problem 1: Die Kosten der Tool-Erkennung steigen schnell

Apidog ist kein Produkt, das sich mit nur einem Dutzend Endpunkten beschreiben lässt.

Wenn die Tools von einem Dutzend auf Dutzende oder Hunderte anwachsen, muss der Agent das Problem "welches Tool zu verwenden ist" lösen, bevor er mit der Lösung von Benutzerproblemen beginnen kann.

Wir haben versucht, Workflows in die Tool-description (das Feld, das zur Offenlegung von Tools gegenüber KI-Agenten verwendet wird) zu schreiben. Zum Beispiel würde eine Tool-Beschreibung explizit besagen:

"Bevor Sie Endpunkt-Daten abfragen, müssen Sie zuerst das Projekt über ein anderes Tool bestätigen, dann Projektmetadaten über ein drittes Tool abrufen und schließlich das aktuelle Tool aufrufen."

Diese Methode funktioniert bei kleinen Tool-Sets. Doch in einer massiven Tool-Wand konkurriert die description selbst um die Aufmerksamkeit des Modells.

Je mehr Anleitungen wir in die Beschreibungen schrieben, desto mehr Tokens wurden verbraucht – und desto unwahrscheinlicher war es, dass der Agent sie tatsächlich lesen und befolgen würde.

Problem 2: Geschäftsschema dringt in den Kontext ein

Jedes MCP-Tool ist nicht nur ein Tool-Name.

Hinter jedem Tool stehen:

• description (was das Tool tut)
• input schema (Parameter, Typen, erforderlich/optional)
• Feld-Erklärungen (verschachtelte Strukturen, Einschränkungen)
• Enum-Werte (erlaubte Optionen)
• Rückgabestrukturen (Antwortformat, Fehlerbehandlung)

Lassen Sie uns eine konservative Schätzung vornehmen:

Die Frage eines Benutzers mag nur 50 Zeichen lang sein. Aber das Modell ist gezwungen, zuerst 50.000 Tokens an Tool-Beschreibungen einzuführen – nur für einen MCP-Server.

Dies ist nicht theoretisch. Branchen-Daten bestätigen dies.

Der offizielle Cursor-Blogbeitrag "Dynamic Context Discovery" lieferte wertvolle Referenzdaten: Durch die Umwandlung von MCP-Tool-Beschreibungen, Terminal-Sitzungen und langen Konversationen in bei Bedarf ladbaren Kontext wurde der Token-Verbrauch zur Laufzeit um 46,9% reduziert.

Traes Ansatz war direkter: Begrenzung der MCP-Tool-Anzahl und der Länge einzelner Tool-Beschreibungen:

• Oberer Grenzwert für Tool-Anzahl: 40
• Grenzwert für einzelne Tool-Beschreibung: 8000 Zeichen

Tatsächlich berichteten viele Teams während früher interner Tests, dass Apidog MCP Probleme mit einigen Tools hatte, die in Trae nicht aufgerufen werden konnten. Der Agent war aufgrund des begrenzten Modellkontextes gezwungen, Kompromisse einzugehen, und externe Tools wurden als erste "gekürzt".

Diese Lösungen weisen alle auf dieselbe Tatsache hin:

Tool-Beschreibungen können nicht unendlich in den Modellkontext eingegeben werden.

Problem 3: Protokollsitzungen machen Ausführungsketten schwerfälliger

Der Apidog MCP-Server muss Folgendes handhaben:

Für einen einfachen Tool-Aufruf sind diese Kosten akzeptabel. Für Agentenaufgaben mit großen Anrufzahlen und häufiger Exploration erhöhen diese Anforderungen an das Zustandsmanagement die Komplexität auf Server- und Clientseite.

Bei der Implementierung von Apidog MCP verbrauchte das Team erhebliche Energie für die Fehlersuche und Anpassung an verschiedene Agenten-Clients (Cursor, Claude Code, Antigravity, Trae usw.). Dennoch blieben Protokoll-Kompatibilitätsprobleme bestehen, und das offizielle MCP-Protokoll wurde weiterhin mit neuen Versionen gepatcht.

Alle Beteiligten litten stark.

Problem 4: Atomare Tools können die Produktsemantik nicht natürlich ausdrücken

In den Testszenarien von Apidog ist es nicht nur ein einfacher steps-Array-Ausdruck.

Ein Testszenario umfasst:

Nachdem diese in mehrere MCP-Tools aufgeteilt wurden, muss der Agent immer noch die Test-Orchestrierung selbst übernehmen.

Je atomarer die Tools, desto mehr muss das Modell die internen Semantiken des Produkts verstehen:

• Warum muss der Import zurückgelesen werden?
• Warum haben interne Fälle unterschiedliche Update-Marker?
• Warum erfordern Assertions spezifische Vergleichsoperatoren?
• Warum hat die Variablenextraktion Typbeschränkungen?

Dies liegt offensichtlich außerhalb der Fähigkeiten des Modells.

Es zwang das Apidog-Team, proaktiv technische Anpassungen für die interne Produktsemantik vorzunehmen. Atomare Endpunkte fügten passiv eine Konvertierungsschicht hinzu, nur um sich an eine einzige MCP-Tool-Layer-Dispatch anzupassen.

Die technischen Herausforderungen und die Kosten für die Nachwartung sind zweifellos mühsam.

Die Grundursache

Die Grundursache dieser vier Probleme ist dieselbe:

MCP ist besser darin, Tools zu verbinden, aber komplexe F&E-Aufgaben benötigen mehr als nur Tool-Verbindung – sie benötigen ausführbare technische Prozesse.

Für einfache Produkte mit einem Dutzend gut definierter Operationen funktioniert MCP gut. Der Agent kann das richtige Tool vernünftigerweise erraten, es aufrufen und ein Ergebnis erhalten.

Für Produkte wie Apidog – mit Dutzenden von Modulen, Hunderten von Operationen, verschachtelten Strukturen, versteckten Workflows und produktspezifischer Semantik – erzeugt MCP allein eine Wand zufälliger Tools, durch die Agenten nur schwer navigieren können.

Was wir gelernt haben

Der Wendepunkt

Diese Erkenntnis führte uns dazu, eine andere Frage zu stellen:

Wenn MCP nicht die Antwort für die Agenten-Aktivierung ist, was dann?

Wir haben den Wert von MCP nicht aufgegeben – es bietet standardisierte Verbindungen, was für das Ökosystem wichtig ist. Aber wir brauchten etwas, das:

• Workflows ausdrücken kann, nicht nur Tools
• Agenten durch Sequenzen führen kann
• Vor dem Schreiben validiert
• Qualitätssicherungen erzwingt
• Komplexität in das System aufnimmt

Die Antwort, auf die wir kamen: CLI + SKILL.

Im nächsten Beitrag, Warum wir eine brandneue Apidog CLI entwickelt haben, werden wir den architektonischen Wandel untersuchen – wohin die Komplexität vom Modellkontext in das Engineering-System verschoben wurde und warum das alles für die Agenten-Aktivierung verändert.

Wichtige Erkenntnisse

• MCP wurde zur Branchenantwort auf die Frage "Wie verbinden sich Agenten mit Tools?"
• Wir bauten 126 MCP-Tools, in der Annahme, mehr Tools = bessere Aktivierung
• Reale Aufgaben zeigten vier strukturelle Probleme: Entdeckungskosten, Kontextinvasion, Sitzungsaufwand, Produktsemantik
• Die Grundursache: MCP verbindet Tools, aber komplexe Aufgaben benötigen ausführbare Prozesse
• Mehr Tools sind ein Kostenfaktor, kein Vorteil, wenn Tool-Beschreibungen Kontext verbrauchen

Laden Sie Apidog herunter, um APIs in einem Arbeitsbereich zu entwerfen, zu mocken, zu testen und zu dokumentieren. Erfahren Sie mehr über Apidog CLI für Befehlszeilen-API-Tests, CI-Automatisierung und KI-Agenten-Workflows.