Tool Use für AI Agents: MCP, CLI, Skills und Code Execution

Viacheslav Dubrov

2026-03-24 · Aktualisiert 2026-08-01 · 20 Min. · KI-Agenten

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Teil 1 behandelte Reasoning Loops, Teil 2 den Speicher. Dieser Artikel ergänzt die Handlungsebene: wie ein Agent Tools bereitstellt, auswählt und ausführt. Die Memory entscheidet, was der Agent zu Beginn eines Turns weiß; diese Ebene entscheidet, was er damit tun kann. Teil 4 behandelt die Prüfung, die entscheidet, ob ein benannter Aufruf überhaupt ausgeführt wird, und Teil 6 das Harness, das sowohl den Aufruf als auch die Prüfung ausführt. In diesem Artikel bezeichnet Harness das Steuerungsprogramm, das jeden Prompt zusammenstellt, die akzeptierten Tool Calls ausführt und entscheidet, wann die Aufgabe abgeschlossen ist – also alles rund um das Model, was gewöhnlicher Code ist, den du schreibst.

Die Tooling-Landschaft hat sich 2025–2026 verändert. MCP, das Model Context Protocol, gab Anbietern eine gemeinsame Möglichkeit, externe Services bereitzustellen. Code-executing Agents zeigten, dass ein Model manchmal ein kleines Programm effizienter zusammenstellen kann, als eine lange Folge von JSON-Aufrufen auszugeben. Anthropic berichtete für einen Google-Drive-to-Salesforce-Workflow von einer Token-Reduktion um 98,7 %, und das CodeAct-Paper meldete in seinem Benchmark-Setup Verbesserungen von bis zu 20 %. Diese Ergebnisse beziehen sich auf die jeweiligen Tasks und Harnesses, nicht auf einen universellen Vorteil von Code Execution.

Ich vergleiche JSON Tool Calling, MCP, Skills, CLI Tools und Code Execution in dieser Reihenfolge. Ein späterer Abschnitt wendet Designprinzipien für Agent-Computer Interfaces (ACI) auf den Market Analyst Agent an, einen kleinen LangGraph-Research-Agenten, den ich für Teil 1 gebaut habe und der Marktdaten abruft und einen Analystenbericht verfasst.

Eine kurze Entscheidungshilfe für Interfaces findest du unter AI Agent Tool Interfaces.

Fünf Möglichkeiten, wie AI Agents Tools verwenden

In Teil 1 wählte der Reasoning Loop den nächsten Schritt. Teil 2 speicherte den Zustand, der zum Fortsetzen erforderlich war. Die Tool-Grenze liegt zwischen beiden: Sie validiert den vom Loop vorgeschlagenen Schritt, leitet den Call anschließend zur Ausführung weiter und gibt das Ergebnis an den Loop zurück. Diese fünf Muster gehen unterschiedliche Kompromisse bei Token-Kosten, Flexibilität und Durchsetzung ein.

1. JSON Tool Calling: die Grundlage

Das ursprüngliche Muster: Du definierst Tool Schemas als JSON, das LLM gibt strukturierte Function Calls aus und dein Code führt sie aus. Das Muster ist gut verstanden und funktioniert für kleine Toolsets problemlos.

# 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"]
        }
    }
]

Bei 5–10 Tools ist der Overhead akzeptabel. Das Problem ist die Skalierung: Jede Tool-Definition kostet 550–1.400 Tokens. Bei 20 Tools verbrauchst du 11–28K Tokens, bevor der Agent überhaupt mit dem Reasoning beginnt.

2. MCP für gemeinsame Integrationen

MCP ist der Standard, auf den sich die meisten Anbieter geeinigt haben. Ein MCP-Server ist ein Prozess, der eine Liste von Tools über ein festgelegtes Wire Protocol bereitstellt — stdio für einen lokalen Prozess, HTTP für einen Remote-Prozess. Dein Agent führt einen MCP-Client aus, der eine Verbindung herstellt, den Server nach seinen Tools fragt und die Calls des Models an ihn weiterleitet. Dadurch funktioniert derselbe Server mit jedem Client, der das Protokoll unterstützt. Anthropic hat das Protokoll im Dezember 2025 unter der Agentic AI Foundation, die das Unternehmen gemeinsam mit OpenAI und Block gegründet hat, an die Linux Foundation übergeben. Google, Microsoft und AWS unterstützen die Foundation als Platinum Members. OpenAI hat MCP-Unterstützung in seiner Responses API ergänzt. Zum Zeitpunkt von Anthropics Ankündigung der Übergabe im Dezember 2025 umfasste das Ökosystem mehr als 10.000 aktive öffentliche MCP-Server und mehr als 97 Millionen monatliche SDK-Downloads über die Python- und TypeScript-SDKs hinweg.

MCP eignet sich für SaaS-Integrationen über Anbietergrenzen hinweg (Figma, Notion, Salesforce), für Services ohne CLI-Äquivalente und für Umgebungen, die OAuth-Orchestration benötigen. Sein Wert liegt in einer gemeinsamen Discovery- und Transport-Schicht. Die Governance hängt jedoch weiterhin von den Authentifizierungs-, Autorisierungs-, Logging- und Deployment-Kontrollen des Servers ab.

Die Produktionsrealität ist weniger erfreulich, als die Schlagzeilenzahlen vermuten lassen.

Die Security-Surface ist das erste Problem. Das Vulnerable MCP Project erfasst 50 Schwachstellen in MCP-Servern, davon 13 mit der Bewertung Critical, gemeldet von 32 Security-Researchern. Die Angriffsklassen reichen von Prompt Injection und Fehlern bei der Input-Validierung über Authentifizierungslücken bis hin zu Schwachstellen in der Netzwerksicherheit. Der erste tatsächlich bösartige MCP-Server tauchte im September 2025 auf: ein Paket namens postmark-mcp, das jede ausgehende E-Mail per BCC an die Adresse eines Angreifers weiterleitete.

Tool Poisoning ist die Angriffsklasse, die mir am meisten Sorgen bereitet. Invariant Labs demonstrierte, dass vergiftete MCP-Tools Daten exfiltrieren können, selbst wenn sie nie aufgerufen werden. Es genügt, dass das Model die Metadaten des Tools liest, um den Angriff auszulösen. Die MCPTox-Benchmarks, in denen 20 LLM Agents gegen 45 reale MCP-Server getestet wurden, ermittelten Erfolgsraten der Angriffe von bis zu 72,8 %.

Der Token-Overhead ist das operative Problem. Ein Team, das MCP-Server für GitHub, Slack und Sentry betrieb (insgesamt etwa 40 Tools), stellte fest, dass 55.000 Tokens an Tool-Schema-Definitionen injiziert wurden, bevor ein User überhaupt eine Frage stellte. Ein anderes Team berichtete, dass allein die Tool-Definitionen 143.000 von 200.000 verfügbaren Tokens (72 %) verbrauchten.

Der Bericht von Anthropic zu seinem Tool Search Tool maß eine Reduktion des gesamten Context-Verbrauchs um 85 % — von ungefähr 77.000 Tokens vor Beginn der Arbeit auf 8.700 — bei etwa 72.000 Tokens an Tool-Definitionen im traditionellen Setup. Das Tool lädt nur die drei bis fünf Tools, die ein Request benötigt, fügt jedoch vor dem Aufruf einen Discovery-Schritt hinzu. Für kleine, kompakte Toolsets, deren Tools in jeder Session häufig verwendet werden, ist es daher weniger nützlich.

3. Skills bündeln Expertise, nicht Ausführung

Agent Skills sind ein offenes Format zum Bündeln von Anweisungen und unterstützenden Dateien. Tools stellen Fähigkeiten bereit (was Agents tun können), während Skills Expertise bereitstellen (was Agents darüber wissen, wie komplexe Aufgaben auszuführen sind).

Das SKILL.md-Format definiert einen Skill als Markdown-Datei mit YAML-Frontmatter. Der offene Standard erfordert lediglich name und description; das folgende Beispiel verwendet außerdem zwei Claude-Code-Erweiterungen, argument-hint und user-invocable, sowie den positionsbasierten Argument-Platzhalter $0:

---
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

Skills verwenden Progressive Disclosure. Beim Start werden etwa 100 Tokens Metadaten geladen; die vollständigen Anweisungen werden erst geladen, wenn der Skill aktiv ist. Zum Vergleich: Rund 40 MCP-Tools können vor Beginn des Reasoning etwa 55.000 Tokens verbrauchen.

Verwende Skills für Domänenwissen, mehrstufige Verfahren und wiederkehrende Aufgaben wie Datenbankmigrationen oder Payment-Integrationen. Sie eignen sich für Aufgaben, bei denen der Agent Anweisungen dazu benötigt, wie eine vorhandene Fähigkeit eingesetzt wird.

4. CLI- und Shell-Tools

CLI-Schnittstellen können beim Context deutlich günstiger sein, wenn das Model den Befehl bereits kennt. Scalekit berichtete über einen 4- bis 32-fachen Token-Unterschied zwischen seinen CLI- und MCP-Pfaden bei 75 Durchläufen. Diese Case Study misst die eigenen Tools und Aufgaben; sie ersetzt keinen Vergleich mit den eigenen Tool-Definitionen und der eigenen Command-Ausgabe.

Weitgehend dokumentierte Befehle wie git, docker, kubectl, gh, curl und jq benötigen oft nur wenig einführenden Schema-Text. Weniger verbreitete oder interne CLIs brauchen weiterhin auffindbare Hilfe, Beispiele und eine stabile maschinenlesbare Ausgabe.

Ugo Enyiohas Leitfaden “Writing CLI Tools That AI Agents Actually Want to Use” fasst acht Designregeln zusammen:

1. Structured Output ist obligatorisch — unterstütze --json
2. Exit-Codes sind Control Flow — verwende unterschiedliche Codes für verschiedene Fehlertypen
3. Befehle sollten idempotent sein
4. Selbstdokumentierend --help mit realistischen Beispielen
5. Für Composability designen — --quiet für reine Werte und stdin-Unterstützung
6. --dry-run- und --yes-Flags bereitstellen
7. Version-Introspection unterstützen
8. Authentifizierung über Environment-Variablen handhaben

CLI bietet keine Discovery auf Protokollebene. JSON Tool Calling kann typisierte Schemas übertragen, während MCP die Tool Discovery standardisiert und für HTTP-Transports ein Autorisierungsmodell bereitstellt. Keines von beiden liefert Governance automatisch: Host, Server oder Harness müssen Richtlinien durchsetzen und die für Audits erforderlichen Calls protokollieren. Das Muster, auf das sich die meisten Teams meiner Beobachtung nach einigen, ist CLI für Entwicklung und lokale Operationen sowie MCP für die gemeinsame Integration externer Services.

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

Das ist die folgenreichste Veränderung bei Agent-Tooling, die ich beobachte. Statt strukturiertes JSON auszugeben, um vordefinierte Funktionen einzeln aufzurufen, schreibt der Agent ein Python- oder Bash-Script. Das Script ruft mehrere Tools auf, verarbeitet Ergebnisse mit Loops und Conditionals und gibt nur die abschließende Zusammenfassung an den Model Context zurück.

Anthropic hat Programmatic Tool Calling (PTC) als eines von drei Beta-Features in der Claude API eingeführt. Die akademische Grundlage bildet das CodeAct-Paper (Wang et al., ICML 2024). Darin wurde Code über 17 LLMs hinweg evaluiert; dabei erzielten Code-Actions bis zu 20 % höhere Task-Erfolgsraten und benötigten 30 % weniger Schritte als JSON-Alternativen.

Drei First-Party-Fallstudien zeigen, wo dieses Pattern hilfreich sein kann: unten Vercel und Cloudflare, anschließend Anthropic mit einem Beispiel zur Spesenanalyse. Betrachte sie als Evidenz der Anbieter und führe den Vergleich mit deinen eigenen Tasks erneut durch.

• Vercel hat d0, seinen Data Agent für Natural-Language-to-SQL, neu aufgebaut. Das alte Code-Beispiel nennt 17 Tools; das neue Code-Beispiel stellt ExecuteCommand und ExecuteSQL bereit. Vercel beschreibt das Redesign als Entfernung von 80 % seiner Tools. Diese Aussage ist jedoch Vercels Headline und keine Prozentangabe, die sich aus den in den Beispielen genannten Tools ableiten lässt. Für fünf repräsentative Queries berichtet Vercel, dass der Task-Erfolg von 4/5 auf 5/5 stieg, die durchschnittliche Ausführungszeit um den Faktor 3,5 sank (von 274,8 s auf 77,4 s) und der durchschnittliche Token-Verbrauch um 37 % zurückging (von etwa 102k auf etwa 61k). Ihre Formulierung lautet: „The best agents might be the ones with the fewest tools.“

• Cloudflare hat „Code Mode“ entwickelt, mit dem Agents TypeScript schreiben können, um ihre API aufzurufen, statt Tool Schemas zu definieren. Dadurch sinkt der Context Overhead. Die Begründung lautet: „LLMs haben eine enorme Menge an praxisnahem TypeScript in ihren Trainingsdaten, aber nur eine kleine Zahl an konstruierten Beispielen für Tool Calls.“

Hier ist das Pattern aus Anthropics PTC-Dokumentation. In Anthropics sequenzieller Illustration zur Spesenanalyse erfordert herkömmliches Function Calling mehr als 20 separate Inference-Pässe, wobei Zwischendaten durch den Context fließen. Nach der Abfrage der Mitarbeitenden kann ein Host, der parallele Tool Calls unterstützt, die unabhängigen Spesenabfragen bündeln; die Angabe von mehr als 20 Pässe macht das nicht unmöglich. Anthropic berichtet, dass generierter Code zur Beantwortung derselben Frage den Anteil, der den Context erreicht, von 200 KB rohen Spesendaten — mehr als 2.000 Einzelpositionen — auf 1 KB Ergebnisse reduziert. Mit Code Execution schreibt der Agent ein einzelnes Script:

# Agent generates this code, executes in sandbox
import asyncio
import json

async def main() -> None:
    team = await get_team_members("engineering")
    levels = list(set(member["level"] for member in team))
    budgets = dict(zip(
        levels,
        await asyncio.gather(*(get_budget_by_level(level) for level in levels)),
    ))
    expenses = await asyncio.gather(
        *(get_expenses(member["id"], "Q3") for member in team)
    )
    over_budget = []
    for member, employee_expenses in zip(team, expenses):
        total = sum(expense["amount"] for expense in employee_expenses)
        limit = budgets[member["level"]]["travel_limit"]
        if total > limit:
            over_budget.append(
                {"name": member["name"], "spent": total, "limit": limit}
            )
    # Only this final summary returns to the LLM context
    print(json.dumps(over_budget))

asyncio.run(main())

Das LLM sieht nur die finale JSON-Zusammenfassung und nicht die Tausenden von Spesenpositionen, die in der Sandbox verarbeitet wurden. Die Einsparung ist nicht spezifisch für Spesenabrechnungen: Anthropics separater Beitrag zu Code Execution nennt die deutlichste Zahl für dieses Pattern: Ein Workflow von Google Drive zu Salesforce sank von etwa 150.000 Tokens auf etwa 2.000 — eine Reduktion um 98,7 %.

Token-Effizienz ist der offensichtliche Vorteil. Schleifen und Bedingungen gibt es praktisch kostenlos, und Code Execution kann Fehler mit expliziten Handlern behandeln, statt das Model dazu zu bringen, Fehler in natürlicher Sprache zu analysieren. Ein Pfad über Code Execution kann sensible Zwischendaten aus dem Model Context heraushalten; das ist jedoch keine Vertraulichkeit: Isolation, Egress Controls, eingeschränkte Credentials und Logging müssen separat durchgesetzt werden.

Wann JSON Tool Calling weiterhin sinnvoll ist: bei einzelnen atomaren Operationen, in Umgebungen ohne Sandbox-Infrastruktur, bei kleineren Models mit schwacher Code-Generierung oder bei Audit-Anforderungen, die jeden einzelnen Tool-Aufruf protokolliert benötigen.

Vergleichstabelle zum Tool Calling von AI Agents

„Meta-Tools“ in der Zeile zum Token-Overhead bezeichnet die wenigen generischen Einstiegspunkte, die ein Code ausführender Agent benötigt – beispielsweise Vercels ExecuteCommand und ExecuteSQL – anstelle eines Schemas pro zugrunde liegender Operation. Die Zeilen zu Composability und Latenz beziehen sich auf Calls, deren spätere Argumente von früheren Ergebnissen im besprochenen Harness oder Loop abhängen. JSON Tool Calling und MCP können unabhängige Calls gemeinsam ausgeben, und ein Host kann sie nebenläufig ausführen; abhängige Calls benötigen normalerweise einen weiteren Model-Turn, um die nächste Aktion auszuwählen. PTC verlagert den abhängigen Control Flow und das Filtering auf Code-Seite in das Script und gibt anschließend eine Zusammenfassung an das Model zurück; unabhängige Calls können ebenfalls nebenläufig ausgeführt werden. Die Token- und Task-Success-Zellen fassen die zitierten Beispiele zusammen und stammen nicht aus einem kontrollierten Benchmark über alle fünf Spalten.

Das Agent-Computer-Interface (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 in ihrem SWE-agent-Paper (NeurIPS 2024) geprägt. Der Qualität menschlicher Interfaces ist eine ganze Disziplin gewidmet: Human-Computer Interaction, kurz HCI. Das Paper argumentiert, dass Language-Model-Agents dieselbe Aufmerksamkeit verdienen: Sie seien „eine neue Kategorie von Endnutzern mit eigenen Anforderungen und Fähigkeiten, die von speziell entwickelten Interfaces profitieren würden“.

Ihre Ablation-Ergebnisse quantifizieren diesen Effekt. Mit demselben GPT-4-Turbo-Basismodell erreichte die Ablation des Papers auf SWE-bench Lite mit dem vollständigen ACI von SWE-agent bei 300 Aufgaben 18,0 %, gegenüber 7,3 % für die Shell-only-Bedingung ohne Worked Demonstration und 11,0 % mit einer solchen Demonstration. Der Vergleich zeigt, dass Interface- und Demonstrationsbedingungen die Performance in diesem Setup substanziell veränderten; er isoliert das Interface-Design jedoch nicht von allen anderen Unterschieden und zeigt auch nicht, dass das Modell keine Arbeit geleistet hätte. Innerhalb derselben Interface-Ablation erhöhte das Aktivieren von Linting die Edit-Bedingung von 15,0 % auf 18,0 %; über den vollständigen SWE-bench-Testdatensatz hinweg enthielten 51,7 % der SWE-agent-Runs mindestens ein Edit, das der Linter ablehnte, bevor es weitergegeben werden konnte.

Anthropic übernahm ACI als grundlegendes Konzept in ihrem Leitfaden “Building Effective Agents” und führt es als eines von drei Kernprinzipien auf: „Entwickle dein Agent-Computer-Interface sorgfältig durch ausführliche Tool-Dokumentation und Tests.“ Die praktische Empfehlung lautet: „Als Faustregel solltest du dir überlegen, wie viel Aufwand in Human-Computer-Interfaces fließt, und planen, genauso viel Aufwand in die Entwicklung guter Agent-Computer-Interfaces zu investieren.“

Vier ACI-Prinzipien in der Praxis

1. Aktionen sollten einfach und leicht verständlich sein. Der häufigste Fehler besteht darin, API-Endpunkte eins zu eins zu wrappen. Statt list_users, list_events, create_event solltest du schedule_event implementieren, das Verfügbarkeiten ermittelt und in einem Aufruf Termine plant. Statt read_logs solltest du search_logs implementieren, das nur die relevanten Zeilen mit Kontext zurückgibt.

2. Aktionen sollten kompakt und effizient sein. Fasse wichtige Operationen in möglichst wenigen Aktionen zusammen. Im Market Analyst Agent kombiniere ich das Abrufen von Preisen mit grundlegenden Metriken in einem einzigen get_stock_snapshot-Tool, anstatt separate Aufrufe für Preis, Volumen, Market Cap und PE-Ratio zu erfordern.

3. Feedback aus der Umgebung sollte informativ, aber prägnant sein. Vermeide die Rückgabe von rohem HTML oder vollständigen API-Payloads. Löse kryptische IDs in semantische Namen auf. Anthropics Tests ergänzten ein response_format-Enum, damit der Agent eine knappe Antwort mit etwa 72 Tokens oder eine detaillierte Antwort mit etwa 206 Tokens anfordern kann – ein ungefähr dreifacher Unterschied bei den Token-Kosten.

4. Validierung sollte die Fehlerfortpflanzung eindämmen. Die automatische Fehlererkennung hilft Agents, Fehler schnell zu erkennen und zu korrigieren. In SWE-agent weist ein benutzerdefinierter File Editor mit integriertem Linting Syntaxfehler automatisch zurück – das ist der Validierungsschritt hinter dem oben genannten Wert von 51,7 %. Dabei geht es um die Validierung der Ein- und Ausgaben eines Tools, nicht um die Inhaltsfilterung rund um einen Model-Aufruf, die die Guardrail-Produkte in Teil 4 übernehmen; für beides wird dasselbe Wort verwendet. Im Market Analyst Agent wende ich dasselbe Prinzip an, indem ich Tool-Argumente vor der Ausführung mit Pydantic-Schemas validiere:

from pydantic import BaseModel, Field, field_validator

from market_analyst.utils import normalize_ticker

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)")

    @field_validator("ticker")
    @classmethod
    def validate_ticker(cls, v: str) -> str:
        return normalize_ticker(v)

class StockHistoryQuery(StockQuery):
    """Validated input for price history queries."""

    period: str = Field(default="1mo", description="Time period: 1d, 5d, 1mo, 3mo, 6mo, 1y")

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

Der gemeinsame Normalizer entfernt Leerzeichen am Anfang und Ende und schreibt den Wert in Großbuchstaben um. Anschließend akzeptiert er Ticker-Ziffern sowie Suffixe mit Punkten oder Bindestrichen wie BRK.B und BF-B; StockHistoryQuery, nicht StockQuery, ist für period zuständig.

Funktionierende Muster für das Tool-Design von AI Agents

Anthropics Leitfaden “Writing effective tools for agents” beschreibt Tools als „eine neue Art von Software, die einen Vertrag zwischen deterministischen Systemen und nichtdeterministischen Agents widerspiegelt“.

Behandle Tool-Beschreibungen als Prompt Engineering

Beschreibungen sollten mindestens drei oder vier Sätze umfassen und erläutern, wann das Tool verwendet werden soll, welche Parameter erforderlich beziehungsweise optional sind, welches Ausgabeformat gilt und welche Edge Cases auftreten können. Anthropic berichtet, dass die Wahl zwischen einer auf Präfixen und einer auf Suffixen basierenden Namespacing-Strategie (asana_search beziehungsweise search_asana) bei den eigenen Tool-Use-Evals „nichttriviale Auswirkungen“ hatte. Es wird nicht angegeben, welches Schema besser abschneidet. Teste daher beide mit deinem Toolset, statt Präfixe einfach vorauszusetzen. Anthropic speiste außerdem die Transkripte seiner Evaluator-Agents zurück in Claude Code und ließ die Tools umschreiben. Auf zurückgehaltenen Testsets erzielte dieser Loop weitere Verbesserungen „sogar über das hinaus, was wir mit ‚Expert‘-Tool-Implementierungen erreicht haben“ – unabhängig davon, ob die Tools von den eigenen Forschern von Hand geschrieben oder von Claude generiert worden waren.

# 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": "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 company competitors rather than news, use search_competitors 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"]
    }
}]

Anthropics interne Tests zeigten, dass ein zusätzliches Feld input_examples die Genauigkeit bei der Verarbeitung komplexer Parameter von 72 % auf 90 % erhöhte.

Liefere aussagekräftige, maschinenlesbare Ausgaben

Vermeide Low-Level-Identifier (uuid, mime_type). Löse kryptische IDs in semantische Namen auf. Strukturiere die Antwort so, dass der Agent darüber nachdenken kann, ohne Boilerplate parsen zu müssen:

# Bad: raw API response dumped to agent
def get_stock_snapshot(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_snapshot(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}%)"
    }

Liefere Fehler, mit denen der Loop arbeiten kann

Das Error Handling benötigt vier getrennte Mechanismen, weil sie unterschiedliche Fehlerklassen behandeln:

1. Retries mit exponentiellem Backoff für transiente Fehler
2. Model-Fallback-Ketten bei Ausfällen von Providern
3. Routing nach Fehlerklassifikation – transiente Fehler werden erneut versucht, durch ein LLM behebbare Fehler mit Kontext an den Agent zurückgegeben, und Fehler, die einen Menschen erfordern, werden eskaliert
4. Checkpoint-Recovery zur Überbrückung von Crashes

Anthropics “Writing effective tools for agents” plädiert für klare Tool-Fehler und Eval-gesteuertes Tool-Design, nennt jedoch keine universelle Zahl dafür, wie viele Fehler diese vier Mechanismen beheben. Messe Recovery-Rate, Retries und Eskalationen in deiner eigenen Task-Suite.

import httpx
from tenacity import retry, retry_if_exception, stop_after_attempt, wait_exponential

def is_transient_error(error: BaseException) -> bool:
    if isinstance(error, (httpx.TimeoutException, httpx.NetworkError)):
        return True
    if isinstance(error, httpx.HTTPStatusError):
        return error.response.status_code == 429 or 500 <= error.response.status_code < 600
    return False

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

    Mechanism 1 of the four above: exponential backoff for 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 Patterns auf den Market Analyst Agent

Der Market Analyst Agent aus Teil 1 macht den Effekt des Interface-Designs sichtbar.

Konsolidierung der Tools

Die ursprünglichen Tool-Module definierten get_stock_price, get_company_metrics, get_price_history, zwei Search-Tools und execute_trade. Für eine grundlegende Analyse musste der Agent sowohl den Kurs- als auch den Metrics-Call auswählen; Market Cap und P/E waren Felder von get_company_metrics und keine eigenständigen Tools. Der Source-Stand vor der Konsolidierung zeigt diese frühere Oberfläche.

Ich habe die Market-Data-Oberfläche gemäß dem ACI-Prinzip kompakter, effizienter Actions in fünf High-Level-Tools umstrukturiert. Die ReAct-Tool-Liste des Repos enthält daneben vier weitere Tools — einen Skill Loader, zwei CLI-Wrapper und einen eingeschränkten In-Process-Python-Evaluator (eine AST-Allowlist, keine Sandbox; Teil 4 behandelt dieses Thema) — und deckt damit drei der fünf oben genannten Modalitäten ab. MCP erscheint als Sidecar und nicht als Tool in dieser Liste:

Damit werden Kurs und Valuation in einer auf eine Aufgabe zugeschnittenen Definition zusammengeführt und Financial Statements als explizite Action ergänzt. Ob dadurch die Tool-Auswahl verbessert wird, ist anhand repräsentativer Requests und Traces zu überprüfen.

Strukturierte Tool Results

Die Stock- und News-Tools liefern Pydantic-validierte Responses. Die CLI- und Code-Execution-Wrapper geben str zurück. Daher beschreiben die folgenden Models die strukturierten Tool Results und nicht jeden Wrapper im Repository:

from pydantic import BaseModel

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 NewsItem(BaseModel):
    """One news item 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

class NewsSearchResult(BaseModel):
    query: str
    results: list[NewsItem]
    summary: str

Das Feld summary liefert dem Agent eine direkt verwendbare Zeichenfolge, die unmittelbar in einen Report übernommen werden kann. NewsItem.key_points werden vom Tool und nicht vom Agent extrahiert. Dadurch werden Inference-Tokens eingespart, die andernfalls zum Parsen der Artikelinhalte erforderlich wären.

Trade-offs und Überlegungen

Neben den spezifischen Einschränkungen der einzelnen oben beschriebenen Patterns beeinflussen einige übergreifende Aspekte die Auswahl:

• Die operativen Kosten variieren je nach Dimension. Code Execution spart Tokens, fügt aber eine Cold-Start-Latenz des Sandboxes hinzu. MCP spart Entwicklungszeit bei SaaS-Integrationen, bringt jedoch zusätzlichen Aufwand für das Deployment von Servern mit sich. Die CLI ist zunächst kostenlos, lässt sich aber bei einer Skalierung schwerer steuern. Optimiere für deinen tatsächlichen Bottleneck – unabhängig davon, ob es sich um Token-Kosten, Latenz oder operative Komplexität handelt.

• Die Kompetenzen des Teams sind entscheidend. Code Execution setzt voraus, dass deine Agents (und die dahinterliegenden Models) zuverlässiges Python oder TypeScript generieren können. Für die CLI sind Kenntnisse der Unix-Konventionen erforderlich. MCP erfordert ein Verständnis von Transportprotokollen und OAuth-Flows. Stimme die Modalität auf die Stärken deines Teams ab.

• Die Konsolidierung von Tools kann zu weit gehen. Wenn ein Tool nicht zusammenhängende Modi und Argumente ansammelt, steht der Agent innerhalb des Schemas vor einem anderen Auswahlproblem. Nutze Tool-Selection- und Task-Success-Evals, um die passende Oberfläche für deinen Workload zu bestimmen.

• Skills basieren auf Prompts und werden nicht erzwungen. Ein Skill enthält Anweisungen, die der Agent befolgen sollte, aber keine Guardrails, die er befolgen muss. Ein Skill-Bundle kann beliebige Dateien und ausführbare Scripts enthalten. Vertraue daher auf die Quelle, überprüfe das Bundle und lasse den Host die Berechtigungen für jede Ressource durchsetzen, die gelesen, geändert oder ausgeführt werden kann. Bei kritischen Workflows solltest du Skills mit deterministischer Validierung kombinieren.

• Anforderungen an Audits beeinflussen die Auswahl. Strukturierte MCP- und JSON-Calls sind praktische Events für die Protokollierung, aber keines der beiden Protokolle erstellt standardmäßig einen vollständigen Audit-Trail. Der Host, Server oder Harness muss Invocations und Results aufzeichnen und anschließend Autorisierung, Richtlinien, Aufbewahrung und Review durchsetzen. Für Code Execution ist dieselbe Instrumentierung rund um den Sandbox erforderlich; Script und Output allein sind kein Compliance-Nachweis.

Drei Richtungen für AI-Agent-Tooling im großen Maßstab

Die erste ist Tool RAG zur Skalierung. In den Benchmark-Tasks und dem MCP-Stresstest von RAG-MCP lag die Accuracy der Tool-Selection im Baseline-Setup bei 13,62 %. Durch Retrieval stieg sie auf 43,13 % – eine Verbesserung um den Faktor 3,2 –, während die Prompt-Tokens um mehr als 50 % sanken. Das Ergebnis gilt für dieses Eval-Setup und ist keine universelle Rate für naive Selection bei wachsenden Toolsets.

Die zweite Richtung sind Agents, die ihre eigenen Tools erstellen. Das LATM-Framework („LLMs As Tool Makers“) etablierte ein Paradigma mit zwei Phasen: Ein leistungsstarkes LLM erstellt wiederverwendbare Python-Funktionen, ein kleineres LLM verwendet sie. Im 15-Task-Benchmark von ToolMaker zu Papers mit öffentlichen Code-Repositories, die als GitHub-URLs und kurze Task-Beschreibungen bereitgestellt wurden, implementierte es 80 % der Tasks korrekt. Beide Ansätze weisen über Tool Use hinaus auf Tool Creation und anschließend auf die Verwaltung einer Bibliothek generierter Tools.

Die dritte Richtung ist der Dual-Protocol-Stack aus A2A und MCP. Google übertrug A2A im Juni 2025 an die Linux Foundation. Die Dokumentation des A2A-Protokolls grenzt die Zuständigkeiten ab: MCP verbindet einen Agent mit Tools und Ressourcen, während A2A unabhängigen Agents ermöglicht, einander zu entdecken, Interaktionen auszuhandeln, gemeinsame Tasks zu verwalten und Arbeit zu delegieren.

Zentrale Erkenntnisse

1. Wählen Sie das Interface anhand der Aktion: JSON Function Calling für kleine typisierte Operationen, MCP für gemeinsam genutzte Services, Skills für Prozeduren, CLI für etablierte Commands und Sandbox-Code für lokale Komposition.
2. Behalten Sie die Benchmark-Bedingungen beim Ergebnis. CodeAct, Anthropic, Vercel, Cloudflare, Apideck und Scalekit haben unterschiedliche Models, Tasks, Tools und Harnesses gemessen.
3. Die ACI-Qualität bleibt auch bei Protokolländerungen erhalten. Klare Aktionen, kompakteres Feedback, Validierung und hilfreiche Fehlermeldungen unterstützen jede Modalität.
4. Konsolidieren Sie sich überschneidende Tools nur dann, wenn Evals zeigen, dass die kleinere Oberfläche die Auswahl oder den Task-Erfolg verbessert.
5. Mit der Ausführungsmacht verschieben sich auch die Security-Anforderungen. Shell- und Code-Interfaces benötigen Sandboxing; MCP benötigt eine eingeschränkte Identität und Server-Policy; Skills bleiben Instruktionen und sind keine Enforcement-Mechanismen.

Die nächste Ebene ist Policy

Teil 4, AI Agent Security, platziert einen Policy-Check zwischen einem vorgeschlagenen Tool Call und dessen Ausführung. Es handelt sich um dieselbe oben beschriebene Tool-Grenze, diesmal aus der Perspektive, die Nein sagt. Teil 5 platziert das Tool und seine Sandbox anschließend in einem recoverbaren Runtime, und Teil 6 ergänzt einen zweiten Vertrag, den das Model nie sieht: eine Effect-Kategorie, eine Retry-Regel und ein strukturiertes Ergebnis, das ein Acceptance-Check lesen kann, ohne Prosa parsen zu müssen.

Referenzen

Papers

• Executable Code Actions Elicit Better LLM Agents (CodeAct) — Wang et al., ICML 2024 — Code-basierte Aktionen erreichen bis zu 20 % mehr Task-Erfolg als JSON
• SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering — Yang, Jimenez et al., NeurIPS 2024 — ACI-Designprinzipien und SWE-bench-Evaluation (18,0 % für SWE-agent gegenüber 7,3 % für Shell-only ohne Demonstration in der 300-Task-SWE-bench-Lite-Ablation des Papers; Interface- und Demonstrationsbedingungen unterscheiden sich)
• RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection — Die Benchmark-Tasks und der MCP-Stresstest steigerten die Selection Accuracy von 13,62 % auf 43,13 %
• LLMs As Tool Makers (LATM) — Cai et al., 2023 — Zwei-Phasen-Paradigma zur Erstellung von Agent Tools
• ToolMaker: LLM Agents Making Agent Tools — Wolflein et al., ACL 2025 — 80 % im eigenen 15-Task-Benchmark mit Papers, deren Code-Repositories öffentlich verfügbar sind
• MCPTox: A Comprehensive MCP Toxicity Benchmark — 72,8 % Attack Success Rate über 20 LLM Agents und 45 MCP Server hinweg

Anthropic Engineering

• Advanced Tool Use / Programmatic Tool Calling — Tool Search (85 % weniger Context-Verbrauch insgesamt, etwa 77.000 auf 8.700 Tokens), PTC und Beispiele für Tool Use
• Code Execution with MCP — 98,7 % weniger Tokens (150.000 auf 2.000 Tokens) durch code-basierte Tool Orchestration
• Writing Effective Tools for Agents — Engineering von Tool-Beschreibungen; Input-Beispiele verbessern die Accuracy; response_format-Enum (72 gegenüber 206 Tokens)
• Building Effective Agents — ACI als grundlegendes Designprinzip

Protokollspezifikationen

• Google Cloud überträgt A2A an die Linux Foundation — Ankündigung vom 23. Juni 2025 zur Übertragung des Protokolls, SDKs und der Tools
• A2A und MCP: Detaillierter Vergleich — A2A-Protokolldokumentation zu den komplementären Verantwortlichkeiten von Agent-to-Agent- und Agent-to-Tool-Kommunikation

Fallstudien aus der Industrie

• Vercel: Wir haben 80 % der Tools unseres Agents entfernt — Das alte Beispiel nennt 17 Tools; das neue Beispiel stellt ExecuteCommand und ExecuteSQL bereit. Vercel beschreibt das Redesign als Entfernung von 80 % der Tools; bei fünf repräsentativen Queries stieg die Erfolgsquote von 4/5 auf 5/5, bei 3,5-facher Geschwindigkeit und 37 % weniger Tokens
• Cloudflare: Code Mode — TypeScript-gesteuerte API-Aufrufe ersetzen Tool Schemas
• Apideck: MCP Server frisst dein Context Window — 550–1.400 Tokens pro Tool, 55K Tokens für etwa 40 MCP-Tools, 143K von 200K Tokens des Context Windows belegt
• Scalekit: MCP- vs. CLI-Token-Benchmark — 4- bis 32-facher Token-Overhead für MCP gegenüber CLI in 75 Benchmark-Durchläufen

Sicherheit

• Vulnerable MCP Project — 50 erfasste Schwachstellen, davon 13 kritisch, gemeldet von 32 Forschenden
• AuthZed: Zeitleiste der MCP-Sicherheitsverletzungen — 9 größere MCP-Sicherheitsvorfälle (April bis Oktober 2025)
• Invariant Labs: MCP Tool-Poisoning-Angriffe — Tool Poisoning, Rug Pulls und Cross-Origin-Eskalation
• Pivot Point Security: MCP-Sicherheitsanalyse — 43 % Command Injection, 43 % Schwachstellen bei der OAuth-Authentifizierung

CLI-Design

• CLI-Tools entwickeln, die AI Agents tatsächlich verwenden möchten — Ugo Enyioha — Acht Designregeln für agentenfreundliche CLIs

Demo-Projekt

• Market Analyst Agent — Vollständige Implementierung mit Tool-Konsolidierung und ACI-Mustern

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