Tool Calling ist ein Application Pattern, bei dem ein Modell eine benannte Capability auswählt oder vorschlägt und strukturierte Arguments liefert. Die Host Application entscheidet danach, ob und wie sie diese ausführt. Ein Tool kann Daten abrufen, rechnen, einen Draft erstellen oder ein externes System verändern. Der Model Output ist ein Request und kein Beweis für Authorization, Validity oder Completion. Die Anwendung validiert Schema, authentifiziert User und Service, erzwingt Policy, prüft State, führt über Trusted Integration aus und liefert ein beobachtetes Result an Modell oder User.
Ein Prototype lässt Tool Use wie einen einfachen Loop wirken: Functions beschreiben, Call parsen, Result zurückgeben. Production bringt Identity, Permissions, Stale State, Duplicate Execution, Partial Failure, adversariale Instructions und irreversible Consequences. Ein syntaktisch gültiges Argument kann falschen Customer oder Amount adressieren. Ein Timeout kann erfolgreichen Payment verdecken und Retry dupliziert ihn. Tool Output kann untrusted Content enthalten, der das Modell umlenkt. Entscheidet das Modell auch Authorization und Success, kontrolliert eine probabilistische Komponente die ganze Transaction.
Entwerfen Sie Tools als enge, typed Application Contracts um Business Capabilities. Halten Sie Identity, Authorization, Limits und High-Consequence Approvals ausserhalb des Modells. Trennen Sie Read, Draft, Preview und Commit, wo Effects dadurch verständlich werden. Nutzen Sie Idempotency und Current-State Checks für Mutations, minimieren Sie Credentials und liefern Sie Structured Outcome Evidence. Das Modell darf Tool und Explanation wählen, aber Deterministic Services entscheiden, ob der exakte Effekt geschehen darf. Testen Sie Denial, Cancellation, Timeout, Retry, Compensation und malicious Output.
Call Lifecycle
Selection, Authorization, Execution und Observation sind getrennt
Ein Modell wählt ein Tool, weil Name, Description und Schema relevant scheinen, und konstruiert Arguments aus dem Conversation Context. Der Host parst und validiert den Vorschlag vor Execution. Authentication etabliert Identity, Authorization entscheidet Berechtigung und Business Validation prüft Current Conditions. Erst die Integration führt die Operation aus. Eine Observation meldet Success, Failure, Created IDs oder Changed State. Wer diese Stufen vermischt, erzeugt False Completion und schwachen Audit Trail.
Die Model Context Protocol Specification definiert Tools mit Identifiers, Descriptions und Input Schemas sowie Call Request und Result. Ein Protocol standardisiert Discovery und Messages, entscheidet aber nicht Permission Model und Risk Appetite einer Organisation. Behandeln Sie Server Annotations und Metadata als Information aus einer Trusted Source. Derselbe Security Review gilt für MCP, Provider Function Interface und Internal Code.
| State | Verantwortliche Layer | Evidenz |
|---|---|---|
| Proposed | Model und Host Parser | Tool Name und Arguments |
| Authorized | Identity und Policy Service | Decision und Scope |
| Validated | Business Application | Current State und Invariants |
| Executed | Trusted Integration | Provider Response |
| Observed | Application und UI | Verified Outcome |
Effect Safety
Die API soll einen plausiblen Modellfehler begrenzen
Narrow Tools reduzieren Ambiguity. Ein Read Tool mutiert nicht als Side Effect. Ein Draft Tool bereitet Content ohne Versand vor. Ein Preview löst Current Price, Recipient und Impact unmittelbar vor Approval auf. Ein Commit Tool kann Immutable Preview Token und Idempotency Key verlangen. Diese Grenzen verbessern Human Understanding und Automated Testing. Sie machen Denial zu einem normalen Result statt zu einem Conversational Failure, den das Modell umgeht.
Risk Management sollte Foreseeable Misuse und Operational Change über den Lifecycle abdecken, konsistent mit dem NIST AI RMF. Bauen Sie Evaluation Cases für Prompt Injection, Unauthorized Records, Malformed Arguments, Stale Previews, Provider Timeouts und Contradictory Results. Redacten Sie Secrets, minimieren Sie Payload Retention und alerten Sie abnormal Patterns. Irreversible oder regulierte Effects brauchen Domain- und Security-Review.
- Tools eng und typed halten.
- Jeden Effect gegen aktuelle Identity autorisieren.
- Preview von Consequential Commit trennen.
- Retries möglichst idempotent machen.
- Observed Outcome statt Model Intention melden.
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für AI Tool Calling
- Jedes Tool hat bounded Purpose, Input Schema und definiertes Result.
- User- und Service Permissions werden bei Execution geprüft.
- High-Consequence Actions zeigen Preview und Approval, wo passend.
- Retries duplizieren keinen geschützten Business Effect.
- Requested, Accepted, Completed und Failed States bleiben getrennt.
- Logs stützen Investigation ohne unnötige Secrets oder Private Content.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Business Capability modellieren
Benennen Sie Actor, Object, Operation, Preconditions, Effect und Failure Consequences. Entscheiden Sie vor der Tool Description, ob die Capability Read-only, Draft, Reversible oder Commit-Level sein soll.
- 02
Typed Contract spezifizieren
Erstellen Sie präzise Names, Descriptions, constrained Input Schemas und Structured Outputs. Machen Sie IDs explizit, lehnen Sie Unknown Fields ab und trennen Sie Business Errors von Transport Failures.
- 03
Execution Controls durchsetzen
Authentifizieren Sie aktuelle Identity, autorisieren Sie Object und Action, validieren Sie State, wenden Sie Rate und Value Limits an, verlangen Sie Approval und nutzen Sie Idempotency für Mutations.
- 04
Effects beobachten und evaluieren
Geben Sie Actual Result statt optimistischer Annahme zurück. Erfassen Sie Correlation, Decision und Outcome States. Testen Sie Normal, Denied, Ambiguous, Adversarial und Partial Failure samt Compensation.
Bewertung
Fragen, die den Entscheid verändern
- Soll das Modell diese Operation lesen, entwerfen, previewen oder committen?
- Welche Identity und Policy autorisieren Object und Action?
- Was muss jenseits des Input Schema deterministisch validiert werden?
- Welcher Effect braucht Human Confirmation am aktuellen State?
- Wie werden Retry, Timeout und Duplicate Request aufgelöst?
- Welche Structured Evidence zeigt, was tatsächlich geschah?
Fehlermuster
Wo Teams die Kontrolle verlieren
Ein breites Tool erlaubt mehr Action als seine Description zeigt.
Das Modell erfindet eine syntaktisch gültige, aber falsche ID.
Untrusted Tool Output injiziert Instructions in den nächsten Step.
Ein Timeout wird nach bereits erfolgreichem Effect wiederholt.
Approval wird vor einer materiellen State- oder Amount-Änderung erfasst.
Der Assistant behauptet Completion aus Request statt Observed Result.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- Tool Requests accepted, denied, clarified und abandoned nach Reason
- Schema-, Authorization- und Business-Rule-Failures
- durch Idempotency verhinderte Duplicate Effects
- Requests mit Verified Completion Evidence
- Human Approval und Cancellation Rate nach Consequence Tier
- Zeit zu Detection, Containment und Resolution partieller Execution
Fragen
Häufige Fragen
Was ist Tool Calling in einer AI-Anwendung?
Das Modell schlägt eine benannte Operation mit Arguments vor; die Host Application validiert, autorisiert und führt sie aus. Tools können Information abrufen oder externe Effects erzeugen.
Ist Function Calling schon Function Execution?
Nein. Das Modell erzeugt normalerweise einen Structured Request. Application Code entscheidet über Validity und Permission, führt aus und gibt Observed Result zurück. Model Output schafft keine Authority.
Wie werden Tool Calls sicherer?
Mit Narrow Schemas, Least-Privilege Credentials, Current-State Authorization, Deterministic Checks, Preview und Approval, Idempotency, Structured Results, Monitoring und getesteter Recovery.
Macht MCP Tool Calling automatisch sicher?
Nein. MCP standardisiert Discovery und Calls. Die Application verantwortet Trust, Authentication, Authorization, Validation, Approvals, Secret Handling, Execution und Audit.
Quellen
Primärquellen
- Model Context Protocol: Tools Model Context Protocol
- Artificial Intelligence Risk Management Framework 1.0 National Institute of Standards and Technology
Über den Autor
Tony Kim
Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.
Zeke
AI Product Engineering, das aus einem Software-Briefing ein zuverlässiges Produkt im Betrieb macht.
Produktverantwortliche, Gründungsteams und Software-Engineering-Teams. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.
Zeke ansehen→