2026-03-24 · Aktualisiert 2026-07-14

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

AI Agent Tool Use im Jahr 2026: MCP, CLI, Fähigkeiten und Ausführung von Code

Teil 3 der Serie „Engineering der Agentic-Stack“

Teil 1 abgedeckte Reasoning-Schleifen, und Teil 2 Gedeckte Speicherung. Dieser Artikel fügt die Aktionsschicht hinzu: Er erklärt, wie ein Agent Werkzeuge freigibt, auswählt und ausführt.

Die Entwicklung der Tooling-Lösungen veränderte sich in den Jahren 2025–2026. MCP verschaffte Anbietern ein gemeinsames Protokoll für externe Dienste, während die Ausführung von Code mittels Agents zeigte, dass eine Model manchmal in der Lage ist, ein kleines Programm effizienter zu erstellen, als wenn sie eine lange Abfolge von JSON-Aufrufen durchführen würde. Anthropic berichtete von einer 98,7-%igen Token-Reduzierung bei einer Kostenanalyse mit Hilfe von Workflow, und die im Paper von CodeAct beschriebenen Ergebnisse wiesen Verbesserungen von bis zu 20 % in ihren Benchmark-Konfigurationen auf. Diese Ergebnisse beziehen sich auf spezifische Aufgaben und Umgebungen und stellen keine allgemeine Vorteilhaftigkeit der Codeausführung dar.

Ich vergleiche in dieser Reihenfolge den Aufruf der JSON-Tool, MCP, Skills, CLI-Tools sowie die Ausführung von Code. Im abschließenden Abschnitt werden die Entwurfsprinzipien einer Agent-Computer-Schnittstelle (ACI) auf dieses Konzept angewandt. Marktanalyst Agent.

TL;DR: Fünf nützliche Schnittstellenmuster decken den Großteil der Agent Tool Use ab. Skills übertragen Anweisungen, CLI-Tools eignen sich für die lokale Entwicklung, MCP verbindet gemeinsam genutzte Dienste, und die Ausführung von Code ermöglicht die Komposition mehrstufiger Aufgaben innerhalb einer Sandbox. Die Verwendung von JSON-Tools bleibt die einfachste Wahl für kleine, atomare Aktionen. Unabhängig vom Protokoll muss die Agent-Computer-Schnittstelle (ACI) sicherstellen, dass Aktionen klar dargestellt werden, Rückmeldungen kompakt sind und Fehler behoben werden können.

Fünf Möglichkeiten, wie AI Agents Werkzeuge einsetzt

In Teil 1, Der Reasoning Loop wählte den nächsten Schritt aus. Teil 2 Es wird der zum Wiederaufnehmen erforderliche Zustand gespeichert. Die Tool-Grenze wandelt diese Entscheidung in eine Aktion um und gibt eine Beobachtung an den Schleifenprozess zurück. Diese fünf Muster führen zu unterschiedlichen Kompromissen hinsichtlich des Token-Kosten, der Flexibilität sowie der Durchsetzungskraft.

1. Aufruf des JSON-Tools: Die Baseline

Das ursprüngliche Muster sieht so aus: Man definiert Tool Schemas als JSON, der LLM generiert strukturierte Funktionsaufrufe, und Ihr Code führt diese aus. Dieses Vorgehen ist weithin bekannt und funktioniert einwandfrei für kleine Toolsets.

# Traditional tool definition — each tool consumes ~550-1,400 tokens (Apideck benchmark)
tools = [
    {
        "name": "get_stock_price",
        "description": "Get the current stock price for a ticker symbol",
        "input_schema": {
            "type": "object",
            "properties": {
                "ticker": {"type": "string", "description": "Stock ticker (e.g., NVDA)"}
            },
            "required": ["ticker"]
        }
    }
]

Mit 5–10 Tools ist das in Ordnung. Das Problem liegt bei der Skalierbarkeit: Jede Tool-Definition verursacht zusätzliche Kosten. 550-1,400 Tokens. Mit 20 Tools verbringen Sie bereits 15–25 Tausend Tokens, noch bevor der Agent überhaupt startet Reasoning.

2. MCP für gemeinsame Integrationen

Das Model Context Protocol stellt das von den meisten Anbietern angenommene Standardprotokoll dar. Im Dezember 2025 spendete Anthropic es der Linux Foundation im Rahmen der Agentic AI Foundation (AAIF), die gemeinsam mit OpenAI und Block gegründet wurde und von Google, Microsoft sowie AWS als Platinmitglieder unterstützt wird. OpenAI fügte in seinen Responses API Unterstützung für MCP hinzu. Derzeit sind es mehr als 10.000 aktive MCP Server sowie mehr als 97 Millionen monatliche SDK Downloads.

MCP eignet sich für die Integration von SaaS-Lösungen verschiedener Anbieter (z. B. Figma, Notion, Salesforce), für Dienste ohne entsprechende CLI-Optionen sowie für Umgebungen, die Orchestration benötigen. Sein Vorteil liegt in einer gemeinsamen Entdeckungs- und Übertragungsschicht. Die Verwaltung hängt weiterhin von der Authentifizierung, Autorisierung, Protokollierung sowie den Deployment-Steuermechanismen des Servers ab.

Die tatsächlichen Produktionsbedingungen sind unübersichtlicher, als die in den Schlagzeilen angegebenen Zahlen vermuten lassen.

Die Sicherheitsoberfläche stellt das erste Problem dar. Die Anfälliges MCP Projekt erfasst 50 Schwachstellen auf MCP-Servern, wovon 13 als kritisch eingestuft werden, und stammt von 32 Sicherheitsforschern. Zu den Angriffsklassen gehören Span Prompt Injection, Fehler bei der Eingabenvalidierung, Authentifizierungsfehler sowie Netzwerksicherheitslücken. Der erste in der Praxis vorkommende bösartige MCP-Server erschien im September 2025: ein Paket mit dem Namen postmark-mcp dass jede ausgehende E-Mail an die Adresse des Angreifers per BCC gesendet wurde, wodurch schätzungsweise 300–500 Organisationen betroffen waren, bevor dies entdeckt wurde.

Tool-Verschmutzung ist die Angriffsklasse, die mir am meisten Sorgen bereitet. Invariant Labs hat dies demonstriert. Dass solche kontaminierten MCP-Tools Daten auslesen können, selbst wenn sie niemals aufgerufen werden. Für den Model reicht bereits das Lesen der Metadaten des Tools aus, um den Angriff auszulösen. MCPTox Benchmarks Bei Tests von LLM Agents an 45 Servern aus der Praxis zeigten sich bei den MCP Erfolgsraten von Angriffen Werte von bis zu 72,8 %.

Token-Kosten stellen das betriebliche Problem dar. Ein Team, das MCP-Server für GitHub, Slack und Sentry betreibt (insgesamt etwa 40 Tools), stellte fest 55,000 Tokens von Schema-Definitionen, die vor dem Eingang einer Anfrage durch den Benutzer eingefügt werden. Ein weiterer gemeldeter Fall 143.000 von 200.000 verfügbaren Einheiten Tokens (72 %) vollständig durch die Definitionen der Tools in Anspruch genommen.

Anthropic gab an, dass durch die Tool Search Tool die Anzahl der benötigten Schemata um 85 % reduziert werden konnte, und bei der Laden von drei bis fünf relevanten Tools für die getesteten Aufgaben sogar um 96 %. Durch selektives Laden wird die Anzahl der zu verarbeitenden Protokolleinstellungen aufrecht erhalten, während gleichzeitig jene Schemata entfernt werden, die der aktuelle Anfrage nicht benötigt werden.

3. Expertise im Skill-Paket – nicht die Ausführung

Ende 2025 führte die Standardisierung der Agent-Fähigkeiten als offenes Format ein (Einführung im Oktober 2025, Veröffentlichung als offener Standard im Dezember 2025). Dieser Unterschied ist von großer Bedeutung: Werkzeuge bieten Funktionalitäten an – also das, was Agents leisten kann – während Fähigkeiten Fachwissen darstellen, nämlich das Wissen von Agents darüber, wie komplexe Aufgaben bewältigt werden können.

Der SKILL.md-Standard definiert eine Fähigkeit als eine Markdown-Datei mit YAML-Frontmatter:

---
name: deploy
description: Deploy the application to production
argument-hint: "[environment]"
user-invocable: true
---
Deploy the application to the $0 environment (default: staging).
Steps:
1. Run the test suite
2. Build the production bundle
3. Deploy using the deploy script
4. Verify the deployment health check

Fähigkeiten nutzen progressive Disclosure. Beim Start werden etwa 100 Tokens an Metadaten geladen; die vollständigen Anweisungen werden erst dann geladen, wenn die Fähigkeit aktiv ist. Im Gegensatz dazu können rund 40 MCP Tools Ressourcen verbrauchen ungefähr 55.000 Tokens vor dem Beginn von Reasoning. Bis März 2026 hatten bereits Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI, Goose, Windsurf sowie Roo Code dieses Format übernommen. Victor Dibia beschreibt diesen Wandel. in Richtung auf kodengestützte Agent Aktionen.

Nutzen Sie diese Fähigkeiten für Domänenwissen, mehrstufige Verfahren sowie wiederkehrende Aufgaben wie Datenbankmigrationen oder Zahlungsanbindungen. Sie eignen sich für Aufgaben, bei denen der Agent Anleitungen dafür benötigt, wie eine vorhandene Funktionalität genutzt werden kann.

4. CLI- und Shell-Tools

CLI-Schnittstellen können im entsprechenden Kontext deutlich kostengünstiger sein, wenn der Model bereits den Befehl kennt. Scalekit berichtete darüber. 4–32× Token-Unterschied zwischen seinen CLI-Schritten und den Pfaden von MCP in insgesamt 75 Ausführungen. Diese Fallstudie bewertet dabei die verwendeten Tools sowie Aufgaben; sie ersetzt jedoch nicht einen direkten Vergleich mit Ihren eigenen Manifesten sowie den Ausgabeergebnissen der Befehle.

Weit verbreitete, gut dokumentierte Befehle wie git, docker, kubectl, gh, curl, und jq Oft reicht bereits ein kurzer Einführungstext zum Schema aus. Seltener genutzte oder interne CLI-Tools benötigen dennoch hilfreiche Dokumentationen, Beispiele sowie eine stabile, maschinenlesbare Ausgabe.

Ugo Enyiohas Leitfaden “CLI-Tools schreiben, die AI Agents tatsächlich genutzt werden wollen” Acht kodifizierte Entwurfsregeln:

1. Structured Output ist zwingend erforderlich — Unterstützung --json
2. Ausgabekodes sind Teil des Kontrollflusses – verwenden Sie unterschiedliche Codes für verschiedene Fehlerarten.
3. Kommandos sollten idempotent sein.
4. Selbst dokumentierend. --help mit realistischen Beispielen
5. Entwurf für Kompositionierbarkeit — --quiet für reine Werte: Unterstützung von Standardeingabe
6. Stellen Sie bereit --dry-run und --yes Flags
7. Unterstützung der Versionsinspektion
8. Verarbeitung der Authentifizierung über Umgebungsvariablen

Die Kompromisse sind real. Die CLI verfügt nicht über die Typsicherheit von MCP, integrierte OAuth Orchestration-Funktionen, Werkzeugerkennung sowie eine Auditspur. Das Muster, zu dem sich die meisten Teams durchringen, ist folgendes: Die CLI wird standardmäßig für die Entwicklung und lokale Verarbeitung genutzt, während MCP zur Integration mit externen Diensten sowie zur Unternehmenssteuerung eingesetzt wird.

5. Ausführung von Code für mehrstufige Aufgaben

Dies ist der bedeutendste Wandel in den Werkzeugen von Agent, den ich feststelle. Anstatt dass der LLM strukturierte JSON-Daten ausgibt, um vorgefertigte Funktionen nacheinander aufzurufen, erstellt der Agent ein vollständiges Python- oder Bash-Skript, das mehrere Tools aufruft, die Ergebnisse mithilfe von Schleifen und Bedingungen verarbeitet und schließlich nur Zusammenfassungen in den Model-Kontext zurückgibt.

Anthropic hat dies formalisiert durch Programmgesteuerte Toolaufrufe (PTC), nun GA in Claude API. Die wissenschaftliche Grundlage ist die CodeAct-Paper (Laut Wang et al., ICML 2024), die an 17 LLMs getestet haben und dabei feststellten, dass Code-Agents im Vergleich zu JSON-Alternativen bis zu 20 % höhere Erfolgsraten bei der Aufgabenerledigung sowie 30 % weniger Schritte erzielten.

Drei Fallstudien von Erstpartnern zeigen auf, wo dieses Muster nützlich sein kann. Verwenden Sie sie als Belege des Anbieters und führen Sie den Vergleich für Ihre eigenen Aufgaben erneut durch.

• Vercel hat ihre d0-Plattform für den Text-zu-SQL-Umwandlungsvorgang neu entwickelt Agent durch das Entfernen von 80 % seiner Tools (von 15 auf 2): ExecuteCommand und ExecuteSQL). Der Erfolgsgrad der Aufgabe stieg von 80 % auf 100 %, die Ausführungszeit verringerte sich um das 3,5-fache und der Verbrauch von Token sank um 40 %. Ihre Formulierung lautet: „Die besten Agents sind vermutlich jene, die über die wenigsten Werkzeuge verfügen.“

• Cloudflare hat „Code Mode“ entwickelt, durch das Zulassen von Agents, TypeScript zu verwenden, um auf ihre API zuzugreifen, anstatt Tool Schemas zu definieren – wodurch die Kontextbelastung verringert wird. Ihre Reasoning lauten: „LLMs enthalten in ihrem Trainingsdatensatz eine enorme Menge an echtem TypeScript, doch nur eine begrenzte Anzahl künstlich erzeugter Beispiele für Tool Calls.“

Hier ist das Muster aus Die PTC-Dokumentation von Anthropic. Herkömmliche Tools zur Kostenanalyse erfordern mehr als 20 getrennte Aufrufe von Inference – einen pro Teammitglied – wobei alle Zwischendaten über den Kontext übertragen werden. Ein Workflow, der bei direktem Toolaufruf etwa 150.000 Tokens verbrauchte, wurde für etwa 2.000 Tokens neu implementiert, was einer 98,7‑Prozentigen Reduzierung entspricht. Durch die Ausführung von Code erstellt der Agent lediglich ein einziges Skript:

# Agent generates this code, executes in sandbox
import json
members = get_team_members("engineering")
over_budget = []
for m in members:
    expenses = get_expenses(m["id"], "Q3")
    total = sum(e["amount"] for e in expenses)
    if total > 5000:
        custom = get_custom_budget(m["id"])
        limit = custom["limit"] if custom else 5000
        if total > limit:
            over_budget.append({"name": m["name"], "spent": total, "limit": limit})
# Only this final summary returns to the LLM context
print(json.dumps(over_budget))

Der LLM zeigt lediglich die endgültige JSON-Zusammenfassung an, nicht die Tausende von Ausgabenpositionen, die im Sandbox verarbeitet werden. Dadurch wird die Token-Effizienz erhöht, da eine natürliche Komposierbarkeit gegeben ist (Schleifen und Bedingungen entstehen ohne zusätzliche Aufwand) sowie eine echte Fehlerbehandlung möglich ist.try/except Anstelle von natürlicher Sprache Reasoning bezüglich Fehlermeldungen sowie der Privatsphäre (denn sensible Daten bleiben im Sandbox) verbessern sich alle Aspekte gleichzeitig.

Wenn der Aufruf des JSON-Tools weiterhin sinnvoll ist: bei einzelnen atomaren Operationen, Umgebungen ohne Sandbox-Infrastruktur, kleineren Models mit schwacher Codegenerierung oder bei Prüfanforderungen, bei denen jeder einzelne Toolaufruf protokolliert werden muss.

Vergleichstabelle zur Aufrufung von AI Agent-Tools

Unter Kompositionstiefe versteht man hier, wie leicht mehrere Operationen zu einer größeren Workflow aufgereiht werden können. Eine niedrige Kompositionstiefe bedeutet, dass jede Tool Call in der Regel einen weiteren Model-Wechsel erfordert; eine hohe Kompositionstiefe hingegen ermöglicht es der Schnittstelle, Zwischenergebnisse über Pipes, Variablen oder prozedurale Schritte weiterzugeben. Die Token- sowie die Zellen zur Erfolgsprüfung der Aufgaben fassen die genannten Beispiele zusammen – und nicht einen einzigen, zentral gesteuerten Benchmark für alle fünf Spalten.

Die Agent-Computer-Schnittstelle (ACI) für AI Agent-Tools

Der Begriff „Agent-Computer Interface“ (ACI) wurde von John Yang, Carlos E. Jimenez und ihren Kollegen an der Princeton University geprägt. SWE-Paper zu Agent (NeurIPS 2024). Die Idee ist einfach: Genau wie Menschen von gut gestalteten Benutzeroberflächen (HCI) profitieren, sind LM Agents „eine neue Kategorie von Endnutzern mit eigenen Anforderungen und Fähigkeiten, die von speziell entwickelten Benutzeroberflächen Vorteile ziehen würden.“

Der Ablationsergebnisse Ich habe dies gesichert. Der SWE-Agent mit seiner vollständigen ACI-Leistung erzielte auf dem SWE-bench Lite-Wert von 18,0 %, während nur eine Standard-Linux-Shell lediglich 7,3 % erreichte – das entspricht einer Verbesserung von 10,7 Prozentpunkten allein durch das Interface-Design. Die durchgeführte Guardrail-Prüfung trug allein bereits 3 Prozentpunkte bei: Bei 51,7 % der Änderungen an Agent wurde zumindest ein Fehler bereits vor der Weiterverbreitung vom Linter erkannt.

Anthropic hat ACI als grundlegendes Konzept in ihrer „Effektive Agents-Systeme entwickeln“ Leiten sie dies als eines von drei Kernprinzipien an: „Entwickeln Sie Ihre Agent-Computer-Schnittstelle sorgfältig durch umfassende Dokumentation der Tools sowie ausführliche Tests.“ Ihre praktische Anleitung lautet: „Eine Faustregel ist, sich darüber im Klaren zu sein, wie viel Aufwand in mensch-Computer-Schnittstellen gesteckt wird, und genauso viel Mühe in die Erstellung guter Agent-Computer-Schnittstellen zu investieren.“

Vier Prinzipien des ACI in der Praxis

1. Aktionen sollten einfach und leicht verständlich sein. Der häufigste Fehler besteht darin, die API-Endpunkte eins-zu-eins zu umhüllen. Anstelle davon list_users, list_events, create_event, implementieren schedule_event dieser in einem einzigen Aufruf Verfügbarkeiten ermittelt und Termine festlegt. Anstelle davon read_logs, implementieren search_logs der ausschließlich die relevanten Zeilen zusammen mit ihrem Kontext zurückgibt.

2. Aktionen sollten kompakt und effizient sein. Konsolidieren Sie wichtige Operationen in so wenigen Aktionen wie möglich. In der Marktanalyst Agent, Ich integriere den Preisabruf mit grundlegenden Metriken zu einem einzigen get_stock_snapshot ein Tool, anstatt mehrere getrennte Aufrufe für Preis, Volumen, Marktkapitalisierung und Kurs-Gewinn-Verhältnis erforderlich zu haben.

3. Die Umgebungsfeedbacks sollten informativ, aber prägnant sein. Vermeiden Sie die Rückgabe von rohem HTML oder vollständigen API-Datenpaketen. Ersetzen Sie kryptische IDs durch semantisch aussagekräftige Namen. Anthropics Testverfahren zeigte, dass das Hinzufügen eines response_format Eine Enum, die es Agents ermöglicht, prägnante (~72 Tokens) oder ausführliche (~206 Tokens) Antworten anzufragen – was zu einem dreifach höheren Token-Kostenunterschied führt – hat die Leistung in der Praxis deutlich verbessert.

4. Guardrails sollte die Ausbreitung von Fehlern mindern. Die automatische Fehlererkennung unterstützt Agents dabei, Fehler schnell zu erkennen und zu beheben. In SWE-Agent, Ein benutzerdefinierter Dateieditor mit integriertem Linting lehnt Syntaxfehler automatisch ab und erkennt somit 51,7 % der Agent-Bearbeitungsfehler, bevor diese sich weiter verschlimmern können. Ich wende dasselbe Prinzip im Market Analyst Agent an, indem ich die Argumente der Tools vor der Ausführung mithilfe von Pydantic-Schemata überprüfe:

from pydantic import BaseModel, Field, field_validator

class StockQuery(BaseModel):
    """Validated input for stock queries.

    Pydantic catches malformed tickers before the API call,
    preventing error propagation through the reasoning loop.
    """
    ticker: str = Field(description="Stock ticker symbol (e.g., NVDA)")
    period: str = Field(default="1mo", description="Time period: 1d, 5d, 1mo, 3mo, 1y")

    @field_validator("ticker")
    @classmethod
    def validate_ticker(cls, v: str) -> str:
        v = v.upper().strip()
        if not v.isalpha() or len(v) > 5:
            raise ValueError(f"Invalid ticker format: {v}")
        return v

    @field_validator("period")
    @classmethod
    def validate_period(cls, v: str) -> str:
        valid = {"1d", "5d", "1mo", "3mo", "6mo", "1y", "5y"}
        if v not in valid:
            raise ValueError(f"Invalid period: {v}. Must be one of {valid}")
        return v

AI Agent funktionierende Designmuster für Tools

Anthropics „Effektive Tools für Agents zu entwickeln“ Guide Frames stellt Tools als „eine neue Art von Software dar, die einen Vertrag zwischen deterministischen Systemen und nicht-deterministischen Agents widerspiegelt.“ Im Folgenden sind die Muster aufgeführt, die sich aus der Praxiserfahrung herauskristallisiert haben.

Behandeln Sie Toolbeschreibungen als Prompt-Entwicklungsaufgaben.

Die Beschreibungen sollten ausführlich sein. Ein AI-Agent ist ein autonomes System, das in der Lage ist, Aufgaben unabhängig von menschlichem Eingreifen zu bewältigen. In der Praxis werden solche Agenten häufig zur Automatisierung komplexer Workflows innerhalb von Software-Systemen eingesetzt. Durch die Integration von Machine-Learning-Algorithmen können sie kontinuierlich aus Erfahrungsdaten lernen und ihre Entscheidungsfindung optimieren. Zudem ermöglichen sie eine effizientere Abstraktion von Geschäftslogik, wodurch die Entwicklung und Wartung von Anwendungen, Erörterung dazu, wann das Tool eingesetzt werden sollte, welche Parameter obligatorisch und welche optional sind, das Ausgabeformat sowie Randfälle. Namensraumierung mittels Präfixenasana_search, jira_search) hat „nicht-triviale Auswirkungen“ auf die Genauigkeit der Werkzeugauswahl. In den Experimenten von Anthropic übertrafen die für Claude optimierten Werkzeudescriptions die von Experten verfassten Versionen bei der Bewertung Benchmarks.

# Bad: vague, no context for when to use
tools = [{
    "name": "search",
    "description": "Search for items",
}]

# Good: specific, with input examples and edge cases
tools = [{
    "name": "stock_search_news",
    "description": (
        "Search for recent news articles about a specific stock or company. "
        "Use this tool when the user asks about recent events, earnings, "
        "announcements, or market-moving news for a specific ticker. "
        "Returns up to 10 articles sorted by relevance. "
        "For broad market news (not ticker-specific), use market_overview instead."
    ),
    "input_schema": {
        "type": "object",
        "properties": {
            "query": {
                "type": "string",
                "description": "Search query. Examples: 'NVDA earnings Q3 2025', 'Tesla delivery numbers'"
            },
            "max_results": {
                "type": "integer",
                "description": "Max articles to return (1-10, default 5)",
                "default": 5
            }
        },
        "required": ["query"]
    }
}]

Interne Tests wurde gezeigt, dass die Eingabeproben (input_examples Dieser AI-Agent hat die Genauigkeit bei der Verarbeitung komplexer Parameter erheblich verbessert.

Liefern Sie hochwertigen, maschinenlesbaren Ausgangsdaten.

Vermeiden Sie Identifikatoren niedriger Ebene.uuid, mime_type). Ersetzen Sie verschlüsselte IDs durch semantische Namen. Strukturieren Sie die Antwort so, dass der Agent darauf aufbauen kann, ohne Boilerplate parsen zu müssen:

# Bad: raw API response dumped to agent
def get_stock_price(ticker: str) -> dict:
    response = api.get(f"/v1/quotes/{ticker}")
    return response.json()  # 500+ tokens of nested JSON

# Good: high-signal summary the agent can immediately reason about
def get_stock_price(ticker: str) -> dict:
    data = api.get(f"/v1/quotes/{ticker}").json()
    return {
        "ticker": ticker,
        "price": data["regularMarketPrice"],
        "change_pct": round(data["regularMarketChangePercent"], 2),
        "volume": data["regularMarketVolume"],
        "market_cap_b": round(data["marketCap"] / 1e9, 1),
        "pe_ratio": data.get("trailingPE"),
        "summary": f"{ticker} at ${data['regularMarketPrice']:.2f} "
                   f"({'up' if data['regularMarketChangePercent'] > 0 else 'down'} "
                   f"{abs(data['regularMarketChangePercent']):.1f}%)"
    }

Fehler zurückgeben, auf die der Loop reagieren kann

Verwenden Sie vier getrennte Mechanismen, da diese unterschiedliche Fehlerkategorien bewältigen:

1. Wiederholter Versuch mit exponentiellem Backoff bei vorübergehenden Fehlern
2. Model-Fallback-Ketten im Falle von Ausfällen des Anbieters
3. Klassifizierung der Fehler Routing – bei vorübergehenden Fehlern wird wiederholt versucht, bei LLM-wiederherstellbaren Fehlern wird der Status zusammen mit Kontext an den Agent zurückgesendet, während fehlerbehaftete Vorgänge, die menschliches Eingreifen erfordern, weiter eskaliert werden
4. Checkpoint-Wiederherstellung nach einem Absturz

Der zitierte Anthropic-Leitfaden unterstützt eine klare Erfassung von Tool-Fehlern sowie ein auf Bewertungen basierendes Tool-Design. Er legt keine universelle Vorgabe für die Reduzierung der Ausfallrate fest; daher sollten Sie die Wiederherstellungsrate, die Anzahl der Wiederholungsversuche sowie das Eskalationsverhalten in Ihrem eigenen Aufgabensatz selbst messen.

from tenacity import retry, stop_after_attempt, wait_exponential

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=2, max=10),
)
def call_stock_api(ticker: str) -> dict:
    """Fetch stock data with automatic retry on transient failures.

    Layer 1: Exponential backoff handles rate limits and network blips.
    If all retries fail, the error propagates to the agent with
    enough context to decide whether to try a different approach.
    """
    response = httpx.get(
        f"https://api.example.com/v1/quotes/{ticker}",
        timeout=10.0,
    )
    response.raise_for_status()
    return response.json()

Anwendung der Muster auf den Marktanalysten Agent

Der Marktanalyst Agent von Teil 1 macht die Wirkung der Schnittstelle sichtbar.

Konsolidierung von Tools

Der Artikel Teil 1 zeigt die vereinfachte Oberfläche mit fünf Werkzeugen nach dieser Refaktorierung. Vor dieser Aufbereitung verfügte das ursprüngliche Design über zehn oder mehr Werkzeuge: get_stock_price, get_company_metrics, get_market_cap, get_pe_ratio, get_volumeusw. Jeder davon war eine schmale Umhüllung um einen einzelnen API-Endpunkt. Der Agent musste für jede Anfrage entscheiden, welche Kombination aufgerufen werden sollte.

Ich habe diese in 5 hochrangige Tools zusammengefasst, wobei ich dem ACI-Prinzip kompakter, effizienter Aktionen folgte:

Dadurch wurde die Overhead von Tool Schema erheblich reduziert und die Auswahl der Werkzeuge durch den Agent zuverlässiger, da es weniger mehrdeutige Entscheidungsmöglichkeiten gibt.

Structured Outputs für Tool Results

Jedes Tool im Market Analyst Agent gibt eine durch Pydantic validierte Antwort zurück. Dadurch wird das ACI Guardrails-Prinzip bereits an der Grenze zum Tool angewendet:

class StockSnapshot(BaseModel):
    """Structured tool response — the agent never sees raw API noise."""
    ticker: str
    price: float
    change_pct: float
    volume: int
    market_cap_b: float
    pe_ratio: float | None
    summary: str  # Human-readable one-liner for direct use in reports

class NewsResult(BaseModel):
    """Each news item is pre-processed for agent consumption."""
    headline: str
    source: str
    date: str
    relevance_score: float  # Pre-ranked so the agent doesn't waste tokens sorting
    key_points: list[str]  # Extracted by the tool, not the agent

Der summary Das Feld ist das Wichtigste. Es stellt dem Agent einen sofort einsetzbaren String zur Verfügung, der ohne weitere Verarbeitung direkt in einen Bericht übernommen werden kann. key_points in NewsResult Sie werden serverseitig extrahiert, wodurch Agent vor der aufwändigen Inference Tokens-basierten Verarbeitung der Artikelinhalte geschont wird.

Abwägungen und zu berücksichtigende Aspekte

Abgesehen von den oben genannten modalspezifischen Einschränkungen gibt es noch einige grundsätzliche Aspekte, die die Entscheidungsfindung beeinflussen:

• Die Betriebskosten variieren je nach Dimension. Die Ausführung von Code spart Tokens, verursacht aber zusätzliche Kosten für den Latency Cold-Start sowie Sandbox. MCP verkürzt die Entwicklungszeit bei SaaS-Integrationen, führt jedoch zu höheren Server-Deployment-Kosten. Die CLI lässt sich kostenlos starten, ist aber in großem Umfang schwieriger zu verwalten. Optimieren Sie entsprechend Ihren tatsächlichen Bottleneck-Anforderungen – sei es hinsichtlich der Token-Kosten, der Latency oder der operativen Komplexität.

• Die Fähigkeiten des Teams sind von entscheidender Bedeutung. Bei der Ausführung von Code wird vorausgesetzt, dass Ihre Agents (sowie die dahinterstehenden Models) zuverlässigen Python- oder TypeScript-Code erzeugen können. Für die CLI ist eine Vertrautheit mit den Konventionen von Unix erforderlich. MCP setzt hingegen ein Verständnis von Übertragungsprotokollen sowie OAuth-Workflows voraus. Passen Sie die jeweilige Arbeitsmethode den Stärken Ihres Teams an.

• Die Konsolidierung von Tools kann zu weit getrieben werden. Wenn ein Tool unzusammenhängende Modi und Argumente ansammelt, steht der Agent innerhalb des Schemas vor einem anderen Auswahlproblem. Nutzen Sie Bewertungen zur Toolauswahl sowie zur Erfolgsquote der Aufgaben, um die geeignete Lösung für Ihre Arbeitslast zu finden.

• Die Fähigkeiten basieren auf Prompt und sind nicht verbindlich vorgeschrieben. Eine Fähigkeit stellt lediglich Anweisungen dar, denen der Agent folgen sollte, anstatt dass er dies Guardrails unbedingt tun muss. Bei kritischen Workflows-Szenarien sollten Fähigkeiten mit deterministischer Validierung kombiniert werden.

• Die Anforderungen an Audits bestimmen die Wahl des geeigneten Tools. Falls Sie eine vollständige Protokollierung jeder Aufrufaktion eines Tools sowie deren Ergebnis benötigen, liefern die Tools MCP und JSON standardmäßig strukturierte Auditrückverfolgungen. Die Ausführung von Code erzeugt zwar ein Skript samt dessen Ausgabe, was nützlich ist, doch diese Darstellung lässt sich für Berichte zur Konformitätsprüfung schwieriger in einzelne Aktionen aufteilen.

Werkzeugauswahl in größeren Skalen

Drei Richtungen sind es wert, verfolgt zu werden.

Der erste Ansatz ist ein Tool RAG zur Skalierung. Wenn die Toolsets auf Hunderte oder Tausende anwachsen, sinkt die Genauigkeit einer naiven Toolauswahl auf 13,62 %. RAG-MCP-bezogener Artikel Es wurde gezeigt, dass die Anwendung von Retrieval-ergänzter Generierung bei der Werkzeugauswahl – durch das Indizieren von Werkzeudescriptions in einem Vector Database sowie das Abrufen ausschließlich relevanter Werkzeuge pro Abfrage – eine Genauigkeit von 43,13 % erzielt, was einer Verbesserung um das 3,2-fache entspricht. Gleichzeitig wird dadurch der Prompt Tokens um etwa 50 % reduziert.

Der zweite Ansatz besteht darin, Agents eigene Tools zu entwickeln. LATM Framework (LLMs Als Entwickler von Tools) haben sie ein zweistufiges Paradigma etabliert, bei dem eine leistungsstarke LLM wiederverwendbare Python-Funktionen erstellt und eine leichtgewichtige LLM diese nutzt. ToolMaker (ACL 2025) wandelt GitHub-Repositorien autonom in mit LLM kompatible Tools um – mit einer Erfolgsrate von 80 %. Der Forschungsfokus verschiebt sich zunehmend von Tool Use hin zur Erstellung solcher Tools und weiterhin zur Verwaltung von Tool-Bibliotheken.

Der dritte Ansatz ist der dualen-Protokoll-Stack aus A2A und MCP. Das Agent2Agent Protocol von Google (A2A) löst die Probleme, mit denen sich MCP auseinandersetzen muss, nicht – nämlich die Kommunikation zwischen Agent und Agent. MCP kümmert sich um die Integration von Agent in Tools, während A2A für die Entdeckung, Verhandlung sowie Delegation von Aufgaben zwischen Agent und Agent zuständig ist. Die zusammenfassende Formel lautet daher: Mit Ihrem Framework entwickeln, mit MCP ausstatten und über A2A kommunizieren.

Wichtige Erkenntnisse

1. Wählen Sie die geeignete Schnittstelle aus den verfügbaren Optionen aus: JSON für kleine, typisierte Operationen, MCP für gemeinsam genutzte Dienste, „Skills“ für Prozeduren, die CLI für etablierte Befehle sowie gesandboxter Code für lokale Kompositionen.
2. Behalten Sie die mit dem Ergebnis verbundenen Benchmark-Bedingungen bei. Tools wie CodeAct, Anthropic, Vercel, Cloudflare, Apideck und Scalekit bewerten unterschiedliche Models-Aspekte wie Aufgaben, Werkzeuge und Infrastrukturen.
3. Die Qualität von ACI bleibt auch bei Protokolländerungen erhalten. Klar formulierte Aktionen, prägnante Rückmeldungen, Validierungen sowie nützliche Fehlermeldungen unterstützen alle Anwendungsmöglichkeiten.
4. Konsolidieren Sie überlappende Werkzeuge nur dann, wenn Bewertungen zeigen, dass eine reduzierte Anzahl an Optionen die Auswahl oder den Erfolg der Aufgabe verbessert.
5. Die Sicherheit folgt der Ausführungskraft. Shell- und Code-Schnittstellen erfordern eine Sandbox-Umgebung; MCP benötigt eingeschränkte Identitätsverwaltung sowie Serverrichtlinien; „Skills“ bleiben weiterhin lediglich Anweisungen ohne durchsetzende Wirkung.

Die nächste Schicht ist die Policy

Teil 4, AI Agent Sicherheit im Jahr 2026, Es wird eine Richtlinienprüfung zwischen dem vorgeschlagenen Tool Call und der Ausführung eingefügt. In Teil 5 werden das Tool sowie sein Sandbox in einen wiederherstellbaren Runtime eingebettet. Teil 6 kehrt schließlich von der Seite des Harness zur Benutzeroberfläche zurück: Dabei zeigen Traces, Evaluators, Wiederholungsregeln sowie Akzeptanzprüfungen auf, wie Tool-Rückmeldungen zu einem strukturierten Verbesserungslauf führen.

Referenzen

Arbeiten / Publikationen

• Ausführbare Code-Aktionen erzielen bessere Ergebnisse mit LLM Agents (CodeAct). — Wang et al., ICML 2024 — Auf Basis von Code durchgeführte Aktionen erzielen eine um 20 % höhere Erfolgsrate bei der Ausführung von Aufgaben im Vergleich zu JSON SWE-Agent: Agent – Computer-Schnittstellen ermöglichen die automatisierte Softwareentwicklung — Yang, Jimenez et al., NeurIPS 2024 — Designprinzipien für ACI sowie Bewertung mittels SWE-bench (18,0 % gegenüber 7,3 %, ein Unterschied von 10,7 Prozentpunkten durch das Interface-Design)
• RAG-MCP: Verringerung des Prompt-Bloats bei der Auswahl von LLM-Tools — Werkzeug RAG zur Steigerung der Auswahlgenauigkeit von 13,62 % auf 43,13 % LLMs als Tool-Entwickler (LATM) — Cai et al., 2023 — Zweiphasen-Paradigma für die Erstellung von Agent-Tools ToolMaker: LLM Agents Erstellung von Agent Werkzeugen — Wolflein et al., ACL 2025 — 80-Prozentige Erfolgsrate bei der Umwandlung von Repositories in Tools
• MCPTox: Ein umfassendes MCP-Toxizitäts-Benchmark-Modell — 72,8 % Erfolgsrate bei Angriffen auf 20 LLM Agents sowie 45 MCP Servern

Anthropic-Engineering

• Fortgeschrittene Tool Use / Programmgesteuerte Aufrufe von Tools — Werkzeugsuche (85 % Reduktion des Schemas), PTC sowie Beispiele für Tool Use Ausführung von Code mit MCP — 98,7 % Tokenige Reduzierung (von 150 K auf 2 K Tokens) mithilfe eines auf Code basierenden Tools Orchestration
• Effektive Werkzeuge für Agents entwickeln — Ingenieurwesen der Tool-Beschreibung; Eingabemuster steigern die Genauigkeit; Response_format-Enum (72 gegenüber 206 Tokens) Effektive Agents entwickeln — ACI als grundlegendes Designprinzip

Branchenbeispiele

• Vercel: Wir haben 80 Prozent der Tools für unsere Agent entfernt. — Von 15 auf 2 Werkzeuge, Erfolgsrate von 80 % bis 100 %, 3,5‑mal schnellere Ausführung, 40 % weniger Tokens Cloudflare: Code-Modus — Von TypeScript gesteuerte API-Aufrufe, die Tool Schemas ersetzen
• Apideck: Der MCP-Server, der Ihre Context Window aufbraucht — 550–1.400 Tokens/Tool, 55 K Tokens für etwa 40 MCP Tools, verbrauchte Kontextmenge: 143 K/200 K
• Scalekit: MCP im Vergleich zur CLI Token Benchmark — 4-32x Token Overhead für MCP im Vergleich zur CLI bei 75 Benchmark Ausführungen

Sicherheit

• Anfälliges MCP Projekt — 50 erfasste Schwachstellen, davon 13 kritisch, von 32 Forschern AuthZed: Zeitverlauf der MCP-Vorfälle — 9 bedeutende MCP-Sicherheitsvorfälle (April–Oktober 2025)
• Invariant Labs: MCP Angriffe durch Vergiftung von Tools — Tool-Verschmutzung, „Rug Pulls“ sowie Cross-Origin-Eskalation Pivot Point Security: Sicherheitsanalyse von MCP — 43 % Kommando-Injektionen, 43 % Fehler bei der OAuth-Authentifizierung

CLI-Design

• Die Entwicklung von CLI-Tools, die AI Agents tatsächlich genutzt werden möchten — Ugo Enyioha — Acht Gestaltungsregeln für Agent-freundliche CLI‑Tools

Demo-Projekt

• Marktanalyst Agent — Vollständige Implementierung mit Konsolidierung der Tools sowie ACI-Mustern

Der vollständige Code des Market Analyst Agent, einschließlich der in diesem Beitrag beschriebenen Tool-Designs, ist verfügbar unter GitHub._

Reihe: Entwicklung der Agentic-Stack-Struktur

• Teil 1: AI Agent Reasoning Schleifen im Jahr 2026 — ReAct, ReWOO sowie Plan-and-Execute Teil 2: AI Agent Memory Architektur im Jahr 2026 — Checkpoints, Vector Stores sowie Dokumentenmemorie
• Teil 3: AI Agent Tool Use im Jahr 2026 (dieser Beitrag)
• Teil 4: AI Agent Sicherheit im Jahr 2026 — Guardrails, Berechtigungen, Sandboxes, HITL sowie MCP-Bereichsdefinition
• Teil 5: Langlaufende AI Agent Runtime im Jahr 2026 — Sessions, Sandboxes, Checkpoints sowie Steuermechanismen und Deployment-Formen
• Teil 6: Harness Engineering für AI Agents (folgt bald) — Akzeptanzprüfungen, Traces, Wiederholungsversuche, Übergaben sowie der Zyklus innerhalb des Model