Tool Calling, Function Calling und MCP: Wie LLMs mit Software-Systemen arbeiten

Ein LLM, das nur antworten kann, ist ein Wörterbuch mit Meinungen. Ein LLM, das Software bedienen kann, ist ein produktiver Akteur. Tool Calling, Function Calling und das Model Context Protocol (MCP) sind die Schnittstellen, die diese Transformation ermöglichen. 2026 sind sie unverzichtbar für jede ernsthafte KI-Anwendung im Unternehmen. Dieser Beitrag erklärt, wie sie funktionieren und welche Disziplin sie verlangen.

1. Warum LLMs Werkzeuge brauchen

Ein LLM weiß nicht, wer heute angerufen hat. Es kennt nicht den aktuellen Lagerbestand. Es kann keine E-Mail versenden, keine Rechnung erstellen, keinen Datensatz löschen. Sein Wissen ist auf den Trainingszeitpunkt eingefroren, seine Aktion auf Textausgabe begrenzt.

Tool Calling durchbricht diese Beschränkung: Das LLM bekommt eine Liste von Werkzeugen (Funktionen, APIs, Datenbankzugriffe), die es bei Bedarf aufrufen kann. Es generiert strukturierte Aufrufe (Funktionsname + Argumente), die ein externes System ausführt. Der Output fließt zurück ins LLM, das daraus die nächste Aktion oder die finale Antwort ableitet.

Damit wird das LLM zum Reasoning-Layer über existierender Software — ein Sprachverständnis-Frontend zu jedem System, das eine API hat.

2. Function Calling — strukturierte Tool-Schnittstellen

Function Calling ist die technische Grundform. Eine Funktion wird mit einem Schema beschrieben — Name, Beschreibung, Argumente mit Typen. Das LLM erhält diese Beschreibung in seinem System-Prompt und kann bei Bedarf einen Aufruf produzieren:

{
  "name": "get_customer_by_id",
  "arguments": {
    "customer_id": "C-4711"
  }
}

Das aufrufende System validiert das Schema, führt die Funktion aus und liefert den Output strukturiert zurück:

{
  "id": "C-4711",
  "name": "Müller GmbH",
  "open_invoices": 3,
  "credit_limit": 50000
}

Das LLM nutzt das, um die ursprüngliche Frage zu beantworten oder weitere Aufrufe zu planen. Mehrere Aufrufe in Folge ergeben einen Agenten-Workflow. Siehe Was ist ein KI-Agent?.

3. Model Context Protocol — der Standard 2026

Vor MCP musste jede Tool-Integration einzeln geschrieben werden: ein Code-Stück für OpenAI, eines für Anthropic, eines für die eigene Datenbank, eines für jedes Kunden-System. Das skaliert nicht.

Das Model Context Protocol (MCP), Ende 2024 von Anthropic vorgestellt und seit 2025 breit adaptiert, standardisiert diese Verbindung. Ein MCP-Server stellt drei Klassen von Ressourcen bereit:

• Tools. Funktionen, die das LLM aufrufen kann.
• Resources. Daten, die das LLM lesen kann (Dateien, Datensätze, Dokumente).
• Prompts. Vorgefertigte Aufgabenformulierungen.

Ein MCP-Client (ein LLM-Frontend, eine Agenten-Plattform, eine Coding-IDE) kann jeden MCP-Server nutzen, ohne dafür eigenen Code zu schreiben. 2026 existiert ein wachsendes Ökosystem von MCP-Servern für GitHub, Datenbanken, Slack, Confluence, ERP-Systeme und vieles mehr.

Für Unternehmen heißt das: Ein einmal gebauter MCP-Server für ein internes System ist über alle aktuellen und zukünftigen LLM-Anwendungen hinweg nutzbar.

4. Tool Calling in Agenten-Workflows

Agenten-Workflows kombinieren mehrere Tool-Aufrufe zu einer Lösung:

1. Benutzer: „Sende dem Kunden C-4711 eine Mahnung zur offenen Rechnung.”
2. Agent ruft get_customer_by_id(C-4711).
3. Agent ruft get_open_invoices(customer_id=C-4711).
4. Agent ruft generate_dunning_letter(invoice_id=...).
5. Agent zeigt das Ergebnis und fragt nach Bestätigung.
6. Nach Bestätigung ruft Agent send_email(...).

Das Reasoning für die Schrittfolge übernimmt das LLM. Reasoning-Modelle (siehe Reasoning Models) sind hier oft deutlich besser als klassische LLMs, weil sie Pläne vor der Ausführung prüfen können.

5. Sicherheit und Permissions

Tool Calling ist eine Sicherheitsschnittstelle. Drei Prinzipien sind nicht verhandelbar:

• Least Privilege. Jedes Tool bekommt nur die minimal nötigen Rechte. Read-Only-Tools sollten read-only sein, nicht “fast read-only mit gelegentlicher Schreibrechte”.
• Permission auf Server-Seite. Das LLM ist nicht vertrauenswürdig. Berechtigungen werden vor der Ausführung im Server geprüft, nicht im Prompt suggeriert.
• Human-in-the-Loop für sensible Aktionen. Löschungen, Zahlungen, externe E-Mails, irreversible Operationen verlangen menschliche Bestätigung. Ein LLM-Ja reicht nicht.

Weiter relevant: Sandboxing der Tool-Ausführung, Rate-Limiting, Input-Validation. Siehe vertiefend Sichere KI-Integration.

6. Logging, Audit und Reproduzierbarkeit

Jeder Tool-Aufruf muss vollständig geloggt werden:

• Input des LLMs. Welcher Prompt, welcher Kontext.
• Ausgewähltes Tool und Argumente. Was wurde aufgerufen.
• Tool-Output. Welches Resultat kam zurück.
• LLM-Folgeentscheidung. Wie wurde das Resultat interpretiert.
• Metadaten. Modellversion, Zeitstempel, User, Session-ID.

Ohne dieses Logging sind Tool-Calling-Bugs schwer reproduzierbar und Audits unmöglich. In regulierten Umgebungen ist das nicht optional, sondern Compliance-Anforderung — relevant insbesondere unter dem EU AI Act.

Tracing-Tools wie OpenTelemetry mit LLM-Extensions, Langfuse oder Helicone vereinfachen das. Wer Tool Calling produktiv einsetzt, braucht sie.

7. Praxis: Integration in bestehende Stacks

Empfohlenes Vorgehen für Unternehmen:

1. Use Case identifizieren. Ein konkreter Workflow, bei dem das LLM Mehrwert liefert, wenn es Software bedient.
2. Sicherheitslandkarte zeichnen. Welche Operationen sind read-only, welche schreiben Daten, welche sind irreversibel.
3. MCP-Server für relevante Systeme bauen. Read-Only zuerst, Schreibrechte später unter Approval.
4. Eval mit echten Workflows. Test-Cases mit erwartetem Verhalten, automatisierte Validierung.
5. Logging und Audit von Anfang an. Nicht nachträglich nachrüsten.
6. Iterativ erweitern. Erst einfache Tools, dann mehrstufige Workflows, dann Agenten-Architekturen.

Tool Calling und MCP sind 2026 die kritischste Schnittstelle zwischen LLM und Unternehmenssoftware. Wer sie sauber baut, schafft die Grundlage für jede ernsthafte KI-Integration. Wer sie als Nebenbei-Funktion behandelt, baut Sicherheitslücken und unauditfähige Black Boxes. Das LLM ist nur so produktiv wie die Werkzeuge, die es nutzen darf — und die Werkzeuge sind nur so sicher, wie sie eingegrenzt sind. Mehr zum operativen Betrieb in LLMOps.