Tool-Use, Function Calling, MCP-Protokoll

Lernziele

Sie können erklären, wie KI-Modelle über Function Calling externe Werkzeuge aufrufen, und den Ablauf (Modell erkennt Bedarf → JSON-Aufruf → Ausführung → Ergebnis zurück) vollständig beschreiben.

Sie sind in der Lage, das Model Context Protocol (MCP) als Standardisierungsschicht zwischen KI-Modellen und Unternehmenssystemen zu erklären und mit dem HTTP-Protokoll zu vergleichen.

Sie können die vier Tool-Kategorien (Datenabruf, Aktion, Berechnung, Navigation) auf relevante Anwendungsfälle anwenden.

Sie sind in der Lage, die Sicherheitsimplikationen von Tool-Use zu benennen und das Least-Privilege-Prinzip auf Agenten-Tool-Zuweisungen anzuwenden.

Sie kennen die drei Sicherheitsprinzipien (Least Privilege, Tool Sandboxing, Audit Trail) und können erläutern, welches konkrete Risiko jedes Prinzip adressiert.

Sie können eine Tool-Whitelist für einen definierten Agenten nach dem Least-Privilege-Prinzip entwerfen.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

Ein Sprachmodell ist, für sich allein betrachtet, eine sehr intelligente Textverarbeitungsmaschine. Es kann erklären, zusammenfassen, umformulieren, strukturieren — aber es kann nicht auf das aktuelle Wetter schauen, keine E-Mail versenden, keine Datenbank abfragen und keinen Kalendertermin erstellen. Sein Wissen endet am Trainingsdatum, und es lebt in seiner eigenen Textblase.

Tool-Use ändert das fundamental. Durch die Fähigkeit, externe Funktionen aufzurufen, wird aus einem Textverarbeitungswerkzeug ein Handlungssubjekt. Das Modell erkennt, dass es für eine Aufgabe ein Werkzeug benötigt, formuliert einen strukturierten Aufruf, die Anwendung führt diesen Aufruf aus, gibt das Ergebnis zurück — und das Modell integriert das Ergebnis in seine Antwort.

Das Model Context Protocol (MCP), 2024 von Anthropic eingeführt und heute als offener Standard etabliert, macht diesen Mechanismus universell: So wie HTTP die Kommunikation zwischen Browser und Webserver standardisiert hat, standardisiert MCP die Kommunikation zwischen KI-Modellen und externen Systemen.

Lerntext — Theorie und Konzepte

Warum ein LLM allein nicht genug ist

Ein Large Language Model (LLM) hat drei strukturelle Einschränkungen:

Wissensschnittdatum: Das Modell kennt keine Ereignisse nach seinem Trainingsdatum.

Keine Aktionsfähigkeit: Das Modell kann keine Aktionen in externen Systemen ausführen.

Keine garantierten Berechnungen: Bei mathematischen Aufgaben kann das Modell halluzinieren. Ein Taschenrechner-Tool liefert garantiert korrekte Ergebnisse.

Tool-Use überbrückt all drei Einschränkungen.

Function Calling: Der Standardmechanismus

Function Calling ist der von OpenAI eingeführte und von der Industrie weitgehend übernommene Standard für Tool-Use. Der Ablauf in fünf Schritten:

Werkzeug-Definition: Die Anwendung erklärt dem Modell, welche Werkzeuge verfügbar sind — als JSON-Schemata (Name, Parameter, Beschreibung).

Modell erkennt Bedarf: Im Gesprächsverlauf erkennt das Modell, dass es für eine Aufgabe ein Werkzeug benötigt.

Strukturierter Aufruf: Das Modell generiert einen JSON-Funktionsaufruf mit Name und Parametern. Es führt ihn nicht selbst aus — es gibt ihn an die Anwendung weiter.

Ausführung durch Anwendung: Die Anwendung führt die Funktion aus (API-Call, Datenbankabfrage, etc.) und gibt das Ergebnis zurück.

Integration: Das Modell integriert das Ergebnis in seine nächste Antwort.

Beispiel: - Nutzer fragt: „Wie hoch ist der aktuelle EUR/USD-Kurs?” - Modell erkennt: Ich brauche das Tool get_exchange_rate - Modell generiert: {"name": "get_exchange_rate", "parameters": {"currency_pair": "EUR/USD"}} - Anwendung ruft externe Wechselkurs-API auf: Ergebnis 1.0823 - Modell antwortet: „Der aktuelle EUR/USD-Kurs liegt bei 1,0823.”

Abb. 76.1 — Function Calling Sequenz: Modell erkennt Bedarf, delegiert an Tool, integriert Ergebnis

Merksatz

Das Modell führt den Funktionsaufruf nie selbst aus — es generiert ihn nur. Die eigentliche Ausführung liegt immer bei der Anwendungsschicht. Das ist keine technische Einschränkung, sondern ein Sicherheits-Design: Der Mensch (bzw. die kontrollierende Anwendung) entscheidet, welche Werkzeuge tatsächlich verfügbar sind.

Tool-Kategorien

Datenabruf-Tools: Suche, Datenbankabfragen, API-Calls, Vektorstore-Abfragen. Der Agent liest Daten, ändert aber nichts. Geringes Risiko.

Aktions-Tools: E-Mail senden, Kalendereinträge erstellen, Dateien schreiben, Formulare ausfüllen, CRM-Daten aktualisieren. Der Agent führt irreversible oder schwer umkehrbare Aktionen aus. Hohes Risiko — besondere Sorgfalt bei der Berechtigung erforderlich.

Berechnungs-Tools: Code-Interpreter, mathematische Formeln, Datenanalyse. Der Agent nutzt rechenintensive Prozesse für zuverlässige Ergebnisse.

Navigations-Tools: Webseitennavigation, Formularausfüllung im Browser (Computer Use). Der Agent bedient grafische Oberflächen wie ein Mensch.

MCP — Model Context Protocol

Das Model Context Protocol (MCP) wurde 2024 von Anthropic entwickelt und hat sich schnell zu einem offenen Industriestandard entwickelt. Die Grundidee: Statt dass jedes KI-Produkt eigene proprietäre Schnittstellen zu jedem externen System entwickelt, gibt es eine einheitliche Protokollschicht.

Analogie: So wie HTTP die Kommunikation zwischen beliebigen Browsern und beliebigen Webservern standardisiert hat, standardisiert MCP die Kommunikation zwischen beliebigen KI-Modellen und beliebigen Werkzeugservern.

MCP-Architektur: - MCP-Server: Stellen Ressourcen und Aktionen über eine standardisierte Schnittstelle bereit. - MCP-Clients: Die KI-Modelle oder Agenten-Frameworks, die MCP-Server-Funktionen aufrufen. - Verfügbare MCP-Server: Notion, Google Drive, GitHub, Slack, Jira, HubSpot, PostgreSQL und viele weitere — als Open-Source-Implementierungen auf GitHub verfügbar.

Sicherheitsimplikationen von Tool-Use

Tool-Use bedeutet, dass KI-Agenten echte Aktionen in echten Systemen ausführen. Das ist mächtig — und gefährlich, wenn es falsch konfiguriert wird.

Least-Privilege für Tools: Jeder Agent sollte nur die Werkzeuge erhalten, die für seine konkrete Aufgabe notwendig sind.

Tool Sandboxing: Jedes Tool läuft in einer isolierten Ausführungsumgebung. Ein Tool kann keine Aktionen ausführen, die nicht explizit in seiner Schnittstelle definiert sind.

Audit Trail für Tool-Calls: Jeder Tool-Call wird mit Zeitstempel, Input-Parametern und Ergebnis-Hash protokolliert. Das ist nicht nur für die Fehlersuche wichtig — es ist die Grundlage für die EU-AI-Act-Logging-Anforderungen (UE 82).

Prompt Injection Prevention: Schädliche Anweisungen, die in externen Texten eingebettet sind, können Anweisungen an das Agenten-System enthalten. Gegenmaßnahmen: Input-Validierung vor jedem Tool-Call, strikte Schema-Validierung der JSON-Argumente, Sandboxing der Tool-Ausführung.

Merksatz

Jeder Tool-Zugriff, den ein Agent bekommt, ist eine Vertrauensentscheidung — keine technische Einstellung. Fragen Sie bei jeder Tool-Erteilung: Braucht der Agent das wirklich für seine Aufgabe? Wenn nicht: weglassen.

Vertiefung — MCP und DSGVO

Wenn ein Cloud-Modell per MCP auf personenbezogene Daten in internen Systemen zugreift, werden diese Daten an den API-Endpunkt des Modellanbieters übertragen. Für DSGVO-konformes Setup: Einsatz von Azure OpenAI Service im EU-Rechenzentrum oder eines lokalen Modells ohne Cloud-Datenübertragung. Dies ist keine theoretische Überlegung — es ist eine konkrete rechtliche Anforderung für Unternehmen, die personenbezogene Kundendaten in KI-Workflows einbinden.

MCP-Konfiguration konzeptuell (JSON-Format):

{

"agent": "angebots-assistent-v1",

"allowed_tools": [

{"name": "crm_read", "scope": "contacts,deals"},

{"name": "knowledge_base_read", "scope": "templates"},

{"name": "sharepoint_write", "scope": "/Projekte/Review-Eingang"}

],

"denied_tools": ["email_send", "crm_write", "finance_api", "hr_system"]

}

Diese Konfiguration ist versionierbar und auditierbar — sie wird in einem zentralen Tool-Registry verwaltet, nicht ad hoc im Systemprompt versteckt. Für jeden Agenten empfiehlt sich ein kurzes Dokument (Tool-Passport), das erlaubte und gesperrte Tools, Zugriffsscope und Begründung dokumentiert.

Tool-Restriktion als Governance-Entscheidung ist aus drei Perspektiven zu beantworten:

Datenschutzperspektive (DSGVO Art. 5): Der Agent darf nur auf personenbezogene Daten zugreifen, die für seine konkrete Aufgabe notwendig sind (Datensparsamkeit).

Sicherheitsperspektive (Least Privilege): Jedes gewährte Tool ist eine potenzielle Angriffsfläche. Ein Angreifer, der den Agenten per Prompt Injection manipuliert, kann nur die Tools missbrauchen, auf die der Agent Zugriff hat.

Qualitätsperspektive (Fokus): Agenten mit zu vielen Tools verlieren an Präzision.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

Ein IT-Beratungsunternehmen entwickelt einen Angebots-Assistenten mit MCP-Anbindung an CRM, Projektdokumentation und E-Mail-Archiv. Die Tool-Whitelist ist bewusst eng gehalten: CRM lesen (Kundendaten, Projekthistorie), Wissensbasis lesen (Angebotsvorlagen, Lessons Learned), E-Mail-Archiv lesen (Kommunikationshistorie mit dem Kunden) und PDF-Generator (Angebotsdokument erstellen). Explizit gesperrt: E-Mail senden (Angebot wird nur erstellt, nicht direkt versendet), CRM schreiben (keine automatischen Datenänderungen), Finanzsystem (kein Zugriff auf Preislisten oder Buchhaltung). Das Ergebnis: Der Agent erstellt in 3–5 Minuten einen personalisierten Angebotsentwurf, der früher 90 Minuten manueller Arbeit erforderte — unter vollständiger menschlicher Kontrolle vor dem Kundenkontakt.

Industrie & Fertigung

Ein Fertigungsunternehmen setzt einen Wartungs-Planungs-Agenten ein, der via MCP auf Anlagendaten, Ersatzteilbestand und Kalender zugreift. Function Calling ermöglicht dem Agenten, den aktuellen Betriebszustand einer Anlage abzufragen, verfügbare Servicetechniker zu prüfen und Wartungsfenster zu identifizieren. Das Ergebnis ist ein Wartungsplan-Entwurf — der Wartungsleiter gibt ihn frei, bevor er in das Planungssystem übertragen wird. Die Reversibilitäts-Matrix: Lese-Tools (Anlagenstatus, Kalender) = niedrig; Schreibtools im Planungssystem = mittel; Benachrichtigung an externe Dienstleister = hoch. Nur die ersten beiden Tool-Kategorien sind dem Agenten zugänglich.

Finanzdienstleistung & Versicherung

Eine Bank verwendet Function Calling für einen Beratungs-Assistenten, der Finanzberater bei der Kundenvorbereitung unterstützt. Der Agent kann Kundendepots lesen (nur mit expliziter Kundenzustimmung), aktuelle Marktdaten abrufen und Produktdokumentation durchsuchen. Explizit gesperrt sind alle Schreiboperationen auf Kundendepots oder Auftragsplatzierungen. Die regulatorische Anforderung: Jeder Tool-Call wird vollständig geloggt — Zeitstempel, genutztes Tool, Parameter (anonymisiert), Ergebnis-Hash — und ist für Compliance-Prüfungen durch die BaFin abrufbar.

Öffentliche Verwaltung

Eine Kommunalverwaltung implementiert einen Akten-Recherche-Assistenten mit MCP-Anbindung an das Dokumentenmanagementsystem. Der Agent kann Akten nach Stichworten durchsuchen, relevante Vorschriften aus der Rechtsvorschriften-Datenbank abrufen und Präzedenzfälle aus der Entscheidungsdatenbank finden. Er kann keine Akten verändern, keine Bescheide erstellen und keine Kommunikation an Bürgerinnen und Bürger auslösen. Die Nutzung ist auf angemeldete Sachbearbeiter beschränkt, jede Suchanfrage wird pseudonymisiert geloggt. Der Datenschutzbeauftragte hat das Tool-Passport vor der Inbetriebnahme geprüft und freigegeben.

Übung 1 — Tool-Kategorisierung und Risikoeinschätzung

Aufgabe: Sie erhalten eine Liste von zehn möglichen Tools für einen Agenten und kategorisieren jedes Tool nach Tool-Typ und Risikostufe (niedrig / mittel / hoch).

Material: Tool-Liste (unten), Tool-Kategorien aus dem Lerntext.

Schritt-für-Schritt: 1. Lesen Sie alle zehn Tools sorgfältig. 2. Ordnen Sie jedes Tool einer der vier Kategorien zu (Datenabruf / Aktion / Berechnung / Navigation). 3. Bewerten Sie das Risiko: Niedrig (leicht rückgängig machbar, nur lesend), Mittel (schwer rückgängig, interner Effekt), Hoch (irreversibel, externer Effekt). 4. Begründen Sie Ihre Risikobewertung für die drei Tools mit der höchsten Risikostufe.

Tools: 1) Kundendaten aus CRM lesen; 2) E-Mail im Namen eines Beraters senden; 3) Neue Zeile in SharePoint-Liste schreiben; 4) Websuche nach Firmennews; 5) Angebots-PDF generieren und in SharePoint speichern; 6) Kalendertermin erstellen; 7) Projektbudget in Finanzsystem aktualisieren; 8) Interne Wissensbasis durchsuchen; 9) Slack-Nachricht senden; 10) Vertragstext in CRM-Feld überschreiben

Musterlösung:

Übung 2 — MCP-Konzept: Tool-Whitelist für einen Agenten entwerfen

Aufgabe: Sie entwerfen die Tool-Whitelist für einen konkreten Agenten (Angebots-Assistent) nach dem Least-Privilege-Prinzip: Welche Tools bekommt er — und welche explizit nicht?

Schritt-für-Schritt: 1. Definieren Sie die Aufgabe des Agenten in einem Satz. 2. Listen Sie alle Tools auf, die für diese Aufgabe theoretisch nützlich sein könnten. 3. Prüfen Sie jedes Tool: Ist es für die definierte Aufgabe wirklich notwendig? 4. Erstellen Sie zwei Listen: „Erlaubte Tools (mit Begründung)” und „Explizit gesperrte Tools (mit Begründung)“. 5. Definieren Sie für jeden erlaubten Aktions-Tool die Bedingung: Unter welcher Voraussetzung darf der Agent dieses Tool ausführen?

Musterlösung:

Aufgabe: „Der Angebots-Assistent erstellt auf Basis von Kundendaten und Projektvorlagen einen Angebotsentwurf zur menschlichen Review.”

Erlaubte Tools: - CRM lesen (Kundendaten, Gesprächshistorie) — notwendig für Personalisierung - Wissensbasis lesen (Projektvorlagen, bisherige Angebote) — notwendig für Vorlagen - E-Mail-Archiv lesen (E-Mail-Historie mit Kunden) — notwendig für Kontext - PDF-Generator (Angebotsdokument erstellen) — notwendig für Output - SharePoint schreiben (Entwurf in Review-Ordner ablegen) — nur in designierten Ordner

Explizit gesperrte Tools: - E-Mail senden — Angebot wird nur zur Review abgelegt, nicht direkt gesendet - CRM schreiben — Keine Änderung von Kundenstammdaten - Finanzsystem — Kein Zugriff auf Buchhaltung oder Pricing-Systeme

Promptbaustein — Function-Calling-Schema und Tool-Passport entwerfen

Rolle: Sie sind ein KI-Systemarchitekt mit Spezialisierung auf sichere Agenten-Architekturen und DSGVO-konforme Tool-Integration.

Aufgabe: Entwerfen Sie für den folgenden KI-Agenten ein vollständiges Function-Calling-Schema und ein Tool-Passport-Dokument: [Agenten-Beschreibung einfügen — z. B. „Recherche-Agent für Kundenvorbereitung: liest CRM, Branchennews und interne Projekthistorie”].

Ziel: Ein einsatzbereites JSON-Schema für zwei bis drei Kern-Tools des Agenten sowie ein kurzes Tool-Passport-Dokument (max. eine Seite), das für Compliance-Prüfungen geeignet ist.

Kontext: Der Agent läuft auf Azure OpenAI Service (EU-Rechenzentrum) und greift auf Microsoft-365-Systeme zu. Datenschutz und Least-Privilege sind Pflichtanforderungen.

Output: 1. JSON-Schema für zwei bis drei Tools im OpenAI Function-Calling-Format (name, description, parameters mit type und required) als Codeblock. 2. Tool-Passport: erlaubte Tools mit Scope, explizit gesperrte Tools mit Begründung, DSGVO-Einschätzung (welche Datenkategorien werden verarbeitet?). 3. Eine Sicherheitsempfehlung: Welches Tool ist das kritischste — und welche Kontrollmaßnahme ist dafür notwendig?

Hinweis: Schreiben Sie das JSON-Schema so, dass ein Entwickler es direkt als Ausgangspunkt nutzen kann.

Cheatsheet — Die wichtigsten Punkte

Function Calling: Modell → JSON-Aufruf → Anwendung führt aus → Ergebnis zurück → Modell integriert

MCP: Universelles Protokoll für KI-zu-Tool-Kommunikation (wie HTTP für Browser-zu-Server)

Vier Tool-Kategorien: Datenabruf (sicher) / Aktion (Vorsicht) / Berechnung / Navigation

Least Privilege: Jeder Agent bekommt nur die Tools, die er wirklich braucht

Aktions-Tools sind heiß: E-Mails senden, Daten überschreiben, externe Systeme — immer kritisch prüfen

Prompt Injection: Externe Texte können Anweisungen an den Agenten enthalten — Validierung wichtig

MCP-Server existieren bereits: HubSpot, Notion, GitHub, Slack — einsatzbereit als Open Source

Tool-Passport: Dokumentiert erlaubte und gesperrte Tools, Zugriffsscope und Begründung

Reflexionsfragen

Welche drei Systeme in Ihrer Organisation hätten den größten Nutzen, wenn sie über MCP-Server für einen KI-Agenten zugänglich wären — und welche Tools sollten diese Server anbieten?

Was passiert, wenn ein Agent mit zu weitreichenden Tool-Berechtigungen versehen wird? Beschreiben Sie ein konkretes Schadensszenario.

Wie würden Sie einem Kunden erklären, dass ein KI-Agent zwar Daten aus seinem CRM lesen kann, aber nie direkt in seinem Namen E-Mails versenden wird?

Welche Beziehung besteht zwischen dem MCP-Protokoll und den DSGVO-Grundsätzen der Datenminimierung und Zweckbindung?

Ein Anbieter wirbt damit, dass sein KI-Agent „auf alle Ihre Unternehmensdaten zugreifen” kann. Was sind Ihre ersten drei Fragen an diesen Anbieter?

Quellen & Weiterlesen

Hinweise für AI Champions — So vermitteln Sie das Thema — UE 76

Timing (45 Min): 5 Min Einstieg (Frage: „Was kann ein LLM allein NICHT tun?“), 15 Min Input Function Calling + MCP + Tool-Kategorien + Sicherheit, 5 Min Live-Demo (Function-Calling-Ablauf auf dem Beamer visualisieren, JSON-Aufruf zeigen), 15 Min Übung 1 + 2, 5 Min Reflexion + Übergang.

Methodische Empfehlung: Die Sequenz „Modell → JSON-Aufruf → Ausführung → Ergebnis” sollte visuell dargestellt werden — als Sequenzdiagramm an der Tafel oder als animierte Folie. Dieser Mechanismus ist der konzeptionelle Kern der gesamten Agentenarchitektur.

Häufige Stolpersteine: (a) Teilnehmende denken, das Modell führt die Aktion selbst aus — explizit klarstellen: Das Modell generiert nur den Aufruf. (b) MCP wirkt abstrakt — konkretes Beispiel (Claude Desktop + GitHub-MCP-Server) zeigen. (c) Die Risikoeinschätzung in Übung 1 wird zu schnell ausgefüllt — auf Begründungstiefe bestehen.

Diskussionsfragen: (1) „Welchen Tool-Aufruf würden Sie für Ihren Agenten niemals freigeben — und warum?” (2) „Was ist der Unterschied zwischen einem Agent, der E-Mails entwerfen darf, und einem, der E-Mails versenden darf?”

Tafelbild-Vorschlag: Function-Calling-Sequenz als Pfeildiagramm: Nutzer → LLM → JSON → Anwendung → API → Ergebnis → LLM → Antwort.

Differenzierung Power-User ↔ Einsteiger: - Einsteiger: Tool-Kategorisierung und Risikoeinschätzung, MCP-Konzept verstehen. - Power-User: JSON-Schema für ein eigenes Tool selbst schreiben (als Vorlage), MCP-Server-Repository auf GitHub erkunden.

Tipp zur Branchenauswahl: Für IT-Beratungsgruppen: Angebots-Assistent-Szenario ist sehr nah an der Realität. Für Finanzgruppen: Beratungs-Assistent mit regulatorischen Anforderungen besonders relevant. Für Verwaltungsgruppen: Akten-Recherche-Assistent passt gut.

Übergang zur nächsten UE: „Jetzt wissen Sie, wie Agenten mit Werkzeugen kommunizieren. In UE 77 schauen wir uns die Wissensbasis hinter Agenten an — wie Retrieval-Augmented Generation (RAG) funktioniert und wie Organisationen ihr internes Wissen für KI-Systeme zugänglich machen.”

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.