# Mission 003: APIs werden zu Werkzeugen

> Wie können Agenten bestehende Systeme nutzen, ohne deren Regeln zu umgehen?

**Ergebnis:** Gut beschriebene, begrenzte und beobachtbare Tools und Integrationen.

Veröffentlicht 24.06.2026 · zuletzt geändert 25.06.2026 · fachlich geprüft von Markus Berg (25.06.2026) · für Architektur, Integration, Plattform.

## 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 Einordnung:_ Ein 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.

## Zentrale 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.

## 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 Praxisbeispiel (Service-Agent)
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 durchgehenden Praxisbeispiel](https://agent-007.ai/praxis/service-agent.md)

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

## Primärquellen
- [Model Context Protocol — Spezifikation](https://modelcontextprotocol.io/specification/2025-11-25) — MCP Project (Spezifikation), geprüft 24.06.2026. Standardisierte Verbindung zwischen KI-Anwendungen, Kontextquellen und Tools.
- [Agent2Agent Protocol](https://github.com/a2aproject/A2A) — A2A Project (Spezifikation), geprüft 24.06.2026. Interoperabilität zwischen Agenten — Reifegrad und Version bei jeder Erwähnung prüfen.
- [OAuth 2.0 Security Best Current Practice (RFC 9700)](https://datatracker.ietf.org/doc/rfc9700/) — IETF (Standard / RFC), geprüft 24.06.2026. Sicherheitsleitlinien für OAuth-basierte Autorisierung der Tool-Zugriffe.



---
Quelle (kanonisch): https://agent-007.ai/missionen/003-agentic-apis-integration/