Mission 003 · APIs werden zu Werkzeugen

In 30 Sekunden

Agenten brauchen mehr als technische Endpunkte: klar beschriebene Fähigkeiten, Grenzen, Nebenwirkungen und sichere Ausführungswege. Eine API wird erst dann zum verlässlichen Werkzeug, wenn ihr Vertrag auch für ein nichtdeterministisches System eindeutig ist.

Warum das wichtig ist

Ein Agent wählt selbst, welches Werkzeug er aufruft. Ist eine Nebenwirkung nicht im Vertrag beschrieben, löst er sie womöglich unbeabsichtigt aus.

Tool-Verträge mit Idempotenz, Dry Run und Kompensationslogik machen Integrationen auch dann beherrschbar, wenn der Aufrufer nicht deterministisch handelt.

Redaktionelle EinordnungEin Protokoll wie MCP standardisiert das Anbinden von Tools — es ersetzt aber weder Autorisierung noch fachliche Tool-Grenzen. Der Vertrag der einzelnen Funktion bleibt die eigentliche Arbeit.

Die zentralen Architekturfragen

Welche Fähigkeiten, Grenzen und Nebenwirkungen hat jedes Tool — explizit beschrieben?
Welche Aufrufe sind idempotent, welche verändern Zustand unwiderruflich?
Gibt es einen Dry-Run-Modus für riskante Aktionen?
Wie werden fehlgeschlagene Mehrschritt-Abläufe kompensiert?
Wie werden Tool-Aufrufe auditierbar protokolliert?

Typische Muster

Tool Contracts: präzise Beschreibung von Eingaben, Wirkung und Grenzen.
Idempotenz: wiederholte Aufrufe ohne doppelte Wirkung.
Dry Run: Wirkung prüfen, bevor sie eintritt.
Kompensationslogik: definierte Rücknahme bei Teilfehlern.
MCP / A2A hinter Gateway: Protokolle gebündelt und kontrolliert exponiert.

Häufige Fehlannahmen & Anti-Patterns

Agenten erhalten rohe API-Endpunkte ohne beschriebene Grenzen.
Schreibende Tools ohne Idempotenz oder Dry Run.
Protokolle wie MCP direkt ins Internet exponiert.
Tool-Aufrufe ohne Trace — Fehler nicht rekonstruierbar.

Praktische Prüffragen

Ist für jedes Tool dokumentiert, was es verändert?
Können wir riskante Aktionen erst simulieren?
Laufen alle Tool-Aufrufe über ein kontrolliertes Gateway?
Lässt sich jeder Aufruf im Nachhinein nachvollziehen?

Bezug zum durchgehenden Praxisbeispiel

Welche Systeme ruft der Agent auf — und welche Aufrufe sind lesend, welche schreibend?

Lesende Tools (Fall abrufen, Wissen suchen) sind von schreibenden (Aktion auslösen) klar getrennt.
Schreibende Aktionen haben einen Dry-Run und sind idempotent — ein wiederholter Aufruf richtet keinen Doppelschaden an.
Fehler, Timeouts und Wiederholungen sind im Tool-Vertrag definiert; Mehrschritt-Abläufe haben eine Kompensationslogik.
Alle Aufrufe laufen über ein kontrolliertes Gateway und sind auditierbar protokolliert.

Zum vollständigen Praxisbeispiel: Service-Agent

Bezug zur Referenzarchitektur

Diese Mission bildet die Ebene „Tools, APIs, Events & Workflows“. Sie ist die Brücke zwischen Agent und Fachsystemen — und ohne Identität (004) und Observability (005) nicht sicher zu betreiben.

Mission 004 Identität begrenzt Handlungsmacht Mission 006 Abhängigkeiten bleiben steuerbar