Von MCP-Tools zu TypeScript‑APIs: 98 % weniger Token

Ein Agent, der dutzende Tools kennt, trägt häufig die Last all dieser Definitionen im Kopf: lange Prompt‑Blöcke, große JSON‑Payloads, Logauszüge. Das treibt den Tokenzähler in die Höhe und macht viele Szenarien teuer oder schlicht nicht skalierbar. Das Model Context Protocol (MCP) will hier Standardisierung bringen; das Muster „code execution with MCP” geht einen Schritt weiter: Statt alles in den Kontext zu kopieren, lässt man Modelle Code erzeugen, der lokal als TypeScript‑Modul ausgeführt wird. Dieser Text erklärt, warum genau das Token spart, welche Architekturmuster sinnvoll sind und welche Sicherheitsfragen besonders wichtig sind.

Das Model Context Protocol wurde entwickelt, um LLMs standardisiert Zugang zu Tools, Ressourcen und Prompts zu geben. In der Praxis heißt das oft: jede verfügbare Funktion, jedes Schema und viele Zwischenresultate werden als Tool‑Definitionen und Beispiele an das Modell übermittelt. Das Problem ist nicht die Idee, sondern die Skalierung: Wenn ein Agent zehn, zwanzig oder mehr Connectoren kennt, wächst das Kontextfenster schnell auf Zehntausende Tokens. Diese Form der „Tool‑Menge im Kopf“ führt zu hohen Kosten und erhöhten Latenzen.

Technisch entsteht der Tokenverbrauch an drei Stellen: (1) Definitions‑Overhead — ausführliche Tool‑Schemas und Signaturen; (2) Beispiel‑Dumps — große Input‑/Output‑Beispiele, die dem Modell als Gedächtnis dienen sollen; (3) Round‑trip‑Ergebnisse — vollständige Datensätze, die zurück ins Modell kommen, um Folge‑Entscheidungen zu steuern. Wenn alle drei wachsen, explodiert die Tokenzahl. Anthropic und weitere Autoren haben deshalb das Code‑Execution‑Pattern vorgeschlagen: nur minimale Metainformationen im Kontext, verbleibende Logik in ausführbaren Modulen.

“Große Payloads gehören nicht dauerhaft ins Modellkontextfenster — sie gehören in eine kontrollierte Laufzeit.”

Die Konsequenz ist klar: Wer die Datenlast aus dem Prompt‑Fenster verlagert, reduziert die wiederholte Übertragung großer Texte. In einem berichteten Fall führte die Umstellung auf Code‑Execution zu einer dramatischen Reduktion des Tokenverbrauchs — konkrete Zahlen sind Fallabhängig und stammen aus sekundären Berichten; Primärbenchmarks sollten vor Produktionsentscheidungen reproduziert werden.

Der Kern des Code‑Execution‑Ansatzes ist einfach: Modelle erzeugen ausführbaren Code, der in einer kontrollierten Laufzeit (z. B. einer TypeScript‑Sandbox) importiert und ausgeführt wird. Damit werden große Datenströme und komplexe Verarbeitungslogiken außerhalb des Modellkontexts gehalten. Statt einem Prompt ein komplettes Datenobjekt zu übergeben, gibt das Modell nur noch eine kurze Anweisung oder ein kurzes Script aus — der Rest passiert lokal.

Warum spart das Tokens? Weil wiederholte Details nicht mehr bei jedem Schritt in das Kontextfenster kopiert werden müssen. Ein einmal geladenes Modul enthält die Logik und kann lokal mit kleinen Inputs gesteuert werden. In der Praxis bedeutet das: weniger prompt‑Wiederholungen, weniger Beispielkopien, und nur relevante, komprimierte Ergebnisse wandern zurück ins Modell. Hier zeigt sich ein Nähe‑zum‑Traditionellen Software‑Engineering: Fähigkeiten werden in modularen APIs kapselt, nicht als Text im Prompt dupliziert.

Anthropic beschreibt dieses Muster ausführlich und weist auf Design‑Praktiken hin: progressive Tool‑Discovery (Module werden nur bei Bedarf geladen), Platzhalter für sensible Felder (Tokenization/Masking) und Reuse von generierten Skripten. Berichte aus der Community nennen extreme Einsparungen in Einzelfällen — etwa eine Reduktion um knapp 98 % in einem spezifischen Workflow — diese Zahl ist aber als Fallbericht zu verstehen und benötigt Primär‑Reproduktion.

Wichtig ist die richtige Balance: Code darf nicht zur Blackbox werden. Tests, Repro‑Beispiele und deterministische Interfaces sind nötig, damit das Verhalten stabil bleibt. Der Shift ändert damit nicht nur Kostenprofile, sondern auch Entwicklungs‑ und Ops‑Praktiken.

In der Praxis greifen Teams auf TypeScript‑SDKs zurück, weil die Typisierung, Modulstruktur und Entwickler‑Tooling den Übergang von Text zu ausführbarem Code erleichtern. Das MCP‑Ökosystem bietet heute offizielle SDKs und Beispiel‑Server; viele Entwickler starten mit einem kleinen PoC‑Agenten, der eine bestimmte Pipeline (z. B. Transkript → Zusammenfassung → CRM) lokal als Modul abbildet und nur komprimierte Ergebnisse zurückmeldet.

Ein übliches Setup sieht so aus: (1) MCP‑Server registriert verfügbare Ressourcen und kleine Interfaces; (2) Modell erzeugt ein TypeScript‑Snippet, das diese Interfaces konsumiert; (3) Die Laufzeit validiert den Code gegen eine Allowlist, kompiliert ihn in eine Sandbox (z. B. WASM, Deno‑Isolate oder Node‑VM mit Einschränkungen) und führt ihn aus; (4) Nur strukturierte, max. wenige Kilobyte große Antworten werden an das Modell zurückgegeben. Dieser Flow minimiert den Token‑Footprint jeder Interaktion.

Cloudflare‑ähnliche Konzepte (Code Mode / Workers) werden oft als verwandte Muster genannt, weil sie ebenfalls kleinen, isolierten Ausführungsraum bieten. Wichtiger als die konkrete Runtime ist jedoch das Sicherheitsmodell: Capability‑Based Bindings, Minimalrechte für I/O, und strikte Secrets‑Handhabung sind Pflicht. Die Community empfiehlt zudem: Pinning von SDK‑Versionen, Audit‑Logs jeder Ausführung und automatische Tests für generierte Skripte.

Technisch lassen sich so auch Offline‑Caches und lokale Artefakte nutzen: große Dokumentensammlungen bleiben im Storage; Modelle arbeiten nur mit Indices, Signaturen oder kompakten Summaries. Das senkt nicht nur Tokens, sondern kann Antwortzeiten stabiler machen, weil die Engine nicht jedes Mal Gigabytes an Kontext parsen muss.

Abschließend: Die Implementierung bringt engineering‑Aufwand, aber sie macht Agenten deutlich effizienter. Wer den Wechsel wagt, sollte Messungen zu Tokenverbrauch und Latenz in den Mittelpunkt stellen — und die Ergebnisse offen dokumentieren.

Die Aussicht auf 90+ Prozent Einsparungen klingt verlockend. In der Realität gibt es Grenzen: Einsparungen hängen stark von Workflow‑Charakteristika ab — wie groß sind die Payloads, wie oft werden sie benötigt, wie deterministisch ist die Logik. Berichte über ~98 % Reduktion stammen aus konkreten Fällen; ohne reproduzierbare Benchmarks bleibt die Bandbreite der möglichen Einsparungen groß.

Aus Sicherheits‑sicht verlagert das Pattern einige Risiken vom Prompt‑Fenster in die Laufzeit: ausführbarer Code erhöht die Angriffsfläche. Relevante Maßnahmen sind hier nicht neu, aber zwingend: Strikte Sandboxing‑Techniken, Whitelists für erlaubte APIs, Code‑Audits, Ratenbegrenzung und ein klares Secrets‑Handling. Einige Anbieter im MCP‑Umfeld liefern bereits Guidelines für diese Controls, andere Community‑Beiträge warnen vor zu lockerer Konfiguration.

Operational betrachtet müssen Teams TCO rechnen: Ersparnis bei Tokenkosten steht gegen Entwickler‑ und Infrastrukturkosten (Sandboxing, Monitoring, Sicherheitstests). Eine konservative Herangehensweise ist, zunächst ein enges PoC mit klaren Metriken zu bauen: Token‑Count pro Anfrage, Latenz, Fehlerquote, und Gesamtkosten pro Transaktion. Nur so lässt sich seriös beurteilen, ob sich der Mehraufwand lohnt.

Schließlich ein ethischer Hinweis: Wenn Modelle Code erzeugen, muss nachvollziehbar sein, welche Entscheidungen im Code stecken. Dokumentation, Versionierung und Auditierbarkeit sind somit nicht nur nice‑to‑have, sondern Governance‑Pflicht.

Das Muster „code execution with MCP” zeigt einen realistischen Weg, Tokenkosten zu reduzieren, indem Logik und große Datenströme aus dem Modellkontext ausgelagert werden. TypeScript‑APIs und sandboxed Runtimes sind praktikable Werkzeuge für diesen Ansatz. Berichte über Einsparungen bis zu 98 % sind vielversprechend, aber Fallabhängig — reproduzierbare Benchmarks und Sicherheitstests sind Voraussetzung für Entscheidungen in Produktion.

Kurz: weniger Text im Prompt bedeutet nicht weniger Verantwortung. Wer Token spart, gewinnt gleichzeitig die Pflicht, Laufzeit, Governance und Auditierbarkeit sauber zu organisieren.