MCP vs Function Calling vs Tools: Unterschied 2026

Pexon Consulting | 9 Min. Lesezeit | 15.07.2026

TL;DR

Function Calling, Tools und MCP sind keine Konkurrenten, sondern drei Ebenen derselben Sache: wie ein Sprachmodell an Werkzeuge kommt. Function Calling ist die Modell-native Fähigkeit, Tools ist die Abstraktion im Framework, MCP das offene Protokoll zur Server-Anbindung. Wir bei Pexon (80 Mitarbeiter, Microsoft Partner) bauen genau diese Schichtung produktiv. Dieser Text klärt, was wann greift.

Warum die Begriffe ständig durcheinandergehen

Die drei Wörter beschreiben unterschiedliche Ebenen, werden aber synonym benutzt, und das produziert falsche Architektur-Entscheidungen. Wer glaubt, MCP ersetze Function Calling, baut die falsche Abstraktion. Wer glaubt, „Tools“ sei ein Standard, wundert sich über Vendor-Lock-in. Sortieren wir das.

Der Kern des Missverständnisses: Alle drei drehen sich um dieselbe Grundidee. Ein Sprachmodell kann nur Text erzeugen. Damit es etwas tut, also eine Datenbank abfragt, eine Rechnung zieht oder ein Ticket anlegt, braucht es einen Weg, strukturierte Aufrufe an echten Code zu delegieren. Function Calling, Tools und MCP sind drei Antworten auf dieselbe Frage, aber auf drei verschiedenen Stockwerken.

Wir sehen das in Projekten regelmäßig: Ein Team diskutiert „MCP oder Function Calling“, als wäre das eine Entweder-oder-Frage. Ist es nicht. Ein typischer Produktiv-Stack nutzt alle drei gleichzeitig. Genau darum lohnt es, die Ebenen sauber zu trennen, bevor irgendein Code entsteht.

Function Calling: die Modell-native Ebene

Function Calling ist die Fähigkeit eines Sprachmodells, aus einer Nutzer-Anfrage einen strukturierten Werkzeug-Aufruf zu erzeugen. Das Modell bekommt Tool-Schemas als JSON mitgeschickt, entscheidet selbst, ob und welches Tool passt, und liefert Namen plus Argumente zurück. Ausführen tut den Aufruf dein eigener Code, nicht das Modell.

Das ist eine Eigenschaft des Modells selbst. Anthropics claude-sonnet-5 (allgemein verfügbar seit 30. Juni 2026) und claude-opus-4-8 können das nativ, genauso wie OpenAIs und Googles aktuelle Modelle. Du definierst die Funktion, das Modell übersetzt „Wie ist der Status von Auftrag 4711?“ in einen Aufruf get_order_status(order_id="4711").

Der Haken: Es gibt keinen gemeinsamen Standard. Jeder LLM-Anbieter hat ein eigenes Schema-Format, eigene Feldnamen und eigene Response-Struktur. Wer heute drei Modelle unterstützen will, schreibt drei Varianten desselben Tool-Codes. Genau diese Fragmentierung ist der Grund, warum die höheren Ebenen überhaupt entstanden sind.

Unsere klare Position: Für einen einzelnen Agenten mit einer Handvoll interner Tools ist reines Function Calling der pragmatischste Weg. Kein Server, keine Extra-Infrastruktur, du iterierst in Minuten. Erst wenn Tools geteilt, entdeckt oder unabhängig verwaltet werden sollen, wird es zu wenig.

Tools: die Framework-Abstraktion

„Tools“ ist kein Protokoll und kein Modell-Feature, sondern ein Abstraktions-Begriff aus Agent-Frameworks und SDKs. Ein Tool ist die einheitliche Darstellung einer Fähigkeit im Code, meist eine dekorierte Funktion mit Name, Beschreibung und Schema, die das Framework dann in das jeweilige Function-Calling-Format des Modells übersetzt.

Das ist die Ebene, auf der Entwickler am meisten Zeit verbringen. Frameworks wie das Anthropic SDK, LangChain oder LlamaIndex kapseln die Anbieter-Fragmentierung von Function Calling weg. Du schreibst ein Tool einmal, das Framework kümmert sich um das Schema-Mapping pro Modell. Der Vorteil ist Bequemlichkeit, der Preis ist Framework-Bindung: Ein LangChain-Tool läuft nicht ohne Weiteres in einem fremden Runtime.

Wichtig zu verstehen: Tools lösen die Anbieter-Fragmentierung, aber nur innerhalb eines Frameworks. Das Tool selbst bleibt in deinem Anwendungscode eingebacken. Wer dasselbe Werkzeug in einer zweiten Anwendung braucht, kopiert oder importiert es. Genau hier setzt MCP an, eine Ebene höher.

MCP: das offene Anbindungs-Protokoll

MCP (Model Context Protocol) ist ein offener Standard, der definiert, wie KI-Anwendungen zur Laufzeit Tools und Datenquellen entdecken und nutzen. Statt Tools in jede Anwendung einzubacken, laufen sie in einem eigenen MCP-Server, den jeder MCP-Client anspricht, unabhängig davon, welches Modell darunter arbeitet. Ein Server, viele Clients.

Der Standard kommt ursprünglich von Anthropic (November 2024) und liegt inzwischen bei der Linux Foundation. Die stabile MCP-Spezifikation trägt die Version 2025-11-25. Der nächste Release Candidate ist auf den 28. Juli 2026 datiert und bringt einen zustandslosen Protokoll-Kern, ein Extensions-Framework, Tasks und MCP Apps. Das Ökosystem zählte im März 2026 über 97 Mio. SDK-Downloads pro Monat und mehr als 81.000 GitHub-Stars.

Der entscheidende Unterschied zu den unteren Ebenen: MCP entkoppelt das Werkzeug von der Anwendung. Ein MCP-Server, der Zugriff auf euer SAP oder Confluence gibt, funktioniert mit Claude Desktop, mit einem eigenen Chatbot und mit einem Copilot-Agenten, ohne dass ihr den Server anfasst. Der Client fragt per tools/list, welche Werkzeuge existieren, und nutzt sie.

MCP ersetzt Function Calling nicht, es baut darauf auf. Wenn ein MCP-Client dem Modell die verfügbaren Server-Tools präsentiert, geschieht die eigentliche Entscheidung „welches Tool jetzt“ weiterhin per Function Calling im Modell. MCP regelt Discovery, Transport und Ausführung drumherum. Deshalb ist die Frage „MCP oder Function Calling“ falsch gestellt.

Der direkte Vergleich

Die drei Ebenen unterscheiden sich vor allem in Reichweite und Wiederverwendbarkeit. Function Calling ist Modell-nah und app-lokal, Tools sind framework-lokal, MCP ist app-übergreifend. Je weiter oben, desto mehr Standardisierung, aber auch mehr Infrastruktur.

Kurz gesagt: Function Calling ist die Fähigkeit, Tools ist die Bequemlichkeit, MCP ist die Standardisierung. Wer nur eine App baut, braucht MCP oft nicht. Wer mehrere KI-Anwendungen an dieselben Datenquellen hängt, spart sich mit MCP das klassische N-mal-M-Integrationsproblem.

Code: Function Calling gegen MCP-Server

Am Code wird der Unterschied greifbar. Zuerst definierst du das Tool direkt für einen Modell-Aufruf, danach verpackst du dieselbe Fähigkeit in einen MCP-Server, den beliebige Clients nutzen. Beide Beispiele nutzen Python und sind lauffähig.

# EBENE 1: Function Calling direkt gegen das Modell (Anthropic SDK)
# Das Tool-Schema wird pro Aufruf mitgeschickt, Ausführung im eigenen Code.
from anthropic import Anthropic

client = Anthropic()

# Tool-Definition als Schema, das Modell entscheidet über den Aufruf
tools = [{
    "name": "get_order_status",
    "description": "Auftragsstatus aus dem ERP abfragen",
    "input_schema": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
    },
}]

msg = client.messages.create(
    model="claude-sonnet-5",  # Modell mit nativem Function Calling
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "Status von Auftrag 4711?"}],
)
# msg enthält jetzt einen tool_use-Block: get_order_status(order_id="4711")
# Die eigentliche ERP-Abfrage machst DU, das Modell ruft nur strukturiert auf.

# EBENE 3: Dieselbe Fähigkeit als MCP-Server (FastMCP v3.4.4, Stand Juli 2026)
# Ein Server, den JEDER MCP-Client nutzt, unabhängig vom Modell.
from fastmcp import FastMCP

mcp = FastMCP("erp-connector")

@mcp.tool()
def get_order_status(order_id: str) -> dict:
    """Auftragsstatus aus dem ERP abfragen.

    Jeder MCP-Client entdeckt dieses Tool zur Laufzeit per tools/list,
    ohne eigenen Adapter. Kein anbieterspezifisches Schema nötig.
    """
    # In der Praxis hier der REST-Call an SAP, Dynamics oder vergleichbar
    return {"order_id": order_id, "status": "in Zustellung"}

if __name__ == "__main__":
    mcp.run(transport="stdio")  # läuft mit Claude Desktop, Copilot, eigenem Bot

Der Aha-Moment: Das Function-Calling-Beispiel lebt in genau einer Anwendung. Der MCP-Server lebt für sich und bedient beliebig viele. Genau das ist der Sprung von Ebene 1 zu Ebene 3. Und in beiden Fällen bleibt die Tool-Auswahl selbst Function Calling im Modell.

Wann was: unsere Empfehlung

Es gibt keine universell richtige Ebene, es gibt die passende pro Situation. Wir raten, unten zu starten und nur so weit nach oben zu gehen, wie der Nutzen es rechtfertigt. Jede Ebene höher kostet Infrastruktur, die sich erst ab einer gewissen Wiederverwendung amortisiert.

Für einen Prototyp oder einen einzelnen Agenten mit wenigen eigenen Tools: reines Function Calling, notfalls über das SDK-Tool-Konstrukt. Kein MCP, kein Server, keine Governance-Diskussion. Wer hier MCP aufsetzt, over-engineered. Das ist verschenkte Zeit.

Sobald mehrere KI-Anwendungen dieselben Datenquellen brauchen, dreht sich die Rechnung. Drei Apps auf acht Systemen ergeben ohne MCP 24 Einzelintegrationen, mit MCP acht Server, die alle Apps teilen. Ab diesem Punkt ist MCP die naheliegende Wahl, nicht wegen des Hypes, sondern wegen der Integrationsmathematik. In der Praxis kombinieren gute Systeme ohnehin beides: Function Calling für app-spezifische Kernlogik, MCP für generische, geteilte Fähigkeiten.

Wie MCP sich wiederum von klassischen Integrationsplattformen abgrenzt, also die Frage nach REST-API und iPaaS statt Tool-Anbindung, behandeln wir separat in unserem Beitrag zu den Integrationsansätzen für KI-Projekte 2026. Für die Orchestrierung mehrerer Agenten über diese Tools hinweg lohnt ein Blick auf unseren Hub zur Orchestrierung von KI-Agenten.

Häufig gestellte Fragen

Ersetzt MCP Function Calling?

Nein. MCP baut auf Function Calling auf. Der MCP-Client präsentiert dem Modell die verfügbaren Server-Tools, die Entscheidung welches Tool aufgerufen wird passiert weiterhin per Function Calling im Modell. MCP regelt Discovery, Transport und Ausführung drumherum, nicht die Tool-Auswahl selbst.

Was ist der Unterschied zwischen Tools und Function Calling?

Function Calling ist die Modell-native Fähigkeit, strukturierte Aufrufe zu erzeugen. „Tools“ ist die Abstraktion in einem Framework oder SDK, die dieses Function Calling bequem und anbieterübergreifend macht. Function Calling ist die Ebene darunter, Tools verpacken sie.

Brauche ich MCP für einen einfachen Chatbot?

In der Regel nein. Für einen einzelnen Agenten mit wenigen internen Tools reicht Function Calling. MCP lohnt sich, sobald mehrere Anwendungen dieselben Werkzeuge oder Datenquellen teilen sollen. Vorher setzt du nur unnötige Server-Infrastruktur auf.

Wie aktuell ist der MCP-Standard 2026?

Die stabile Spezifikation ist Version 2025-11-25. Der nächste Release Candidate ist auf den 28. Juli 2026 datiert und bringt einen zustandslosen Kern, Extensions, Tasks und MCP Apps. Das Ökosystem hatte im März 2026 über 97 Mio. monatliche SDK-Downloads.

Was kostet die Einführung von MCP im Unternehmen?

Die MCP-SDKs sind Open Source und kostenlos. Kosten entstehen bei Server-Entwicklung (pro Datenquelle meist 2 bis 5 Tage) und Governance. Für ein Setup mit fünf Datenquellen inklusive Sicherheitskonzept und Tests kalkulieren wir grob 15.000 bis 25.000 Euro.

Nächster Schritt

Bevor ihr euch auf eine Ebene festlegt, lohnt ein kurzer Blick von außen auf euren geplanten Use-Case. Genau das machen wir in einem Workshop, ohne Powerpoint.

Verwandte Themen