MCP vs. OpenAPI: Wann brauche ich was?

MCP (Model Context Protocol) und OpenAPI/Function-Calling sind zwei Wege, KI-Agenten an externe Tools anzubinden. OpenAPI beschreibt klassische REST-Schnittstellen, die per Function-Calling fest in den Agenten eingebaut werden. MCP ist ein offener Standard für dynamische Tool-Discovery über viele Clients hinweg. MCP lohnt sich bei vielen Agenten und wechselnden Tools, OpenAPI bei einer abgegrenzten, stabilen Integration.

• OpenAPI/Function-Calling ist die pragmatische Wahl, wenn ein einzelner Agent eine kleine, stabile Tool-Menge nutzt und du der einzige Konsument bist.
• MCP lohnt sich, sobald mehrere Clients dieselben Tools brauchen, das Tool-Set wächst oder sich Tools zur Laufzeit ändern sollen (dynamische Discovery).
• Beides zusammen ist der Normalfall: Ein MCP-Server kapselt häufig genau die per OpenAPI dokumentierten REST-APIs und macht sie agentenfähig.

Worum geht es eigentlich: Tool-Anbindung für Agenten

Ein KI-Agent ist ein LLM, das in einer Schleife Tools nutzt. Die zentrale Architekturfrage lautet nicht „MCP oder OpenAPI“ im Sinne eines Entweder-oder, sondern: Wie kommt mein Agent zuverlässig, sicher und wartbar an externe Funktionen? Dafür gibt es zwei Denkschulen.

Klassisches Function-Calling mit OpenAPI. Du beschreibst deine Funktionen als Tool-Schema (Name, Parameter, Typen, Beschreibung) und übergibst dieses Schema direkt im API-Call an das Modell. Häufig wird das Schema aus einer bestehenden OpenAPI-Spezifikation generiert, also aus der maschinenlesbaren Beschreibung einer REST-Schnittstelle. Das Modell entscheidet, welche Funktion mit welchen Argumenten aufgerufen wird; dein Code führt den eigentlichen HTTP-Request aus und gibt das Ergebnis zurück. Das ist direkt, transparent und braucht keine zusätzliche Infrastruktur.

MCP: Model Context Protocol. Anthropic stellte MCP am 25. November 2024 als offenen Standard vor, um KI-Anwendungen mit externen Systemen wie Dateisystemen, Datenbanken, Business-Systemen und Dev-Tools zu verbinden. Technisch basiert MCP auf JSON-RPC 2.0 über mehrere Transporte: stdio für lokale Server, ursprünglich Server-Sent Events und seit der Spec-Revision vom März 2025 (2025-03-26) Streamable HTTP. Dieselbe Revision ergänzte OAuth-2.1-Support und Tool-Annotations. Das ebenfalls neu eingeführte JSON-RPC-Batching hat die Spec 2025-06-18 wieder entfernt. Die Spec vom November 2025 brachte unter anderem experimentelle Tasks für asynchrone Operationen und Client-ID-Metadata-Documents für die Client-Registrierung. Mit der Spec 2026-07-28 wurde MCP zustandslos: Der Initialize-Handshake entfällt, und jeder Server muss seine Protokollversionen, Capabilities und Identität über die Methode server/discover ausweisen. Statt das Tool-Schema fest im Agenten zu hinterlegen, fragt ein MCP-Client den Server zur Laufzeit: „Welche Tools, Ressourcen und Prompts hast du?“

Der Unterschied klingt klein, ist aber strukturell: OpenAPI/Function-Calling bindet Tools statisch in den Client, MCP entkoppelt Tools als wiederverwendbaren Server vom Client.

Die fünf Entscheidungsdimensionen

1. Discovery: statisch vs. dynamisch

Beim reinen Function-Calling kennt der Agent nur die Tools, die du ihm beim Aufruf mitgibst. Kommt ein Tool hinzu, änderst du Code. Bei MCP fragt der Client die Capabilities zur Laufzeit ab, neue Tools auf dem Server stehen ohne Code-Änderung bereit. Das ist der namensgebende Vorteil von MCP für „viele, wechselnde Tools“.

2. Statefulness

OpenAPI-Calls sind per Definition zustandslose HTTP-Requests. MCP-Sessions waren ursprünglich zustandsbehaftet (eine offene Verbindung mit Kontext). Mit Streamable HTTP wurde die Session-ID optional, Server konnten also schon ab März 2025 ohne Session laufen. Die Spec 2026-07-28 macht MCP grundsätzlich stateless: Sessions und Initialize-Handshake entfallen, jeder Request trägt Protokollversion und Client-Capabilities selbst. Zustand über mehrere Aufrufe hält der Server über explizite Handles, die als normale Tool-Argumente mitgehen. Das erleichtert horizontale Skalierung und Serverless-Deployments.

3. Standardisierung und Ökosystem

Hier liegt MCPs stärkstes Argument. OpenAI hat MCP im März 2025 adoptiert, Google DeepMind im April 2025, dazu Microsoft Copilot Studio, Cursor, Zed, Windsurf, Replit, Sourcegraph, Block und Dutzende mehr. Die SDKs melden 97M+ monatliche Downloads über Python und TypeScript; Anthropics Claude bringt ein Verzeichnis mit 75+ offiziellen MCP-Connectoren mit. Am 9. Dezember 2025 spendete Anthropic MCP an die neu gegründete Agentic AI Foundation (AAIF) unter der Linux Foundation, mit Block und OpenAI als Mitgründern und Platin-Support von AWS, Bloomberg, Cloudflare, Google und Microsoft. MCP ist damit kein Anbieter-Standard mehr, sondern Industrie-Konsens. OpenAPI ist ebenfalls ein etablierter, breit getragener Standard, aber er beschreibt HTTP-APIs allgemein, nicht das agentenspezifische Tool-Use-Protokoll.

4. Aufwand

Function-Calling über OpenAPI hat den geringeren Initialaufwand: kein Server, keine Transport-Schicht, kein Auth-Layer für MCP. MCP verlangt, dass du einen Server baust oder betreibst, zahlt sich aber aus, sobald mehr als ein Client dasselbe Tool nutzt. Im DACH-Mittelstand gilt 2026 die Faustregel: Standard-MCP-Server der Hersteller nutzen, plus ein kleines Set eigener MCP-Server für proprietäre interne APIs.

5. Tool-Use vs. Agent-to-Agent

Wichtig für die Abgrenzung: MCP ist der Standard für Agent-zu-Tool. Für die echte Zusammenarbeit zwischen Agenten gibt es A2A (Agent2Agent, Google 04/2025, Linux Foundation 06/2025). Die offizielle Linie von Google, Salesforce, Microsoft und IBM lautet: „MCP ist für Capabilities (Agent-to-Tool), A2A für Collaboration (Agent-to-Agent).“ Microsofts eigene Guidance ist explizit: „Use MCP for tool and data access. Use Linux Foundation A2A for cross-platform agent-to-agent messaging.“ Man kann zwar einen Agenten als MCP-„Server“ mit tool-förmigen Capabilities exponieren, das funktioniert, ist aber nicht das Design-Ziel von MCP.

Vergleichstabelle: MCP vs. OpenAPI/Function-Calling

Konkretes Beispiel: SEO-Audit-Agent

Angenommen, eine Agentur baut intern Tools rund um SEO: einen Crawler, eine Keyword-Datenbank, ein CMS und eine Reporting-Funktion.

Szenario A: ein einzelner Agent, OpenAPI reicht. Es gibt genau einen Audit-Agenten, der vier stabile REST-Endpunkte aufruft. Du generierst die vier Tool-Schemata aus den vorhandenen OpenAPI-Specs, bettest sie direkt ein, fertig. Kein Server-Betrieb, geringster Aufwand. Würdest du hier MCP einziehen, zahltest du Server-Infrastruktur ohne Gegenwert.

Szenario B: produktisierte Tools, MCP gewinnt. Die Agentur betreibt jetzt mehrere Agenten (Audit-Agent, OnPage-Agent, Newsletter-Pipeline) und Kunden sollen die Keyword-Recherche aus ihren eigenen Stacks (etwa Copilot Studio oder n8n) aufrufen. Statt das Keyword-Schema in jedem Client erneut zu pflegen, baust du einen MCP-Server „SEO-Keyword-Research“ und eine geteilte MCP-Server-Bibliothek über alle Produkte. Pseudocode:

keyword_server = MCPServer("seo-keyword-research")

keyword_server.tool("get_keyword_volume", schema=...)

keyword_server.tool("get_serp_overview", schema=...)

Jeder Client (Claude, n8n, LangGraph) verbindet sich mit diesem Server und entdeckt beide Tools per dynamischer Discovery zur Laufzeit.

Ein neues Tool auf dem Server steht allen Clients sofort zur Verfügung, ohne Code-Änderung in den Agenten. Genau dieser Wiederverwendungs-Hebel ist 2026 das stärkste MCP-Argument. In einem realistischen Mittelstand-Projekt liegt der Budgetrahmen für das erste Jahr eines Multi-Agent-Programms je nach Zahl eigener MCP-Server bei rund 150k–500k Euro, wobei das obere Ende vor allem durch Custom-MCP-Server über mehrere interne Systeme getrieben wird (Stand 2026).

Entscheidungshilfe in drei Fragen

1. Wie viele Clients nutzen das Tool? Einer → OpenAPI/Function-Calling. Mehrere → MCP.
2. Wie stabil ist das Tool-Set? Stabil und klein → OpenAPI. Wachsend oder wechselnd → MCP (dynamische Discovery).
3. Geht es um Tools oder um Agenten-Kooperation? Tools/Daten → MCP. Echte Agent-zu-Agent-Zusammenarbeit über Plattformgrenzen → A2A (nicht MCP zweckentfremden).

Ein wichtiger Realismus-Hinweis aus der Praxis: Für DACH-Mittelstand-Projekte gilt, dass du MCP-Server „schreiben oder konsumieren wirst, ob du es geplant hast oder nicht“. SAP Joule Studio 2.0, Microsoft 365 Copilot, Copilot Studio, Salesforce Agentforce, n8n und LangGraph sprechen alle MCP. Die Entscheidung ist also oft weniger „ob MCP“ als „wo MCP zuerst“.

Sicherheit nicht unterschätzen

MCPs Offenheit hat eine Kehrseite. 2025 wurden mehrere Angriffsklassen dokumentiert: indirekte Prompt-Injection über MCP-Server-Beschreibungen, Tool-Poisoning (Invariant Labs, April 2025, samt WhatsApp-PoC), Look-alike-Server-Squatting und CyberArks Full-Schema-Poisoning (jeder Teil eines Tool-Schemas ist ein Injection-Vektor, nicht nur die Beschreibung). Ursache ist MCPs „optimistisches Trust-Modell“. Die Absicherung liegt beim Betreiber: Sandboxing, scope-begrenzte Tokens, OAuth-2.1-Scopes, Least-Privilege und keine autonome Installation von MCP-Servern aus nicht vertrauenswürdigen Registries. Klassische OpenAPI-Integrationen haben hier den Vorteil bewährter, gut verstandener REST-Sicherheitsmodelle.

Für Agenturen und B2B-Entscheider

Wenn du ein abgegrenztes Pilot-Projekt mit einem Agenten und wenigen, stabilen APIs startest, beginne schlank mit OpenAPI/Function-Calling, das senkt die Time-to-Value. Sobald du mehrere Agenten produktisieren oder Tools über Kundensysteme hinweg wiederverwenden willst, ist MCP die strategisch richtige Investition: ein Server, viele Clients. Für Agenturen ist das ein konkreter Produkt-Hebel: Eigene Vertical-MCP-Server (SEO, CMS, Newsletter) plus A2A-AgentCards machen deine Leistungen aus den Salesforce-, Joule- oder Copilot-Studio-Umgebungen deiner Kunden direkt aufrufbar. Blck Alpaca begleitet DACH-Unternehmen bei genau dieser Architekturentscheidung, von der Tool-Anbindung über MCP bis zur sicheren, governance-konformen Multi-Agent-Orchestrierung.