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 - 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 - 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 - Dateisysteme, Datenbanken, Geschäftsanwendungen, Entwickler-Tools. Technisch basiert MCP auf JSON-RPC 2.0 über mehrere Transporte: stdio für lokale Server, seit der Spec-Revision im April 2025 zusätzlich Streamable HTTP, dazu OAuth 2.1, JSON-RPC-Batching und Tool-Annotationen. 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. Die SDKs verzeichnen ü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: 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 - 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 - von Anthropic Ende 2025 als Engineering-Ansatz publiziert - 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.

Klassisch - viele 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 - ein generiertes Programm:

```

vom Agenten generierter, in der Sandbox ausgeführter Code

kontakte = mcp.crm.get_contacts()
top = [k for k in kontakte
if mcp.crm.get_last_order(k.id).umsatz > 10000]
return [{"name": k.name, "umsatz": k.umsatz} for k in top]
```

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 und dienen der Größenordnung, nicht als Benchmark.

Der entscheidende Posten ist 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.

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 konkrete Angriffsklassen: indirekte Prompt-Injection über Server-Beschreibungen, Tool Poisoning (Invariant-Labs-PoC, März 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 April-2025-Spec) 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. In DACH-Kontexten ist das zugleich eine Compliance-Anforderung, nicht nur Engineering-Praxis - End-to-End-Trace, Modellversionen gepinnt, Korrelation über eine Trace-ID.

Wer ausführbaren Modell-Code ohne diese Schutzschichten betreibt, tauscht Token-Effizienz gegen ein erhebliches Sicherheits- und Datenschutzrisiko - in regulierten DACH-Branchen 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.