Anthropics Model Context Protocol hat sich durchgesetzt: Wie MCP zum universellen Standard für AI-Tool-Integration wurde

Im November 2024 veröffentlichte Anthropic eine Spezifikation namens Model Context Protocol – ein offener Standard, um KI-Modelle mit externen Tools, Datenquellen und Diensten zu verbinden. Damals sah es aus wie ein weiteres herstellerspezifisches Integrationsformat. Mitte 2026 hatten alle großen KI-Plattformen es übernommen. MCP löste das Fragmentierungsproblem, das KI-Agenten bis dahin leise ausgebremst hatte: die Unfähigkeit, Tool-Integrationen über Modelle und Laufzeitumgebungen hinweg gemeinsam zu nutzen.

Was MCP eigentlich ist

MCP ist ein Client/Server-Protokoll, das auf JSON-RPC 2.0 basiert. Ein MCP-Server stellt Fähigkeiten bereit – Tools, Ressourcen und Prompts – über eine Transportschicht (stdio für lokale Prozesse, HTTP/SSE für vernetzte Dienste). Ein MCP-Client, eingebettet in einen KI-Host wie Claude, Copilot oder Cursor, entdeckt und ruft diese Fähigkeiten zur Laufzeit auf.

Das Protokoll definiert drei primitive Typen:

• Tools – aufrufbare Funktionen, die das Modell ausführen kann, mit typisierten JSON-Schema-Eingabe-/Ausgabedefinitionen. Denkbar: github.create_pull_request, postgres.run_query, slack.send_message.
• Ressourcen – strukturierte Daten, die das Modell lesen kann, identifiziert durch URIs. Eine Datei, eine Datenbankzeile, ein Kalendereintrag.
• Prompts – wiederverwendbare, parametrisierte Prompt-Vorlagen, die der Server für häufige Aufgaben bereitstellt.

Das transportunabhängige Design ist beabsichtigt. Ein lokal laufender MCP-Server kommuniziert über stdin/stdout. Derselbe Server, als Mikroservice bereitgestellt, wechselt zu HTTP mit Server-Sent Events für Streaming. Dem Client ist es egal, welcher Transport verwendet wird.

Der Adoptionszeitplan, der alles veränderte

Anthropic hat MCP als Open Source veröffentlicht und zusammen mit der Spezifikation SDKs für Python und TypeScript bereitgestellt. Frühe Adoption kam von Entwicklerwerkzeugen: Cursor, Zed und Continue integrierten MCP innerhalb von Wochen und gaben ihren Nutzern Zugriff auf einen wachsenden Katalog von Servern für GitHub, Dateisysteme, Datenbanken und Websuche.

Der Wendepunkt kam Anfang 2025, als OpenAI native MCP-Unterstützung in der Responses API und seinem Agenten-Framework ankündigte. Diese Entscheidung signalisierte, dass MCP kein Claude-spezifisches Feature war – es war Infrastruktur. Google zog mit Geminis MCP-Integration in Google AI Studio und Vertex AI nach, sodass Gemini-Agenten denselben Serverkatalog nutzen konnten, den Claude-Nutzer aufgebaut hatten. Microsoft Copilot Studio fügte MCP-Connector-Support hinzu, sodass Unternehmensteams interne APIs als MCP-Server bereitstellen konnten, ohne benutzerdefinierten Plugin-Code schreiben zu müssen.

Mitte 2026 war das MCP-Server-Register auf über 2.000 von der Community und Anbietern gewartete Server angewachsen. AWS, Azure und GCP veröffentlichten jeweils eigene MCP-Server für ihre Kerndienste. Stripe, Linear, Notion und Atlassian brachten offizielle Integrationen heraus. Das Ökosystem, das Jahre gebraucht hatte, um sich um REST-APIs herum aufzubauen, baute sich in Monaten um MCP herum neu auf.

Warum MCP sich gegen Alternativen durchsetzte

Vor MCP hatte jede KI-Plattform ihr eigenes Tool-Calling-Format. OpenAI hatte Function Calling mit einem eigenen JSON-Schema-Dialekt. LangChain hatte Tools mit Python-Klassendefinitionen. Semantic Kernel hatte Plugins mit OpenAPI-Beschreibungen. Jedes Ökosystem erforderte, Integrationen von Grund auf neu zu schreiben, wenn man Modelle oder Laufzeiten wechselte.

MCP gewann aus drei Gründen:

• Es ist wirklich offen. Die Spezifikation ist MIT-lizenziert und wird unabhängig verwaltet. Kein Anbieter kontrolliert den Fahrplan unilateral. Das machte die Adoption politisch unbedenklich für OpenAI und Google, die kein Protokoll ausgeliefert hätten, das Nutzer in Anthropics Ökosystem einsperrt.
• Es ist einfacher als die Alternativen. Ein MCP-Server ist ein Prozess, der JSON-RPC spricht. Man braucht kein Framework, kein Plugin-Manifest oder eine OpenAPI-Spezifikation. Ein funktionierender Server in Python besteht mit dem offiziellen SDK aus etwa 30 Zeilen Code.
• Transportunabhängigkeit beseitigt Implementierungshürden. Dasselbe Server-Binary funktioniert in einer lokalen Entwicklungsumgebung und in einem Kubernetes-Cluster. Diese Vorhersagbarkeit ist wichtig für Unternehmensteams mit strengen Netzwerk- und Sicherheitsanforderungen.

Wie es in der Praxis aussieht

Ein Entwickler, der heute einen Kundenservice-Agenten baut, schreibt keinen benutzerdefinierten Tool-Calling-Glue-Code für jedes Modell, das unterstützt werden soll. Stattdessen betreibt er einen MCP-Server, der sein CRM, sein Ticketing-System und seine Wissensdatenbank als Tools und Ressourcen bereitstellt. Jeder MCP-kompatible KI-Host – Claude, GPT-4o, Gemini – kann diese Tools dann ohne Änderungen nutzen.

Betrachten wir einen konkreten Stack. Ein Team setzt ein:

• Einen MCP-Server, der ihre PostgreSQL-Datenbank kapselt und run_query sowie list_tables als Tools bereitstellt
• Einen MCP-Server für ihr GitHub-Repository, der Issue-Management und PR-Erstellung bereitstellt
• Einen MCP-Server für Slack, der Kanalnachrichten und Thread-Lesen ermöglicht

Ihr KI-Agent – der auf dem Modell läuft, das für ihre Arbeitslast am besten geeignet ist – entdeckt alle drei Server beim Start über eine Konfigurationsdatei und kann während einer Reasoning-Sitzung jedes Tool in jedem Server aufrufen. Der Wechsel von Claude zu Gemini zerbricht keine einzige Integration. Das ist der praktische Wert, den MCP liefert.

Der Wandel der Entwicklererfahrung

Das mentale Modell hat sich für Entwickler geändert, die KI-gestützte Produkte bauen. Früher waren Integrationen modellspezifisch: man baute für OpenAIs Function Calling oder für Claudes Tool Use, und die Portierung zwischen ihnen bedeutete, Schemata und Glue-Code neu zu schreiben. Jetzt sind Integrationen fähigkeitsspezifisch: man baut einmal einen MCP-Server, und jede kompatible KI-Laufzeit kann ihn nutzen.

Dieser Wandel hat praktische Konsequenzen dafür, wie Teams ihre KI-Infrastruktur strukturieren. MCP-Server sind jetzt eine eigene Schicht im Stack – getrennt von der Anwendung, getrennt bereitgestellt, getrennt versioniert. Teams bauen interne MCP-Serverkataloge auf, so wie sie früher interne API-Kataloge aufgebaut haben. Die Disziplin des API-Designs – klare Verträge, Versionierung, Dokumentation – wird zum ersten Mal auf KI-Tool-Integrationen angewandt.

Sicherheit und Autorisierung

MCP 1.1, veröffentlicht im ersten Quartal 2026, fügte eine OAuth-2.1-Autorisierungsschicht für HTTP-basierte Server hinzu. Ein MCP-Client kann jetzt bereichsbezogene Zugriffstoken aushandeln, bevor er Tools auf einem entfernten Server aufruft. Das beantwortete den Haupteinwand von Unternehmen gegen frühe MCP-Bereitstellungen: dass jedes verbundene Modell jedes Tool ohne granulare Zugriffskontrolle aufrufen könnte. Mit den in der Spezifikation standardisierten OAuth-2.1-Abläufen sind Unternehmens-MCP-Bereitstellungen jetzt ohne benutzerdefinierte Sicherheits-Middleware realisierbar.

Handlungsempfehlungen

Wenn Sie 2026 KI-gestützte Produkte bauen, ist MCP keine optionale Infrastruktur mehr, die es zu evaluieren gilt – es ist die Standard-Integrationsschicht. Hier ist, was zu tun ist:

• Überprüfen Sie Ihre bestehenden Tool-Integrationen. Jedes benutzerdefinierte Function-Calling-Schema, das Sie für ein bestimmtes Modell pflegen, ist jetzt technische Schuld. Die Migration zu einem MCP-Server verschafft Ihnen Portabilität über alle kompatiblen Modelle hinweg.
• Prüfen Sie das Register, bevor Sie selbst bauen. Der MCP-Serverkatalog unter modelcontextprotocol.io enthält höchstwahrscheinlich einen gewarteten Server für die benötigte API. Stripe, GitHub, Postgres, Slack und Google Drive haben alle First-Party-Server.
• Bauen Sie MCP-Server als interne Produkte. Behandeln Sie Ihren MCP-Server genauso wie eine interne API: versionieren Sie ihn, dokumentieren Sie ihn und geben Sie ihm ein klares Ownership-Modell. Teams, die in einen gut designten internen MCP-Katalog investieren, werden diese Investition bei jedem KI-Feature, das sie ausliefern, vervielfachen.
• Nutzen Sie den OAuth-2.1-Ablauf für alles, was produktiv eingesetzt wird. Lokale stdio-Server sind für die Entwicklung in Ordnung. Jeder MCP-Server, der einem produktiven KI-Agenten ausgesetzt wird, sollte authentifizierten, bereichsbezogenen Zugriff erfordern.

MCP hat sich nicht durchgesetzt, weil Anthropic es gut vermarktet hat. Es siegte, weil das Problem, das es löst – die Zersplitterung von KI-Tools – real und teuer war, und die Lösung einfach genug, dass Wettbewerber keinen Anreiz hatten, etwas anderes zu bauen. Diese Kombination versagt selten.