Warum wir eine 96%ige Token-Ersparnis abgelehnt haben

Wir haben einen MCP-Server gefunden, der 96 % an Token spart. Er nutzt ein einziges Tool: execute_code. Anstatt spezifische Funktionen aufzurufen, schreibt der Agent JavaScript, um Daten abzurufen.

Auf dem Papier gewinnt er. Bei komplexen Aufgaben schlägt die Code-Ausführung das Tool-Calling in Sachen Effizienz.

Aber wir haben ihn nicht übernommen. Stattdessen sind wir bei unseren diskreten, benannten Tools geblieben.

Hier ist der Grund, warum die offensichtliche Wahl die falsche Wahl für unseren Agenten war.

Das Ziel bestimmt das Design

Die meisten Menschen entwickeln für Frontier-Modelle in einem Chat-Fenster. Diese Modelle verfügen über riesige Token-Budgets. Für sie ist die Code-Ausführung das Maß aller Dinge.

Wir entwickeln für einen Voice-First-Agenten auf einem kleinen lokalen Modell (Hermes 3 8B) auf einem Boot.

Bei einem kleinen Modell ist nicht die Token-Anzahl die Einschränkung. Die Einschränkung ist die Zuverlässigkeit.

Wenn ein kleines Modell bereits Schwierigkeiten hat, ein einfaches Tool aufzurufen, ist die Aufgabe, korrektes JavaScript zu schreiben, weitaus schwieriger. execute_code tauscht Zuverlässigkeit gegen Token ein. Diesen Kompromiss können wir uns nicht leisten.

Das Last-Mile-Problem

Die Code-Ausführung verlagert die „letzte Meile“ der Arbeit auf den Agenten. Der Agent muss:

  • Daten filtern
  • Ergebnisse sortieren
  • Die Ausgabe formatieren

Unsere Tools erledigen diese Arbeit innerhalb des Servers. Wenn wir beispielsweise nach dem Batteriestatus fragen, gibt unser Tool einen String zurück, der bereit für Text-to-Speech ist. Er sagt „68 Prozent, 12,8 Volt“ anstatt nur Rohdaten zu liefern.

Wenn wir execute_code verwenden, muss der Agent die Logik schreiben, um diese Sprachausgabe zu formatieren. Kleine Modelle scheitern ständig daran.

Die Regel für fehlende Werte

Auf einem Boot fallen Sensoren aus. In unserem System liefert ein fehlender Sensor ein sauberes null. Dies ist ein erfolgreicher Aufruf.

In einem Modell zur Code-Ausführung führt ein fehlender Sensor oft zu einem Fehler. Wenn ein kleines Modell ein paar falsche Pfade errät, werden Fehlerschwellenwerte überschritten und der Agent bricht ab. Benannte Tools ermöglichen es uns, das Fehlen eines Wertes als Erfolg zu behandeln und nicht als Fehler.

Checkliste: Übernehmen vs. Selbst bauen

Bevor Sie einen MCP-Server übernehmen oder selbst bauen, stellen Sie sich diese Fragen:

• Wer ist der Ziel-Agent? (Frontier-Modell vs. kleines lokales Modell) • Was ist die entscheidende Einschränkung? (Token vs. Zuverlässigkeit) • Wer erledigt die letzte Meile? (Formatiert das Tool die Daten oder der Agent?) • Wie wird das Fehlen von Werten gehandhabt? (Ist ein fehlender Wert ein Fehler oder ein null?) • Wie hoch sind die Wartungskosten? (Übernehmen Sie eine brachliegende Codebasis?)

Wir haben das andere Projekt nicht ignoriert. Wir haben dessen Ideen genutzt. Wir haben deren Alarmbehandlung und Pfadentdeckungslogik übernommen und in unsere Roadmap integriert.

Effizienz ist großartig, aber Zuverlässigkeit ist erforderlich, wenn man auf dem Wasser ist.

Quelle: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Optionale Lern-Community: https://t.me/GyaanSetuAi