KI-Agenten, Tool-Use & MCP: wenn das Modell selbst handelt
Ein Sprachmodell allein produziert Text. Sobald es Werkzeuge aufrufen, Ergebnisse prüfen und mehrschrittig weiterarbeiten kann, wird daraus ein handelndes System – ein Agent. Dieser Artikel erklärt die Bausteine: Tool-Use als Motor, den Agenten-Loop, das Model Context Protocol (MCP) für die Werkzeug-Anbindung und das ergänzende A2A-Protokoll für die Agent-zu-Agent-Kommunikation, Muster zur Orchestrierung – und warum „so einfach wie möglich“ die wichtigste Regel bleibt.
11 Min. Lesezeit
11 Abschnitte
19 Quellen
Stand: 16. Juni 2026
Agent oder Workflow?
Nicht jedes „KI-System“ ist ein Agent. Anthropic trennt sauber: In einem Workflow sind Modell und Werkzeuge über fest vorgegebene Code-Pfade orchestriert – der Ablauf steht vorher fest. In einem Agenten steuert das Modell seinen eigenen Ablauf und Werkzeugeinsatz dynamisch selbst und behält die Kontrolle darüber, wie es die Aufgabe löst.
Der Unterschied ist praktisch, nicht akademisch: Ein Workflow ist vorhersehbar und günstig zu betreiben, ein Agent flexibel, aber teurer und schwerer zu kontrollieren. Die Faustregel vorweg: erst den einfachsten Weg ausreizen – oft genügt ein einzelner, gut gebauter Modellaufruf mit Kontext –, und Agenten nur dort einsetzen, wo die einfacheren Lösungen nicht reichen.
MerksatzWorkflow = feste Pfade, vorhersehbar. Agent = das Modell bestimmt den Ablauf selbst, flexibel, aber schwerer zu führen.
Tool-Use: vom Reden zum Handeln
Der Motor jedes Agenten ist Tool-Use (auch Function-Calling). Wichtig: Das Modell führt nichts selbst aus. Es bekommt eine Liste definierter Werkzeuge – jeweils Name, Beschreibung und ein JSON-Schema der Parameter – und liefert, wenn es ein Werkzeug braucht, einen strukturierten Aufruf zurück. Die Anwendung führt diesen aus und reicht das Ergebnis ans Modell zurück.
So entscheidet das Modell, wann eine Datenbankabfrage, eine Berechnung oder ein API-Aufruf nötig ist – und arbeitet mit dem echten Ergebnis weiter, statt es zu raten. Eine Werkzeug-Definition sieht etwa so aus:
{"name":"wetter_abfragen","description":"Liefert das aktuelle Wetter für einen Ort.","input_schema":{"type":"object","properties":{"ort":{"type":"string","description":"Stadt, z. B. Wien"},"einheit":{"type":"string","enum":["celsius","fahrenheit"]}},"required":["ort"]}}
Der Agenten-Loop
Ein Agent ist im Kern ein Modell in einer Schleife: Es plant einen Schritt, ruft ein Werkzeug auf, beobachtet das Ergebnis aus der Umgebung und entscheidet auf dieser Basis den nächsten Schritt – so lange, bis die Aufgabe erledigt ist oder eine Grenze (Schrittzahl, Budget, Zeit) erreicht wird. Diese Rückkopplung mit der echten Umgebung unterscheidet den Agenten vom starren Skript.
Entscheidend ist, woran sich der Loop verankert: Läuft der Agent gegen einen echten Prüfstein – Tests, Compiler, ein Schema, die laufende Anwendung –, korrigiert er sich an Fakten. Ohne solche Rückmeldung rät er im Zweifel. Für das Programmieren ist dieser Loop im Coding-Artikel ausführlich beschrieben.
MerksatzEin Agent ist ein Modell in einer Schleife – mit Werkzeugen und Umgebungs-Feedback. An echten Prüfsteinen verankert schlägt geraten.
Jedes Werkzeug einzeln an jedes Modell zu koppeln, skaliert nicht – aus M Anwendungen und N Werkzeugen werden schnell M×N Einzel-Integrationen. Das Model Context Protocol (MCP) löst das wie ein gemeinsamer Stecker: Anthropic beschreibt es als „USB-C-Anschluss für KI“. Ein Werkzeug oder eine Datenquelle wird einmal als MCP-Server bereitgestellt und spricht dann mit jedem MCP-fähigen Client dieselbe Sprache.
Anthropic stellte MCP im November 2024 als offenen Standard vor – und es blieb nicht hauseigen: OpenAI übernahm MCP im März 2025 (u. a. ChatGPT-Desktop und Agents-SDK), Google bestätigte Unterstützung in den Gemini-Modellen, und Ende 2025 wurde das Protokoll in eine herstellerneutrale Stiftung überführt. Aus konkurrierenden Insellösungen wurde ein gemeinsamer Standard. Für Entwickler heißt das: einmal bauen, mit Modellen mehrerer Anbieter nutzbar.
MCP (Model Context Protocol)Offener Standard, über den ein Modell einheitlich externe Werkzeuge und Datenquellen anbindet. Macht Tool-Anbindungen austauschbar statt anbieterspezifisch.Mehr im Wissen → ist ein sauberer Standard für die Anbindung – aber er hat einen Preis, der im Alltag oft übersehen wird: Werkzeuge kosten Kontext, schon bevor der Agent eines davon benutzt. Bei MCP werden die Tool-Definitionen vieler angebundener Server beim Start in den Kontext geladen, auch die ungenutzten. Anthropic beschreibt für Setups mit Dutzenden MCP-Servern, dass so „Hunderttausende Token verbraucht werden, noch bevor eine Anfrage gelesen ist“. Genau hier setzt die Gegen-Nuance an: Für einen Agenten, der ohnehin eine Shell hat, ist ein schlankes Kommandozeilen-Werkzeug (CLI (Command-Line Interface)Werkzeug, das über die Kommandozeile (Shell) bedient wird. Für Agenten mit Shell-Zugriff oft eine schlanke Alternative zur MCP-Anbindung: Ein einzelnes CLI-Tool belegt weniger Kontext als ein dauerhaft geladener MCP-Server – es ruft seine Definition erst beim Aufruf ab.Mehr im Wissen →) oft die günstigere Anbindung – nicht weil MCP schlecht wäre, sondern weil ein einzelnes CLI-Tool den Kontext schlank hält.
Das ist kein Randeffekt. Eine unabhängige Analyse beziffert den Aufschlag pro ungenutztem MCP-Server auf häufig 30 bis 50 % der Token, im Extremfall bis 72 % – pro Werkzeug grob 550 bis 1.400 Token, allein fürs Bereitstehen. Diese Zahl deckt sich der Größenordnung nach mit Anthropics eigenem Erfahrungswert: In einem internen Fall standen rund 134 K Token an Tool-Definitionen im Kontext, bevor der Agent überhaupt loslegte. Praktiker greifen das auf – auf einschlägigen Entwickler-Kanälen kursiert die Faustregel, ungenutzte MCP-Server fräßen leicht „10 bis 20 % des Kontexts“; gemessen an den unabhängigen Zahlen ist das eher die konservative Untergrenze.
Was am Kontext klebt, fehlt an anderer Stelle und kostet doppelt: einmal an Geld pro Token, einmal an Qualität, denn ein vollgepackter Kontext verschlechtert die Treffsicherheit (siehe Kontext-EngineeringDie Disziplin, gezielt zu kuratieren, welche Tokens während der Inferenz im Kontextfenster stehen – statt möglichst viel hineinzukippen. Kontext ist eine endliche Ressource; Ziel ist „informativ, aber knapp“. Gilt als Fortsetzung des Prompt-Engineerings.Mehr im Wissen → und der Abschnitt zum Kontextfenster). Deshalb gilt für Werkzeuge dieselbe Disziplin wie für alles andere im Kontextfenster: so viel wie nötig, so wenig wie möglich.
Was Werkzeuge kosten
Tool-Definitionen liegen im Kontext – auch ungenutzte, vor dem ersten Aufruf
Aufschlag je MCP-Server
oft 30–50 % der Token, Extremfall 72 % (~550–1.400 Token/Tool)
Anthropic-Beispiel
~134 K Token Tool-Definitionen im Kontext vor dem ersten Schritt
MerksatzWerkzeuge kosten Kontext, bevor der Agent sie nutzt. Für einen Shell-Agenten ist ein schlankes CLI-Tool oft günstiger als ein dauerhaft geladener MCP-Server.
Wie stark der Unterschied wird, zeigt die Browser-Automatisierung. Der MCP-Server von Playwright legt nach einer Aktion den vollen Accessibility-Tree der Seite – die strukturierte, vorgelesene Repräsentation aller Bedienelemente – in den Kontext. Bei komplexen Seiten ist das eine Menge Text, die das Modell mitschleppt. Die CLI-Variante geht den umgekehrten Weg: Sie schreibt diesen Baum auf die Festplatte und reicht dem Modell nur eine Referenz darauf; den Inhalt holt sich der Agent erst, wenn er ihn wirklich braucht. Microsofts eigene Projekt-Doku begründet die CLI-Variante genau damit – sie vermeide „große Tool-Schemata und ausführliche Accessibility-Trees“ im Kontext.
In Zahlen, an einer identischen Browser-Aufgabe gemessen: rund 114 K Token über den MCP-Server gegenüber etwa 27 K über das CLI – ein Faktor von gut vier, also knapp 90 K Token Unterschied für dasselbe Ergebnis. Das ist es, was hinter der gern zitierten „90.000 Token gespart“-Zahl steht, die auf Entwickler-Kanälen die Runde macht. Sie ist keine Naturkonstante – wie viel man spart, hängt stark von Aufgabe und Seite ab –, aber die Richtung ist robust belegt. Der Mechanismus dahinter ist allgemein: Wer dem Modell nur Zusammenfassungen statt Rohdaten gibt, spart drastisch. Anthropic berichtet von einem Workflow, der so von 150 K auf 2.000 Token fiel – ein Minus von 98 %.
Dieselbe Logik gilt für die teuren screenshot-basierten Ansätze: Praktiker, die mit visuell steuernden Browser-Agenten arbeiten, berichten, diese seien spürbar teurer, weil jeder Screenshot als Bild viele Token kostet – ein weiterer Fall, in dem die schlankere, textbasierte Anbindung gewinnt.
Playwright: MCP vs. CLI
~114 K vs. ~27 K Token für dieselbe Aufgabe – Faktor ~4
Warum
MCP lädt den vollen Accessibility-Tree; CLI legt ihn auf Disk und reicht nur eine Referenz
Allgemeiner Hebel
Zusammenfassungen statt Rohdaten – ein Anthropic-Workflow: 150 K → 2 K Token (−98 %)
MerksatzDer Trick ist nicht „CLI statt MCP“, sondern „Referenz statt Rohdaten“: nur ins Modell laden, was es jetzt braucht.
Tradeoff statt Sieger – und der Anschluss an „weniger Werkzeuge“
Daraus „immer CLI statt MCP“ zu machen, wäre die falsche Lehre. Es ist ein Tradeoff, kein Sieger: Beim Token-Verbrauch gewinnt das CLI, wenn der Agent ohnehin eine Shell hat – aber MCP bleibt richtig, wo Zustand über mehrere Aufrufe hinweg gehalten werden muss, wo mehrere Clients dieselbe Anbindung teilen oder wo der Agent in einer abgeschotteten Umgebung ohne Shell-Zugriff läuft. Nicht ohne Grund liefern größere Anbieter beides parallel und kombinieren sie. Die richtige Frage ist also nicht „welches gewinnt“, sondern „was kostet diese Anbindung an Kontext, und brauche ich ihre Fähigkeiten überhaupt jede Sitzung?“.
Auch Anthropic löst das Problem nicht durch „weg von MCP“, sondern durch schlankeres Laden: Werkzeuge werden über eine Code-Ausführungs-Schicht erst bei Bedarf nachgezogen, und ein Tool-Search-Tool reicht dem Modell zunächst nur einen durchsuchbaren Index statt aller Definitionen. In einem internen Fall sank die Last so von 134 K Token um rund 85 %, bei zugleich höherer Erfolgsrate. Das ist dasselbe Prinzip, das im Skill-Konzept als Progressive Disclosure auftaucht: nicht alles vorab in den Kontext, sondern bei Bedarf nachladen.
Das ist dieselbe Reliability-Regel, die der Abschnitt „Grenzen & Sicherheit“ weiter unten zieht – „so wenige Werkzeuge wie nötig, nicht so viele wie möglich“. Eine saubere Faustregel, die unter Praktikern kursiert, bringt es auf den Punkt: Ein neues CLI besser als Agent SkillWiederverwendbares Können als Ordner mit einer SKILL.md (Name, Beschreibung, Anleitung, optional Skripte). Die vollen Anweisungen lädt der Agent erst, wenn eine Aufgabe zur Beschreibung passt (Progressive Disclosure) – viele Skills bei wenig Kontextkosten.Mehr im Wissen → einbinden statt als dauerhaft geladenen MCP-Server – so steht die Anleitung bereit, belegt aber den Kontext erst, wenn die Aufgabe sie ruft. Wie man Werkzeuge, Skills und Kontext gezielt schlank hält, vertieft der eigene Artikel zum Verstärken eines Modells.
CLI gewinnt bei
Token-Verbrauch, wenn ohnehin eine Shell da ist
MCP bleibt richtig bei
geteiltem Zustand, mehreren Clients, shell-losen/sandboxed Agenten
MerksatzKein Sieger, sondern ein Tradeoff: CLI spart Kontext, MCP trägt Zustand und teilt sich. Die eigentliche Regel ist Progressive Disclosure – Werkzeuge bei Bedarf laden, nicht auf Vorrat.
MCP verbindet einen Agenten mit Werkzeugen und Daten – das ist die vertikale Achse. Doch wie sprechen zwei eigenständige Agenten verschiedener Anbieter miteinander, etwa um eine Teilaufgabe zu delegieren? Dafür gibt es ein zweites, ergänzendes Protokoll: A2A (Agent2Agent), von Google im April 2025 vorgestellt und am 23. Juni 2025 an die Linux Foundation übergeben – seither herstellerneutral und offen weiterentwickelt. Die offizielle Doku bringt die Arbeitsteilung auf den Punkt: Es hängt davon ab, womit ein Agent interagiert. MCP regelt den Zugriff auf Werkzeuge (Agent ↔ Werkzeug), A2A die Zusammenarbeit (Agent ↔ Agent). Sie konkurrieren nicht – ein Agent holt sich per MCP Daten und delegiert per A2A eine Teilaufgabe an einen spezialisierten Partner.
Der Kern-Mechanismus ist die „Agent Card“: ein maschinenlesbarer Steckbrief, der Fähigkeiten, Ein- und Ausgabeformate und die Authentifizierung eines Agenten beschreibt. Andere Agenten finden darüber passende Partner, delegieren Aufgaben und koordinieren – ohne die innere Funktionsweise des Gegenübers zu kennen, ähnlich einem Service-Steckbrief in einer Microservice-Architektur. Die Trägerschaft ist breit: Schon zur Übergabe standen über 100 Firmen dahinter (u. a. Microsoft, AWS, Salesforce, SAP, ServiceNow, Cisco), bis 2026 über 150 Organisationen; Azure AI Foundry, Amazon Bedrock und Google Cloud binden A2A nativ ein. Vieles ist noch jung – aber die Richtung ist klar: aus konkurrierenden Insellösungen werden zwei sich ergänzende Standards, MCP für Werkzeuge, A2A für Agenten.
A2A vorgestellt / übergeben
Google 4/2025 · Linux Foundation 6/2025
Trägerschaft (2026)
> 150 Organisationen, herstellerneutral
Arbeitsteilung
MCP: Agent↔Werkzeug · A2A: Agent↔Agent
MerksatzMCP verbindet Agenten mit Werkzeugen, A2A verbindet Agenten miteinander – zwei sich ergänzende Standards, keine Konkurrenten.
Mehrere Schritte, mehrere Agenten
Zwischen „ein Modellaufruf“ und „voll autonomer Agent“ liegt eine Reihe bewährter Muster, die Anthropic beschreibt – meist als Workflow, also mit festen Pfaden: Prompt-Chaining (eine Aufgabe in eine Kette von Schritten zerlegen), Routing (Eingaben klassifizieren und an spezialisierte Pfade leiten), Parallelisierung (Teilaufgaben gleichzeitig laufen lassen oder mehrfach abstimmen), Orchestrator-Worker (ein führendes Modell zerlegt die Aufgabe und verteilt sie an Helfer) und Evaluator-Optimizer (ein Modell erzeugt, ein zweites bewertet und verbessert in Runden).
Mehr Agenten sind nicht automatisch besser: Jeder zusätzliche Schritt kostet Tokens, Latenz und Kontrolle. Ein gut dokumentiertes Beispiel, wann sich Aufteilung lohnt – spezialisierte Reviewer plus ein Koordinator, Aufwand nach Risiko dosiert –, steht im Coding-Artikel.
Mehr Agenten kosten mehr – die Frage im Maßstab ist, wann sich das auszahlt. Anthropic hat sein Research-System offengelegt: Ein Leit-Agent zerlegt die Frage und startet 3–5 Subagenten parallel, die unabhängige Spuren gleichzeitig erkunden. Auf dem internen Recherche-Eval schlug dieses Team einen einzelnen Spitzen-Agenten um gut 90 %. Der Preis ist hoch: Multi-Agenten-Systeme verbrauchen rund 15× so viele TokenDie kleinste Verarbeitungseinheit eines Sprachmodells – ein Wortstück, kein ganzes Wort. Faustregel: rund 1.000 Tokens entsprechen grob 750 deutschen Wörtern. Preise und Kontextlängen werden in Tokens gerechnet.Mehr im Wissen → wie ein normaler Chat, und der Token-Verbrauch allein erklärt etwa 80 % der Leistungsvarianz. Die Rechnung geht nur auf, wenn „der Wert der Aufgabe hoch genug ist, um die höhere Leistung zu bezahlen“ – etwa bei breit angelegter Recherche, wo viele unabhängige Pfade gleichzeitig verfolgt werden müssen. Cloudflares Code-Review (im Coding-Artikel) folgt demselben Muster: unabhängige Prüf-Dimensionen, parallel, plus ein Koordinator.
Genauso wichtig ist, wann Aufteilung schadet. Die Macher des Coding-Agenten Devin warnen in „Don’t Build Multi-Agents“ (Cognition, von Walden Yan): Sobald parallele Agenten ohne geteilten Kontext arbeiten, treffen sie einander widersprechende Annahmen – „Handlungen tragen implizite Entscheidungen in sich, und widersprüchliche Entscheidungen führen zu schlechten Ergebnissen“. Ihr Beispiel: Ein Subagent baut einen Mario-artigen Hintergrund, ein anderer einen stilistisch unpassenden Vogel – der Koordinator kann das nicht mehr zusammenführen. Bezeichnend ist die Einigkeit beim Programmieren: Anthropic merkt an, dass die meisten Coding-Aufgaben „weniger echt parallelisierbare Teile“ haben als Recherche; Cognition rät, Schreibzugriffe single-threaded zu halten und Subagenten nur zuarbeiten zu lassen (so machen es Claude Codes Subagenten – sie beantworten Fragen, schreiben aber keinen Code parallel). Für lange Aufgaben empfehlen sie statt vieler Agenten einen linearen Agenten mit einem Verdichtungs-Schritt, der Verlauf und Entscheidungen komprimiert.
Anthropic-Research-System
Leit-Agent + 3–5 parallele Subagenten; +90 % vs. Einzel-Agent
MerksatzMulti-Agent im Maßstab lohnt sich für breit-parallele Aufgaben mit hohem Wert (Recherche, mehrdimensionales Review). Beim eng gekoppelten Arbeiten wie Code-Schreiben schlägt es zurück – dann ist ein linearer Agent verlässlicher.
Agenten greifen nach immer längeren Aufgaben, sind damit aber nicht zuverlässig fertig: Die Forschungsorganisation METR misst die Aufgabenlänge, die ein Modell mit 50 % Erfolg autonom schafft – eine 50-%-Marke ist kein „gelöst“. Und je länger ein Agent läuft, desto eher verliert er die ursprüngliche Anweisung aus dem Blick; unumkehrbare Aktionen gehören abgesichert.
Wo das Risiko am größten wird, lässt sich erstaunlich einfach einordnen. Der quellenbewusste Entwickler Simon Willison – der schon die MCP-Injektionsprobleme früh benannt hat – prägte dafür das Bild der „Lethal Trifecta“, das auch der KI-Analyse-Podcast Cognitive Revolution aufgreift: Drei Fähigkeiten zusammen machen einen Agenten gefährlich – Zugriff auf sensible Daten, das Verarbeiten ungeprüfter Fremdinhalte (das Einfallstor für Prompt-Injection) und die Fähigkeit, nach außen zu kommunizieren (der Weg zur Exfiltration). Solange alle drei Kanten gleichzeitig offen sind, kann untergeschobener Text Daten abgreifen und hinausschleusen. Der praktische Hebel: Es genügt, eine der drei Kanten zu kappen – etwa den Außenkanal zu schließen oder Fremdinhalte nicht ungefiltert ins Modell zu lassen –, um den Angriff zu entschärfen.
Konkret äußert sich diese Angriffsfläche durch Tool-Use und MCP in mehreren Mustern. Sicherheitsforscher warnen vor „Tool Poisoning“ (schädliche Anweisungen, versteckt in der Werkzeug-Beschreibung, die das Modell sieht, der Mensch aber nicht), vor indirekter Prompt-Injection über die von Werkzeugen gelieferten Daten und vor „Rug Pulls“ (ein Werkzeug ändert sein Verhalten nach der Installation). Gegenmittel: nur vertrauenswürdige Server einbinden, Rechte minimal halten (Positivliste statt generischem Shell-Zugriff) und heikle Aktionen bestätigen lassen.
Rechte minimal zu halten zahlt sich nicht nur für die Sicherheit aus, sondern auch für die Verlässlichkeit – und das gilt schon für die Werkzeuge selbst. Der Entwickler-Kommentator Theo (t3.gg) macht darauf aufmerksam, dass mehr Tools einen Agenten oft nicht fähiger, sondern schlechter und teurer machen: Ein Modell zieht alle angebotenen Werkzeuge in Betracht, auch die irrelevanten, und überladene Tool- und Prompt-Definitionen blähen den Kontext auf. Häufig schlägt ein einziges, sauberes Generalwerkzeug – etwa eine Code- oder Bash-Ausführung – viele Spezial-Tools, weil es den Kontext schlank hält. Die Reliability-Schwester zum Merksatz lautet also: so wenige Werkzeuge wie nötig, nicht so viele wie möglich.
METR-Erfolgsmarke
50 % – kein „gelöst“
MerksatzSo einfach wie möglich, so agentisch wie nötig. Und: Jedes Werkzeug ist eine Angriffsfläche – Rechte minimal halten, Quellen prüfen.
