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 Sie der einzige Konsument sind.
• 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. Sie beschreiben Ihre Funktionen als Tool-Schema (Name, Parameter, Typen, Beschreibung) und übergeben 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; Ihr 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 zu verbinden – Dateisystemen, Datenbanken, Business-Systemen, Dev-Tools. 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 April 2025 Streamable HTTP. Dieselbe Revision ergänzte OAuth-2.1-Support, JSON-RPC-Batching und Tool-Annotations. Die Spec vom November 2025 brachte asynchrone Operationen, Statelessness und Server-Identität (alle Angaben Stand 2026). 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 Sie ihm beim Aufruf mitgeben. Kommt ein Tool hinzu, ändern Sie 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), unterstützen seit der November-2025-Spec aber explizit auch stateless Betrieb – wichtig für 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 Sie einen Server bauen oder betreiben – 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. Sie generieren die vier Tool-Schemata aus den vorhandenen OpenAPI-Specs, betten sie direkt ein – fertig. Kein Server-Betrieb, geringster Aufwand. Würden Sie hier MCP einziehen, zahlten Sie 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, bauen Sie 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 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 Sie MCP-Server „schreiben oder konsumieren werden, ob Sie es geplant haben 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 WhatsApp-PoC, März 2025), 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 Sie ein abgegrenztes Pilot-Projekt mit einem Agenten und wenigen, stabilen APIs starten, beginnen Sie schlank mit OpenAPI/Function-Calling – das senkt die Time-to-Value. Sobald Sie mehrere Agenten produktisieren oder Tools über Kundensysteme hinweg wiederverwenden wollen, 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 Ihre Leistungen aus Salesforce-, Joule- oder Copilot-Studio-Estates Ihrer 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.