Braucht deine LLM-App wirklich MCP? MCP vs. CLI vs. Function Calling

In Entwickler-Chats taucht immer öfter dieselbe Frage auf: Ich baue ein LLM-Feature, das eine Datenbank abfragen oder einen Deployment-Befehl ausführen soll — brauche ich dafür sofort einen MCP-Server? Manchmal ja. Häufiger lautet die ehrliche Antwort: noch nicht.

MCP, das Model Context Protocol, ist wertvoll, weil es KI-Anwendungen einen Standardweg gibt, Tools, Ressourcen und Prompts zu entdecken und zu nutzen. Die offizielle Dokumentation beschreibt MCP als offenen Standard für die Verbindung von KI-Anwendungen mit externen Systemen. Das ist nützlich, aber nicht automatisch die richtige erste Abstraktion.

Beginne mit der Integrationsfläche

Function Calling, CLI-Ausführung und MCP lösen dasselbe Grundproblem: Das Modell braucht sichere, strukturierte Fähigkeiten. Der Unterschied ist, wo der Vertrag lebt.

Bei nativem Function Calling liegt der Vertrag in deiner App. Du definierst Schemata, empfängst Tool-Aufrufe, führst serverseitigen Code aus und gibst Ergebnisse zurück. Das ist direkt, gut debugbar und oft der schnellste Weg in Produktion.

Bei einer CLI-Schicht ist der Vertrag ein ausführbarer Befehl. Tests, Type Checks, Migrationen, Infrastrukturpläne und Repository-Suche sind bereits kommandoförmig. Die richtige Architektur ist kein offenes Shell-Fenster, sondern ein enger Broker mit Allowlist, Timeouts, Validierung, Output-Limits und Logging.

Bei MCP wird der Vertrag zu einem Protokoll zwischen Client und Server. Das lohnt sich vor allem, wenn dieselbe Fähigkeit mehrere KI-Clients, Teams oder Laufzeiten bedienen soll.

Wann Function Calling reicht

Für die erste Version einer Produktfunktion ist Function Calling meist der beste Standard. Authentifizierung, Logging, Rate Limits, Mandantenfähigkeit und Incident Response bleiben in der Anwendungsgrenze, die du schon betreibst.

Wenn die Tools produktspezifisch sind — etwa Bestellungen nachschlagen, Rückerstattungen vorbereiten oder Kontohistorien zusammenfassen — ist MCP am Anfang oft zusätzliche Komplexität ohne klaren Nutzen.

Das Problem entsteht später: mehrere Teams implementieren dieselben Tools in mehreren Hosts. Dann wächst Integrations-Sprawl, und MCP wird interessant.

Wann eine CLI besser ist

Für Coding Agents und Infrastruktur-Workflows sind CLIs oft die ehrlichste Schnittstelle. Sie sind lokal reproduzierbar, nutzen bestehende Projektkonventionen, liefern menschlich lesbare Logs und scheitern mit Exit Codes.

Wenn ein Workflow bereits kommandonativ ist, kapsle zuerst die CLI. Gib dem Modell strukturierte Zusammenfassungen, bewahre Rohlogs für Menschen auf und behandle Shell-Zugriff wie Produktions-Schreibzugriff.

Wann MCP die Komplexität verdient

MCP lohnt sich, wenn dieselbe Fähigkeit in mehreren KI-Umgebungen verfügbar sein soll: Knowledge-Base-Suche, Repository-Kontext, Design-Systeme, Datenbank-Metadaten oder Audit-Logs. Dann kann ein Team den Server besitzen und viele Anwendungen konsumieren ihn.

Das passt zu den Mustern aus unserem MCP-Produktionsleitfaden und zur SaaS-Perspektive in MCP SaaS integration strategy.

MCP löst aber keine Sicherheits- und Betriebsfragen automatisch. Authentifizierung, Autorisierung, Secrets, Rate Limits, Telemetrie, Schema-Versionierung und sichere Fehler bleiben deine Verantwortung.

Die praktische Regel

Ein Client und produktspezifische Logik: Function Calling. Ein bestehender, menschenfreundlicher Workflow: CLI-Broker. Mehrere KI-Clients, verteilte Ownership und stabile Tools: MCP.

Die beste Architektur ist nicht die neueste. Es ist die mit den wenigsten Grenzen, die trotzdem Sicherheit, Observability und einen sauberen Weg zur Wiederverwendung bietet.