Code Execution mit MCP: Token-Effizienz für komplexe Agenten

Code Execution mit MCP bezeichnet ein Agenten-Muster, bei dem ein KI-Agent statt vieler einzelner Tool-Calls Code schreibt und ausführt, der MCP-Tools programmatisch in einer Sandbox aufruft. Das reduziert Tokenverbrauch und Latenz spürbar, weil Tool-Definitionen und Zwischenergebnisse im Code-Kontext verarbeitet werden, statt vollständig durch das Kontextfenster des Sprachmodells zu laufen. Es ist eine Optimierung für komplexe, datenintensive Workflows und keine Ablösung der klassischen Tool-Calls.

Schnellantworten

• Was es ist: Der Agent generiert ein Programm, das MCP-Tools als Funktionen aufruft; nur das verdichtete Endergebnis kehrt ins Modell zurück.
• Wofür es gut ist: Token- und Latenz-Effizienz bei vielen Tools, vielen Schritten und großen Zwischenergebnissen.
• Was es braucht: Eine isolierte Sandbox, scope-limitierte Tokens und Least-Privilege, denn ausführbarer Modell-Code ist eine eigene Angriffsfläche.

Das Problem: Tool-Calls skalieren schlecht

Das Model Context Protocol (MCP) wurde am 25. November 2024 von Anthropic als offener Standard eingeführt, um KI-Anwendungen mit externen Systemen zu verbinden, etwa mit Dateisystemen, Datenbanken, Geschäftsanwendungen und Entwickler-Tools. Technisch basiert MCP auf JSON-RPC 2.0 über zwei Standard-Transporte: stdio für lokale Server und einen HTTP-Transport, den die Spec-Revision 2025-03-26 (März 2025) vom bisherigen HTTP+SSE auf Streamable HTTP umgestellt hat. Dieselbe Revision brachte OAuth 2.1 und Tool-Annotationen. Das ebenfalls damit eingeführte JSON-RPC-Batching hat die Revision 2025-06-18 wieder gestrichen. Stand 2026 ist MCP der De-facto-Standard für die Agent-zu-Tool-Kommunikation; am 9. Dezember 2025 spendete Anthropic das Protokoll an die neu gegründete Agentic AI Foundation (AAIF) unter dem Dach der Linux Foundation. Zu diesem Zeitpunkt verzeichneten die SDKs laut Anthropic über 97 Millionen monatliche Downloads in Python und TypeScript.

Im klassischen Muster ruft der Agent jedes Tool einzeln auf. Jeder Aufruf durchläuft das Sprachmodell (LLM): Das Modell sieht die Tool-Definition, formuliert den Aufruf, erhält das vollständige Ergebnis zurück in sein Kontextfenster und entscheidet über den nächsten Schritt. Bei einfachen Aufgaben ist das ideal: transparent und gut auditierbar. Bei komplexen Workflows entstehen jedoch zwei Token-Fresser:

1. Tool-Definitionen im Vorlauf. Stehen einem Agenten dutzende oder hunderte MCP-Tools zur Verfügung, müssen deren Beschreibungen vorab in den Kontext geladen werden. Das sind oft tausende Tokens, bevor der Agent überhaupt arbeitet.
2. Zwischenergebnisse im Kontext. Ein Tool, das eine lange Liste, ein großes Dokument oder einen umfangreichen API-Response liefert, schreibt diesen vollständig ins Kontextfenster, auch wenn der Agent nur drei Werte daraus braucht. Bei mehrstufigen Ketten summiert sich das.

Die Lösung: Der Agent schreibt Code

Das Code-Execution-Muster, das Anthropic Ende 2025 als Engineering-Ansatz publiziert hat, kehrt die Logik um. Der Agent generiert ein Programm, typischerweise Python oder TypeScript, das die MCP-Tools als importierbare Funktionen behandelt. Dieser Code läuft in einer Sandbox. Filterung, Schleifen, Verzweigungen und Aggregationen passieren dort, im Code-Laufzeitkontext. Nur das verdichtete Endergebnis kehrt ins Kontextfenster des Modells zurück.

Der Unterschied lässt sich an Pseudocode zeigen. Die Aufgabe: Der Agent soll im CRM alle Kontakte finden, deren letzte Bestellung mehr als 10.000 Euro Umsatz gebracht hat.

Klassisch, mit vielen Tool-Calls über das Modell:

LLM: ruf get_contacts() auf

-> 5.000 Kontakte (vollständig in den Kontext)

LLM: für jeden Kontakt ruf get_last_order(id) auf

-> 5.000 weitere Tool-Calls, jeder einzeln durchs Modell

LLM: filtere die mit Umsatz > 10.000

-> erneut große Datenmengen im Kontext

Code Execution, mit einem generierten Programm:

# vom Agenten generierter, in der Sandbox ausgeführter Code

kontakte = mcp.crm.get_contacts()

umsaetze = {k.id: mcp.crm.get_last_order(k.id).umsatz for k in kontakte}

return [{"name": k.name, "umsatz": umsaetze[k.id]} for k in kontakte if umsaetze[k.id] > 10000]

Im zweiten Fall sieht das Modell weder die 5.000 Kontakte noch die 5.000 Order-Responses. Es sieht nur den Code, den es geschrieben hat, und am Ende die gefilterte Liste. Die Tool-Aufrufe selbst laufen programmatisch ab, nicht als einzelne LLM-Runden. Das spart sowohl Tokens als auch Latenz, weil Schleifen ohne Modell-Roundtrips ausgeführt werden.

Ein zweiter Effekt ist die bedarfsgesteuerte Tool-Entdeckung: Statt alle Tool-Definitionen vorab zu laden, kann der Agent verfügbare MCP-Server und ihre Funktionen wie ein Modul-Verzeichnis durchsuchen und nur die tatsächlich benötigten importieren. Das hält den Vorlauf-Overhead klein, selbst wenn theoretisch hunderte Tools verfügbar wären.

Beispiel mit Zahlen

Eine vereinfachte Rechnung verdeutlicht den Hebel. Annahme: Ein Agent soll aus einem CRM die Top-Kunden ermitteln und mit Bestelldaten anreichern. Die Zahlen sind illustrativ. Sie zeigen Größenordnungen und sind kein Benchmark. Die klassische Spalte bildet dabei den günstigsten Fall ab: Sie zählt nur den Vorlauf und eine einzige Rohliste mit 5.000 Datensätzen. Die 5.000 Einzelaufrufe von get_last_order aus dem Pseudocode oben sind nicht eingerechnet. Jeder davon brächte eine eigene Order-Response und einen Modell-Roundtrip mit. Die klassische Summe läge damit um ein Vielfaches höher.

In der Tabelle ist der entscheidende Posten nicht der Vorlauf, sondern die Zwischenergebnisse: Sie werden im Code verarbeitet und belegen keinen Modell-Kontext. Genau hier liegt der Hebel. Je größer die Datenmengen und je mehr Iterationen, desto stärker fällt der Unterschied aus. Bei einer simplen Einzelabfrage dagegen kehrt sich die Rechnung um: Der Overhead, ein Programm zu generieren und auszuführen, übersteigt den Nutzen.

Konkrete Werte nennt Anthropic im Engineering-Beitrag vom 4. November 2025. Im Beispiel lädt ein Agent ein Meeting-Transkript aus Google Drive und hängt es an einen Salesforce-Lead. Mit direkten Tool-Calls läuft das Transkript zweimal durchs Modell. Bei einem zweistündigen Meeting können das zusätzlich 50.000 Tokens sein. Liegen die Tools als Dateien vor und lädt der Agent nur die Definitionen, die er für die aktuelle Aufgabe braucht, sinkt der Verbrauch laut Anthropic von 150.000 auf 2.000 Tokens, also um 98,7 Prozent.

Wann sinnvoll und wann nicht

Code Execution ist eine Optimierung, kein Standardmuster für alles. Es passt zu datenintensiven, wiederkehrenden Multi-Tool-Workflows. Für einfache, einmalige Aktionen bleiben direkte Tool-Calls schneller, günstiger und transparenter: Der Trace zeigt jeden Schritt direkt, ohne Umweg über generierten Code.

Sicherheit: Sandbox ist Pflicht

Der größte Unterschied gegenüber klassischen Tool-Calls ist sicherheitsrelevant: Beim Code-Execution-Muster führt das System von einem Sprachmodell generierten, ausführbaren Code aus. Das ist eine eigenständige Angriffsfläche. Für MCP ist Stand 2026 ein bewusst optimistisches Trust-Modell dokumentiert, das syntaktische Korrektheit mit semantischer Sicherheit gleichsetzt. Dazu kommen konkrete Angriffsklassen: indirekte Prompt-Injection über Server-Beschreibungen, Tool Poisoning (Invariant-Labs-PoC, April 2025), Look-alike-Server-Squatting und CyberArks Full-Schema-Poisoning, bei dem jeder Teil eines Tool-Schemas ein Injection-Vektor sein kann. Härtung ist dabei ausdrücklich Aufgabe des Betreibers.

Für Code Execution heißt das konkret:

• Isolierte Sandbox. Der generierte Code läuft in einer abgeschotteten Laufzeitumgebung ohne breiten Datei- und Netzwerkzugriff, mit Ressourcen- und Zeitlimits gegen Endlosschleifen und Ressourcen-Erschöpfung.
• Scope-limitierte Tokens. MCP-Server hinter OAuth 2.1 (seit der Spec-Revision 2025-03-26, März 2025) mit minimal nötigen Berechtigungen. Der Code erhält nur Zugriff auf das, was die Aufgabe verlangt.
• Least-Privilege und keine autonome Installation. Agenten dürfen keine MCP-Server aus nicht vertrauenswürdigen Registries selbstständig nachladen oder installieren.
• Vollständiges Audit-Logging. Jeder Tool-Aufruf aus dem Sandbox-Code wird protokolliert, mit End-to-End-Trace, gepinnten Modellversionen und Korrelation über eine Trace-ID. In regulierten DACH-Branchen können Prüfer und Aufsicht solche Nachweise verlangen.

Wer ausführbaren Modell-Code ohne diese Schutzschichten betreibt, tauscht Token-Effizienz gegen ein erhebliches Sicherheits- und Datenschutzrisiko. In regulierten DACH-Branchen ist das ein No-Go.

Für Agenturen und B2B-Entscheider

Für DACH-Agenturen und produktisierende AI-Vendors ist Code Execution mit MCP der direkte Hebel auf die Unit Economics agentischer Produkte. Wer Multi-Tenant-Dienste betreibt (etwa SEO-, Newsletter- oder Recherche-Agenten), zahlt pro Lauf in Tokens; das Code-Execution-Muster senkt diese Kosten bei datenintensiven Workflows messbar und reduziert zugleich die Latenz, was die wahrgenommene Produktqualität verbessert. Der praktische Einstieg: Bestehende MCP-basierte Agenten daraufhin prüfen, welche Workflows viele Tools und große Zwischenergebnisse durchlaufen, genau diese auf Code Execution umstellen und von Tag eins Sandbox, OAuth-2.1-Scopes und Audit-Logging mitbauen. Für B2B-Entscheider gilt: Das Muster ist eine Architekturentscheidung pro Workflow, kein Plattformwechsel. Es setzt auf dem ohnehin etablierten MCP-Standard auf und lässt sich schrittweise einführen, ohne die bestehende Tool-Integration zu verwerfen.