Tool Use & Model Context Protocol

Context

Dein AI-Agent kann brillante Analysen schreiben. Aber er kann keine E-Mail senden, keine Datenbank abfragen und keinen Deployment-Button druecken. Ein LLM allein generiert nur Text. Erst Tool Use macht aus einem Chatbot einen Agent, der Dinge in der echten Welt bewegen kann.

Das Problem: Bis 2024 musste jede AI-Applikation eigene Integrationen für jedes Tool bauen. 10 Apps und 10 Tools bedeuteten 100 Integrationen. Dann kam das Model Context Protocol — und veraenderte die Gleichung fundamental.

Concept

Wie Tool Use funktioniert

Ein LLM kann keine APIs aufrufen. Aber es kann strukturierte “Tool Calls” generieren — eine Kombination aus Funktionsname und Parametern. Die Host-Applikation fuehrt den Call aus und gibt das Ergebnis zurück. Das Modell reasoned dann über das Ergebnis.

Beispiel: Das Modell generiert {"tool": "get_order_status", "params": {"order_id": "12345"}}. Dein System fuehrt die Datenbankabfrage aus. Das Ergebnis geht zurück ans Modell, das daraus eine Kundenantwort formuliert.

Was MCP ist

Das Model Context Protocol (MCP) ist ein offener Standard, angekuendigt von Anthropic im November 2024, für die Verbindung von AI-Assistenten mit externen Datenquellen, Tools und Services. Die Analogie: USB-C für AI-Integrationen — ein universelles Interface statt proprietaerer Adapter.

MCP definiert drei Primitives:

Tools — Funktionen, die das Modell aufrufen kann (Code ausführen, API abfragen, E-Mail senden)
Resources — Daten, die das Modell lesen kann (Dateien, Datenbank-Records, Dokumente)
Prompts — Wiederverwendbare Prompt-Templates, die Server bereitstellen

Warum MCP gewonnen hat

Vor MCP: N Applikationen mal M Tools = N x M Integrationen. Mit MCP: N + M — jede App implementiert einen Client, jedes Tool implementiert einen Server.

Die Adoption war beispiellos schnell:

Datum	Meilenstein
Nov 2024	Anthropic kuendigt MCP an, Open-Source-Spezifikation
Maerz 2025	OpenAI adoptiert MCP für Agents SDK und ChatGPT
April 2025	Google DeepMind bestaetigt MCP-Support in Gemini
Nov 2025	MCP Spec v2025-11-25 mit Streamable HTTP Transport
Dez 2025	Anthropic uebergibt MCP an die Linux Foundation; 97M+ monatliche SDK-Downloads (laut Angaben der Linux Foundation / Anthropic, Stand Ende 2025)

Tool-Auswahl als Produktentscheidung

Zu viele Tools erhöhen Latenz (Modell muss über Optionen nachdenken), Kosten (mehr Tokens) und Angriffsflaeche. Zu wenige Tools begrenzen die Faehigkeiten.

Fuenf Prinzipien:

Read-Only zuerst — geringeres Risiko, sofortiger Wert (Suche, Lookup, Zusammenfassung)
Write-Tools inkrementell — jedes Write-Tool braucht explizite User-Bestaetigung
Tools nach Use Case gruppieren — ein Support-Toolset ist anders als ein Development-Toolset
Tool-Nutzung monitoren — ungenutzte Tools entfernen (reduziert Token-Overhead)
Für Fehler designen — jeder Tool Call kann fehlschlagen; der Agent muss Errors graceful handlen

Security-Implikationen

Tool Use eroeffnet neue Angriffsflaechen: Prompt Injection über Tool-Ergebnisse, uebermaessige Permissions, Data Exfiltration durch Agents, und Confused Deputy Attacks. Die Antwort: Principle of Least Privilege, Sandboxed Execution, Output Filtering und Audit Logging aller Tool Calls.

Framework

Das Tool-Readiness-Assessment — vor dem Shipping jedes neuen Tools durchgehen:

Dimension	Frage	Aktion
Berechtigung	Liest oder schreibt das Tool?	Read-Only zuerst shippen
Datenzugriff	Auf welche Daten greift das Tool zu?	Permission Boundaries definieren
Fehlerverhalten	Was passiert wenn das Tool fehlschlaegt?	Fallback-Verhalten designen
Autorisierung	Wer darf Write-Actions freigeben?	Approval-Anforderungen festlegen
Audit	Wie loggen wir Tool-Nutzung?	Logging vor dem Shipping planen
Latenz	Wie lange dauert ein Tool Call?	Langsame Tools optimieren oder Progress-Feedback geben

Scenario

Du bist PM für ein Enterprise-CRM mit AI-Assistent. Das Team will dem Agenten folgende Tools geben:

Read-Tools (8): Kontaktsuche, Deal-Historie, E-Mail-Verlauf, Meeting-Notizen, Pipeline-Status, Umsatzzahlen, Support-Tickets, Aktivitaets-Log

Write-Tools (6): E-Mail senden, Deal-Status ändern, Meeting einbuchen, Kontakt erstellen, Task zuweisen, Notiz hinzufuegen

Das sind 14 Tools für einen einzelnen Agent. Der erste Prototyp zeigt: Der Agent waehlt in 23% der Faelle das falsche Tool. Die durchschnittliche Antwortzeit ist 8 Sekunden — 4x langsamer als ohne Tool-Auswahl.

Die Frage: Wie strukturierst Du die Tool-Auswahl für den Launch?

Decide

Wie wuerdest Du entscheiden?

Die beste Entscheidung: Launch mit 5-6 Read-Tools. Keine Write-Tools im ersten Release. Tool-Set nach Use Case segmentieren.

Konkreter Plan:

Phase 1 (Launch): Kontaktsuche, Deal-Historie, E-Mail-Verlauf, Pipeline-Status, Support-Tickets — die 5 meistgefragten Read-Operationen
Phase 2 (nach 4 Wochen mit Daten): Notiz hinzufuegen als erstes Write-Tool (niedriges Risiko, reversibel)
Phase 3 (nach Validierung): E-Mail-Entwurf (nicht Senden!) und Meeting-Vorschlag

Warum:

14 Tools ueberfordern das Modell — unter 15 ist die Empfehlung, aber unter 8 ist besser für Genauigkeit
23% falsche Tool-Wahl bei 14 Tools sinkt auf unter 5% bei 5-6 Tools
Read-Only eliminiert das Risiko ungewollter Aktionen
Write-Tools brauchen Approval Gates — die sind noch nicht gebaut

Was viele falsch machen: Alle Tools gleichzeitig freischalten, weil “die Demo damit beeindruckender aussieht”. Das fuehrt zu Tool-Overload und Vertrauensverlust bei den ersten Fehlern.

Reflect

Tool Use verwandelt AI von einem Textgenerator in einen handlungsfaehigen Agent — aber jedes Tool ist gleichzeitig eine Faehigkeit und eine Angriffsflaeche.

MCP hat das Integrationsproblem geloest (N+M statt NxM) — nutze den Standard, bau keinen eigenen
Weniger, besser ausgewaehlte Tools schlagen mehr Tools — das Modell performed besser mit 10 als mit 50
Read-Only zuerst, Write mit Bestaetigung, immer mit Audit Trail

Quellen: Anthropic — Model Context Protocol (2024), MCP Specification v2025-11-25, The New Stack — Why MCP Won (2025), Pento — A Year of MCP (2025)