Model Context Protocol: Wann lohnt sich der Umstieg von klassischem Function Calling?
MCP wird als neuer Standard fuer AI Agents gehandelt, und zahlreiche Frameworks und Modell-Releases ruesten MCP-Server-Support nach. Ob sich die Einfuehrung lohnt, haengt vom konkreten Anwendungsfall ab: Das Protokoll verspricht eine einheitliche Schnittstelle, mit der LLMs Tools entdecken und nutzen koennen.
Wenn man in letzter Zeit Diskussionen zum Thema Agent-Engineering verfolgt hat, ist überall derselbe Hype zu sehen: MCP (Model Context Protocol) ist der neue Standard für KI-Agents. Jedes neue Framework, jede Modellveröffentlichung und jede Demo beeilt sich, MCP-Server-Support hinzuzufügen. Es verspricht einen universellen Weg, mit dem LLMs APIs, Datenbanken, Git, lokale Dateien und SaaS-Dienste entdecken und verbinden können, ohne für jedes einzelne Tool eigene Funktionsdefinitionen schreiben zu müssen.
Doch wer, wie ich, Produktions-Stacks für Agents aufbaut, weiß: Viele Teams setzen MCP aus den falschen Gründen ein. MCP und klassisches Function Calling lösen unterschiedliche Probleme. Wer das Falsche wählt, erhält unnötigen operativen Aufwand, mehr Komplexität und zusätzliche Fehlerquellen.
Klassisches Function Calling (OpenAI Function Call / Anthropic Tool Use) ist eng mit dem LLM-Prompt verknüpft. Man übergibt dem Modell zu Beginn des Prompts eine statische Liste verfügbarer Funktionen samt ihrer JSON-Schemas, Beschreibungen und Parameter. Das Modell wählt aus dieser festen Menge aus und gibt strukturiertes JSON aus, um die Funktionen aufzurufen.
Der Nachteil: Jedes neue Tool erfordert eine manuelle Aktualisierung des System-Prompts und der Schema-Definitionen. Dutzende Tools blähen das Kontextfenster auf. Die Portierbarkeit über Modelle hinweg ist schlecht. Die Funktionsschemas sind für den Tool-Parser eines Anbieters geschrieben und brechen beim Wechsel des LLM oft.
MCP kehrt dieses Modell um. Statt alle Tool-Definitionen in den Prompt einzubauen, stellen MCP-Server Tools, Ressourcen und Prompts dynamisch bereit. Der Agent kann verfügbare Tools zur Laufzeit entdecken, ihre Schemas lesen und sie über eine standardisierte JSON-RPC-Schnittstelle aufrufen. Das Modell muss nicht alle Tool-Definitionen im Vorfeld geladen haben.
Aber MCP verursacht echte Engineering-Kosten, die in den meisten Tutorials unerwähnt bleiben.
Ein MCP-Agent-Stack erfordert den Betrieb und die Wartung von MCP-Servern neben dem eigenen LLM-Dienst. Jeder Server braucht Deployment, Health Checks, Authentifizierung, Berechtigungssteuerung, Logging und Fehlerbehandlung.
Für einfache Anwendungsfälle wie den Aufruf einer einzigen REST-API zum Abrufen von Nutzerdaten ist MCP überdimensioniert. Function Calling ist leichtgewichtiger, einfacher zu debuggen und leichter zu überwachen. Eine zusätzliche MCP-Schicht bringt hier nur bewegliche Teile, mehr Fehlerquellen und Latenz.
Ein weiterer praktischer Schmerzpunkt: das Debugging. Schlägt ein Function Call fehl, untersucht man Prompt, Modellausgabe und API-Antwort direkt. Scheitert ein MCP-Agent, muss man sich durch drei Ebenen arbeiten: den LLM-Planner, den MCP-Client und den entfernten MCP-Server. Die Fehlersuche wird deutlich langsamer, besonders in der Produktion.
Hier ist die praktische Regel, die ich beim Entwurf von Agent-Workflows verwende:
MCP standardisiert die Transport- und Discovery-Schicht für Tools. Es verbessert neither das Reasoning des Modells, noch reduziert es Halluzinationen, oder macht das LLM besser darin zu entscheiden, wann ein Tool aufgerufen werden soll.
Wenn der Agent scheitert, weil das LLM das falsche Tool wählt oder ungültige Parameter übergibt, wird ein Wechsel von Function Calling zu MCP dieses Problem nicht beheben. MCP ändert nur, wie der Agent Tools aufruft, nicht das Urteilsvermögen des Modells. Das ist ein entscheidender Unterschied, der in vielem Marketing verloren geht.
MCP ist ein bedeutsamer Schritt in Richtung interoperabler Agent-Infrastruktur und wird sich als Fundament für komplexe Multi-Tool-Agentensysteme etablieren. Aber es ist kein universelles Upgrade, das Function Calling überall ersetzt.
Gutes Agent-Engineering bedeutet, die Architektur an den Umfang des Problems anzupassen. Bevor man MCP in den eigenen Stack aufnimmt, sollte man sich fragen: Brauche ich dynamisches Tool-Discovery und Portierbarkeit über Modelle hinweg? Wenn nicht, bleibt natives Function Calling einfacher, günstiger und leichter zu warten.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
If you’ve browsed agent engineering discussions recently, you’ve seen the same hype everywhere: MCP (Model Context Protocol) is the new standard for AI agents. Every new framework, model release and demo is rushing to add MCP server support. It promises a universal way for LLMs to discover and connect to APIs, databases, git, local files and SaaS services without writing custom function definitions for every single tool.
But as someone building production agent stacks, I think many teams are adopting MCP for the wrong reasons. MCP and traditional function calling solve different problems. Picking the wrong one adds unnecessary operational overhead, complexity, and failure modes.
Traditional function calling (OpenAI function call / Anthropic tool use) is tightly coupled to your LLM prompt. You hand the model a static list of available functions, their JSON schemas, descriptions and parameters at the start of the prompt. The model picks from this fixed set and outputs structured JSON to invoke them.
The downside: every new tool requires you to manually update your system prompt and schema definitions. Adding dozens of tools bloats your context window. Cross-model portability is poor. Your function schemas are written for one provider’s tool parser and often break when switching LLMs.
MCP flips this model. Instead of baking all tool definitions into the prompt, MCP servers expose tools, resources and prompts dynamically. The agent can discover available tools at runtime, read their schemas, and invoke them via a standardized JSON-RPC interface. The model does not need all tool definitions loaded upfront.
But MCP has real engineering costs most tutorials skip.
An MCP agent stack requires running and maintaining MCP servers alongside your LLM service. Every server needs deployment, health checks, authentication, permission controls, logging and failure handling.
For simple use cases like “call one REST API to fetch user data”, MCP is overkill. Function calling is lighter, simpler to debug, and easier to monitor. Adding an MCP layer here only adds extra moving parts, more points of failure and latency.
Another practical pain point: debugging. When a function call fails, you inspect the prompt, model output and API response directly. When an MCP agent fails, you need to trace across three layers: the LLM planner, the MCP client, and the remote MCP server. Troubleshooting becomes significantly slower, especially in production.
Here is the practical rule I use when designing agent workflows:
MCP standardizes the transport and discovery layer for tools. It does not improve the model’s reasoning, reduce hallucinations, or make the LLM better at choosing when to call a tool.
If your agent fails because the LLM picks the wrong tool or passes invalid parameters, switching from function calling to MCP will not fix that problem. MCP only changes how the agent invokes tools, not the model’s judgment. That’s a critical distinction lost in much of the marketing.
MCP is a meaningful step toward interoperable agent infrastructure, and it will become foundational for complex multi-tool agent systems. But it is not a universal upgrade to replace function calling everywhere.
Good agent engineering is about matching architecture to problem scope. Before adding MCP to your stack, ask yourself: do I need dynamic tool discovery and cross-model portability? If not, native function calling will remain simpler, cheaper and easier to maintain.