Model Context Protocol (MCP)

Wenn du verstehen willst, warum plötzlich jede Software von der IDE bis zum Shopsystem „MCP-Unterstützung" ankündigt, lohnt sich ein genauer Blick auf das, was dieses Protokoll tatsächlich regelt.

Die Grundidee lässt sich in einem Vergleich fassen, der sich in der Branche durchgesetzt hat: MCP ist der USB-C-Anschluss für KI-Anwendungen. Vor MCP musste jeder Anbieter eines KI-Assistenten für jedes externe System eine eigene Integration bauen, und jeder Systemanbieter für jeden KI-Assistenten eine eigene Schnittstelle pflegen. Bei M Modellen und N Systemen ergibt das M mal N Integrationen, von denen jede einzelne brechen kann. MCP ersetzt dieses Geflecht durch eine einzige, standardisierte Schnittstelle: Ein System stellt einmal einen MCP-Server bereit, und jedes MCP-fähige KI-Tool kann ihn nutzen, egal ob es Claude heißt, ChatGPT, Gemini oder Microsoft Copilot.

Wie MCP funktioniert: Architektur und Bausteine

MCP basiert auf JSON-RPC 2.0, einem etablierten, leichtgewichtigen Nachrichtenformat, und definiert drei Rollen. Der Host ist die KI-Anwendung, mit der du arbeitest, etwa ein Chat-Interface oder eine Entwicklungsumgebung. Der Host bettet einen oder mehrere Clients ein, die jeweils die Verbindung zu genau einem Server halten. Der Server ist das Stück Software, das ein externes System anbindet: eine Datenbank, ein CRM, ein Dateisystem, ein Shopsystem. Wie beide Seiten ihre Fähigkeiten abgleichen, hat die Spezifikation 2026 umgebaut: Bis zur Revision 2025-11-25 eröffnete ein initialize-Handshake eine Sitzung, in der die Capabilities einmal ausgehandelt wurden. Seit der Fassung vom 28. Juli 2026 ist das Protokoll zustandslos – jede Anfrage trägt Protokollversion und Capabilities selbst mit sich, und wer sie vorab kennen will, ruft die Methode server/discover auf. Für den Betrieb heißt das: MCP-Server lassen sich hinter einen gewöhnlichen Load Balancer stellen, ohne Sitzungszustand zwischen den Instanzen zu teilen.

Die Architektur orientiert sich erklärtermaßen am Language Server Protocol (LSP), mit dem Microsoft einst standardisiert hat, wie Code-Editoren Programmiersprachen unterstützen. Was LSP für Entwicklungswerkzeuge geleistet hat, soll MCP für KI-Anwendungen leisten: Ein Ökosystem, in dem Anbieter von Werkzeugen und Anbieter von Anwendungen unabhängig voneinander entwickeln können, weil die Schnittstelle dazwischen stabil ist.

Die drei Server-Primitiven

Ein MCP-Server kann seinen Clients drei Arten von Fähigkeiten anbieten:

• Tools sind Funktionen, die das KI-Modell ausführen kann, vom Lesen eines Datensatzes bis zum Anlegen einer Bestellung. Tools sind das Herzstück des Protokolls, denn sie machen aus einem Modell, das nur Text generiert, ein System, das handelt.
• Resources sind Kontext und Daten, die der Server bereitstellt, etwa Dokumente, Datenbankinhalte oder Konfigurationen, die das Modell oder der Nutzer einsehen kann.
• Prompts sind vordefinierte Vorlagen und Workflows, die der Server anbietet, damit wiederkehrende Aufgaben konsistent ablaufen.

Umgekehrt kann auch der Server etwas vom Client brauchen: eine Rückfrage an den Nutzer (Elicitation) oder eine eigene Anfrage an das Sprachmodell (Sampling). Diese Rückrichtung wird oft übersehen, ist aber entscheidend für agentische Szenarien, in denen Server nicht nur passiv Daten liefern, sondern aktiv am Workflow teilnehmen. Mit der Revision 2026-07-28 hat sich ihr Mechanismus geändert: Server stellen keine eigenen Anfragen mehr an den Client. Stattdessen läuft eine Rückfrage über Multi Round-Trip Requests: Der Server beendet den Tool-Aufruf mit dem Hinweis, dass er eine Eingabe braucht, der Client holt sie ein und wiederholt den Aufruf samt Antwort. Roots, Sampling und das Logging-Feature stehen in derselben Revision auf der Abkündigungsliste – frühestens mit der ersten Revision ab dem 28. Juli 2027 dürfen sie entfallen. Als Migrationsweg nennt die Spezifikation: Verzeichnisse und Dateien über Tool-Parameter oder Resource-URIs übergeben statt über Roots, das Sprachmodell direkt über die API des Anbieters ansprechen statt über Sampling, und für Logs stderr (bei stdio-Transporten) beziehungsweise OpenTelemetry nutzen.

Für den Transport definiert die Spezifikation weiterhin zwei Wege: stdio für lokale Server, die als Unterprozess laufen, und Streamable HTTP für entfernte Server. Der ältere HTTP-plus-SSE-Transport gilt bereits seit der Revision 2025-03-26 als abgekündigt; das Register der veralteten Funktionen führt ihn mit Streamable HTTP als Migrationspfad. Über den Kern hinaus kennt die Spezifikation seit der Fassung 2026-07-28 ein formales Erweiterungssystem: Optionale Extensions wie Tasks (lang laufende Aufgaben mit Polling statt offener Verbindung), MCP Apps (interaktive Oberflächen direkt in der Konversation) oder Enterprise Managed Authorization sind opt-in – der Client meldet die von ihm unterstützten Extensions in den Capabilities jeder Anfrage, der Server in seiner Antwort auf server/discover. Die aktuelle Fassung der Spezifikation trägt das Datum 2026-07-28 und ist öffentlich einsehbar unter modelcontextprotocol.io.

Vom Anthropic-Projekt zum Industriestandard

Die Geschwindigkeit, mit der MCP zum De-facto-Standard wurde, ist selbst für KI-Verhältnisse bemerkenswert. Anthropic stellte das Protokoll am 25. November 2024 vor. Im Frühjahr 2025 kündigten OpenAI, Google DeepMind und Microsoft Unterstützung an, also ausgerechnet die direkten Wettbewerber des Initiators. Ende 2025 meldete das Projekt über 97 Millionen monatliche SDK-Downloads und mehr als 10.000 aktive MCP-Server, mit Client-Unterstützung in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot und Visual Studio Code.

Der Governance-Schritt folgte am 9. Dezember 2025: Anthropic übergab MCP an die neu gegründete Agentic AI Foundation (AAIF), einen Fonds unter dem Dach der Linux Foundation, mitgegründet von Anthropic, Block und OpenAI und unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. Für dich als Entscheider ist das mehr als eine Fußnote: Ein Protokoll, das einem einzelnen Hersteller gehört, ist ein Risiko, ein Protokoll unter neutraler Foundation-Governance ist eine Investitionsgrundlage. Genau diese Übergabe hat MCP von einer cleveren Anthropic-Idee in Infrastruktur verwandelt, auf die man Architekturentscheidungen bauen kann.

MCP im E-Commerce: das Shopware-Beispiel

Wie konkret MCP im Handel ankommt, zeigt Shopware. Auf dem Shopware Community Day 2026 in Köln verkündete das Unternehmen eine hundertprozentige MCP-Abdeckung des Commerce-Cores: Jede Aktion in der Plattform, vom Produktanlegen über Preisregeln bis zur Bestandspflege, ist über das Protokoll für KI-Tools und Agents zugänglich. Das ist ein anderes Kaliber als ein eingebauter Textgenerator. Es bedeutet, dass ein beliebiges MCP-fähiges KI-Werkzeug deinen Shop bedienen kann, ohne dass dafür eine proprietäre Schnittstelle gebaut werden muss.

Praktisch heißt das: Ein Agent kann Produktdaten anreichern, Preisregeln entwerfen oder Auswertungen über Bestellungen fahren, und zwar mit denselben standardisierten Mechanismen, mit denen ein anderer Agent ein CRM oder ein Ticketsystem bedient. Der Wert entsteht dabei nicht im Protokoll selbst, sondern in dem, was es erreichbar macht. Ein MCP-Server vor einem gepflegten Produktdatenbestand ist ein Werkzeug, ein MCP-Server vor einem Datenchaos ist ein Verstärker für das Chaos. Wer über MCP-Anbindung nachdenkt, sollte deshalb zuerst über Datenqualität nachdenken.

Wie sich die Spezifikation entwickelt hat

Wer MCP produktiv einsetzt, sollte die Versionsstände kennen, denn das Protokoll hat sich seit dem Start spürbar bewegt. Die Erstausgabe vom 5. November 2024 legte das Fundament mit Tools, Resources und Prompts. Die Revision vom 26. März 2025 ersetzte den ursprünglichen HTTP-plus-SSE-Transport durch Streamable HTTP und brachte einen OAuth-basierten Autorisierungsrahmen. Die Fassung vom 18. Juni 2025 ergänzte unter anderem Elicitation und strukturierte Tool-Ausgaben, die Revision vom 25. November 2025 schärfte Autorisierung und Sicherheitsleitlinien nach. Den größten Schnitt brachte die aktuelle Fassung vom 28. Juli 2026: Sie ersetzt das sitzungsbasierte Modell durch zustandslose Einzelanfragen, streicht den initialize-Handshake und die Session-ID, verlagert Tasks aus dem Kern in eine eigene Extension und kündigt die Dynamic Client Registration zugunsten von Client ID Metadata Documents ab. Wer bisher mit Session-Kennungen gearbeitet hat, hat hier den größten Umstellungsaufwand. Jede Anfrage nennt seitdem ihre Protokollversion, und der Server akzeptiert oder lehnt sie einzeln ab; für ältere, handshake-basierte Gegenstellen beschreibt die Spezifikation einen Kompatibilitätspfad. Trotzdem gilt: Wer heute einen eigenen Server baut, sollte gegen die aktuelle Spezifikation entwickeln und die offiziellen SDKs nutzen – zum Release der neuen Fassung unterstützten die SDKs für TypeScript, Python, Go und C# sie bereits, das Rust-SDK als Beta.

Sicherheit: die offene Flanke

MCP gibt Modellen Zugriff auf reale Systeme, und genau darin liegt das Risiko. Die Spezifikation selbst benennt die Prinzipien: Nutzer müssen Datenzugriffen und Tool-Aufrufen explizit zustimmen, Hosts dürfen Daten nicht ohne Einwilligung weiterreichen, und Tool-Beschreibungen von fremden Servern gelten grundsätzlich als nicht vertrauenswürdig. Das letzte Prinzip zielt auf eine reale Angriffsklasse: Prompt Injection über manipulierte Tool-Beschreibungen, bei der ein bösartiger Server dem Modell Anweisungen unterschiebt.

Durchsetzen kann das Protokoll diese Prinzipien nicht, das ist Aufgabe der Implementierung. In der Praxis heißt das für den Einsatz im Unternehmen: Rechte pro Tool sauber beschränken, Server nur aus vertrauenswürdigen Quellen einbinden, schreibende Aktionen über Freigabeprozesse führen und protokollieren, was Agents tatsächlich tun. Wer einem Agent Schreibrechte auf Preisregeln gibt, ohne einen Prüfschritt davorzusetzen, hat kein MCP-Problem, sondern ein Governance-Problem.

Abgrenzung: MCP, Function Calling, UCP

Drei Begriffe werden in Diskussionen regelmäßig vermischt. Function Calling ist die proprietäre Fähigkeit eines einzelnen Modells, strukturierte Funktionsaufrufe zu erzeugen, jeder Anbieter implementiert sie anders. MCP setzt eine Ebene darüber an und standardisiert, wie solche Aufrufe systemübergreifend transportiert, entdeckt und autorisiert werden. Das Universal Commerce Protocol (UCP) wiederum regelt einen anderen Anwendungsfall: nicht wie ein KI-Tool ein System bedient, sondern wie ein KI-Agent bei einem Händler einkauft, inklusive Katalogzugriff, Warenkorb und Bezahlung. Die beiden Protokolle konkurrieren nicht, sie ergänzen sich. Vereinfacht gesagt macht MCP deinen Shop für KI-Werkzeuge bedienbar und UCP macht ihn für KI-Käufer kaufbar.

Ebenfalls verwandt, aber nicht identisch: Agent-zu-Agent-Protokolle wie Googles A2A, die die Kommunikation zwischen mehreren Agents regeln. MCP bleibt das Bindeglied zwischen einem Modell und den Systemen, mit denen es arbeitet.

Was MCP für dein Unternehmen bedeutet

Ob du einen Onlineshop betreibst, Individualsoftware einsetzt oder interne Prozesse automatisieren willst, die Frage ist nicht mehr, ob deine Systeme KI-zugänglich werden, sondern über welchen Weg. MCP ist hier zur sichersten Wette geworden, aus drei Gründen: Es ist offen lizenziert und herstellerneutral verwaltet, es wird von allen großen Modellanbietern gleichzeitig unterstützt, und es hat in Rekordzeit ein Ökosystem aus tausenden fertigen Servern aufgebaut.

Konkret ergeben sich drei Handlungsfelder. Erstens Bestandsaufnahme: Welche deiner Systeme bringen bereits MCP-Server mit, welche brauchen einen eigenen? Für verbreitete Software existieren oft fertige Server, für Eigenentwicklungen ist ein MCP-Server ein überschaubares Projekt, sofern die zugrunde liegende API sauber ist. Zweitens Priorisierung: Nicht jedes System muss agentenfähig werden, anfangen solltest du dort, wo wiederkehrende, regelbasierte Arbeit auf gute Datenlage trifft. Drittens Kontrolle: Definiere vor dem ersten produktiven Agent, welche Aktionen automatisch laufen dürfen und welche eine menschliche Freigabe brauchen.

Häufige Fragen zum Model Context Protocol

Ist MCP kostenlos nutzbar?

Ja. MCP ist ein offener Standard mit Open-Source-SDKs für unter anderem TypeScript, Python, Go, C# und Java. Kosten entstehen nicht durch das Protokoll, sondern durch die Nutzung der KI-Modelle und den Betrieb der Server.

Brauche ich MCP, wenn meine Systeme schon REST-APIs haben?

Eine REST-API beschreibt, wie Maschinen mit deinem System sprechen, aber ein KI-Modell weiß damit noch nicht, welche Aktionen es wann aufrufen soll. Ein MCP-Server übersetzt deine API in Tools mit Beschreibungen, die Modelle verstehen und selbstständig nutzen können. Häufig ist der MCP-Server eine dünne Schicht über der bestehenden API.

Wie sicher ist es, einem KI-Modell über MCP Systemzugriff zu geben?

So sicher, wie du es konfigurierst. Das Protokoll sieht Zustimmungspflichten und Capability-Grenzen vor, aber Rechtevergabe, Server-Auswahl und Freigabeprozesse liegen bei dir. Bewährt hat sich, lesende Zugriffe großzügig und schreibende Zugriffe nur mit Prüfschritt zu erlauben.

Wer kontrolliert die Weiterentwicklung von MCP?

Seit Dezember 2025 die Agentic AI Foundation unter der Linux Foundation, getragen von Anthropic, OpenAI, Block und weiteren Unternehmen wie Google, Microsoft und AWS. Kein einzelner Hersteller kann das Protokoll im Alleingang verändern.

Was hat MCP mit Agentic Commerce zu tun?

MCP ist eine der Grundlagen dafür. Damit KI-Agents im Handel wirklich arbeiten können, müssen sie Shopsysteme, Warenwirtschaft und Produktdaten bedienen können, und genau diese Bedienbarkeit standardisiert MCP. Für den eigentlichen Kaufvorgang durch fremde Agents kommen Commerce-Protokolle wie UCP hinzu.