Was das Model Context Protocol ist und warum es 2026 zum Standard wurde
Das Model Context Protocol, kurz MCP, ist ein offener Standard, über den KI-Modelle auf Werkzeuge und Datenquellen zugreifen: ein ERP, ein CRM, eine Wissensdatenbank oder eine interne API. Statt jede Anbindung einzeln zu programmieren, spricht das Modell über einen MCP-Server mit dem Zielsystem. Ein Server, viele Modelle, ein Protokoll. Damit wird die Verbindung zwischen KI und Ihren Systemen zu einer wiederverwendbaren Komponente statt zu Wegwerf-Code pro Projekt.
Aus einem Anthropic-Experiment ist innerhalb eines Jahres ein herstellerunabhängiger Standard geworden. Am 9. Dezember 2025 hat Anthropic MCP an die neu gegründete Agentic AI Foundation unter der Linux Foundation übergeben, mitgetragen von Block und OpenAI und unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. Seitdem unterstützen alle großen Anbieter das Protokoll. Für Unternehmen ist das der entscheidende Punkt: Sie binden sich an einen Standard, nicht an einen einzelnen Hersteller.
Die Verbreitung ist real, nicht nur angekündigt. Anthropic nennt über 10.000 aktive öffentliche MCP-Server und mehr als 97 Millionen monatliche SDK-Downloads. Laut dem Stacklok-Report 2026 betreiben 41 Prozent der befragten Software-Organisationen MCP-Server bereits in Produktion. Das macht MCP 2026 zu einer Architektur-Entscheidung, die Sie aktiv treffen sollten, statt sie weiter zu vertagen.
- MCP ist ein offener Standard für die Verbindung von KI-Modellen mit Werkzeugen und Datenquellen
- Ein MCP-Server bindet ein System einmal an und stellt es jedem Modell zur Verfügung
- Seit der Übergabe an die Agentic AI Foundation (Linux Foundation, 9.12.2025) herstellerneutral
- Über 10.000 öffentliche Server, 41 Prozent der befragten Teams schon in Produktion
Voraussetzungen: Wann sich MCP für Ihre Architektur lohnt und wann nicht
MCP lohnt sich, sobald mehr als ein Modell oder mehr als ein Anwendungsfall auf dieselben Systeme zugreifen soll. Bei einer einzigen, fest verdrahteten Anbindung ist eine direkte Programmierung oft schneller. Sobald aber ein zweiter Use Case, ein anderes Modell oder ein Wechsel des Anbieters dazukommt, zahlt sich der Standard aus: Die Anbindung bleibt, das Modell darüber ist austauschbar.
Die ehrliche Voraussetzung ist nicht Technik, sondern Klarheit über Rechte. Ein MCP-Server kann lesend und schreibend auf ein System wirken. Bevor er das tut, muss feststehen, welche Daten ein Agent sehen darf, was er auslösen darf und wer das verantwortet. Diese Frage gehört vor die erste Zeile Code, nicht in ein späteres Audit. Wie Sie ein Vorhaben selbst gegen die wichtigsten Punkte prüfen, zeigt die kostenlose DSGVO-Checkliste für KI-Projekte.
Build or buy ist die zweite Vorab-Entscheidung. Für gängige Systeme gibt es fertige MCP-Server, für gewachsene Eigenentwicklungen lohnt der eigene. Die laufende Anbindung an Bestandssysteme begleite ich als Leistung KI-Integration.
- Sinnvoll ab dem zweiten Use Case, einem Modellwechsel oder mehreren Systemen hinter einer Anbindung
- Bei genau einer festen Verbindung ist direkte Programmierung oft der schnellere Weg
- Vor dem Bau klären: Welche Daten darf der Agent lesen, was schreiben, wer verantwortet es
- Build or buy: fertige Server für Standardsysteme, eigener Server für Legacy-Eigenentwicklung
Architektur in der Praxis: MCP-Server, Gateway und Registry
Eine belastbare MCP-Architektur besteht aus drei Bausteinen. Der MCP-Server kapselt ein Zielsystem und stellt klar umrissene Funktionen bereit. Ein MCP-Gateway sitzt davor und bündelt, was sonst pro Server geregelt werden müsste: Authentifizierung, Protokollierung, Rechtevergabe und Ratenbegrenzung an einer Stelle. Eine private Registry hält fest, welche Server im Unternehmen überhaupt zugelassen sind, statt dass jedes Team beliebige Server einbindet.
Für den Unternehmensbetrieb ist die Authentifizierung der heikelste Teil. Die Richtung des Standards geht klar zu etablierten Verfahren: OAuth 2.1 mit PKCE, dazu Anbindung an die vorhandene Identitätsverwaltung über OIDC oder SAML, etwa Microsoft Entra ID oder Keycloak. Ein MCP-Server gehört nicht offen ins Netz, sondern hinter dieselbe Anmeldung und dieselben Rollen, die für Ihre übrigen Systeme gelten.
Diese Trennung in Server, Gateway und Registry ist zugleich der Hebel für Sicherheit und Datenschutz. Wer Zugriff, Protokollierung und Freigabe zentral führt, kann beides nachweisen, statt es nur zu versprechen.
- MCP-Server kapselt ein Zielsystem mit klar umrissenen Funktionen
- MCP-Gateway zentralisiert Auth, Logging, Rechte und Ratenbegrenzung vor den Servern
- Private Registry lässt nur geprüfte Server zu statt wildwüchsiger Einbindung
- Enterprise-Auth: OAuth 2.1 mit PKCE plus OIDC/SAML, angebunden an Entra ID oder Keycloak
Use Cases im Mittelstand: Agenten an ERP, CRM und Wissensbasis
Der Nutzen von MCP zeigt sich dort, wo ein Agent nicht nur antworten, sondern in echten Systemen nachsehen und handeln soll. Ein Assistent, der einen Auftragsstatus im ERP liest, einen Gesprächsverlauf ins CRM schreibt oder eine Anfrage anhand interner Richtlinien beantwortet, braucht genau diese kontrollierte Verbindung zum Bestandssystem.
Besonders wirksam ist die Kombination aus MCP und einer Wissensbasis. Der Agent beantwortet Fragen quellengestützt aus Ihren eigenen Unterlagen statt aus Allgemeinwissen und greift über weitere Server auf strukturierte Daten zu. Die Grundlage dafür ist ein sauber aufgebautes RAG-Wissenssystem; wie ein solches Chat-Widget produktiv aussieht, zeigt das RAG Starter Kit.
Entscheidend ist die Rechtevergabe je Use Case. Ein Agent für den Vertrieb braucht andere Sichten als einer im Support. MCP erlaubt, den Zugriff pro Server und pro Rolle eng zu fassen, statt einem Agenten pauschal alles zu öffnen. MCP ist dabei der Tool-Layer unter der KI-Agenten-Architektur, nicht ihr Ersatz.
- Agenten lesen und schreiben kontrolliert in ERP, CRM, Ticketsystem und Fachanwendungen
- MCP plus RAG: quellengestützte Antworten aus eigenen Unterlagen statt aus Allgemeinwissen
- Zugriff eng je Rolle und Use Case fassen statt pauschalem Vollzugriff
- MCP als Tool-Layer unter der bestehenden KI-Agenten-Architektur
Sicherheit und Compliance: Tool-Poisoning, Prompt-Injection und der DSGVO-Gateway
Die schnelle Verbreitung hat das Sicherheitsmodell von MCP überholt. Im Juni 2026 hat die NSA ein eigenes Sicherheitspapier zu MCP veröffentlicht und genau darauf hingewiesen: Das Protokoll kehrt das gewohnte Muster um, weil Server für Modelle handeln, und schafft so neue, schwer nachvollziehbare Angriffswege. Die wichtigsten sind Prompt-Injection über manipulierte Inhalte, Tool-Poisoning durch bösartige Server-Beschreibungen und die Ausweitung von Rechten über mehrere Systeme hinweg.
Die Gegenmittel sind bekannt und gehören von Tag 1 in die Architektur: minimale Rechte je Server, gekapselte Ausführung, lückenlose Protokollierung und nur geprüfte Server aus einer eigenen Registry. Ein Gateway ist hier kein Luxus, sondern der Ort, an dem diese Regeln durchgesetzt werden.
Für den DACH-Raum kommt der Datenschutz dazu. Bindet ein MCP-Server einen externen Dienst an, ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO nötig; sensible Daten bleiben am sichersten in einem Server, der in einem EU-Rechenzentrum oder selbst gehostet läuft. So wird der Gateway zur kontrollierten Schleuse statt zum offenen Tor. Den regulatorischen Rahmen mitsamt der ab 2. August 2026 greifenden Pflichten ordnet der Leitfaden zum EU AI Act ein; die Self-Hosting-Variante ohne Cloud-Abfluss behandelt Private AI.
- NSA-Sicherheitspapier (Juni 2026): MCPs Verbreitung hat das Sicherheitsmodell überholt
- Hauptrisiken: Prompt-Injection, Tool-Poisoning, systemübergreifende Rechteausweitung
- Schutz ab Tag 1: minimale Rechte, Sandboxing, Logging, nur geprüfte Server aus eigener Registry
- DSGVO: AVV nach Art. 28 bei externen Servern, EU-Rechenzentrum oder Self-Hosting für sensible Daten
Kosten, Einstieg und Migrationspfad
Ein seriöser Aufwand lässt sich erst nach dem Blick auf Systeme und Rechte nennen. Die Treiber sind aber benennbar: ob fertige Server genügen oder ein eigener nötig ist, die Tiefe der Authentifizierung, die geforderte Prüf- und Protokolltiefe und der spätere Betrieb von Gateway und Registry.
Der bewährte Einstieg ist klein: ein Use Case, ein Server, eine saubere Anbindung an die vorhandene Anmeldung, in einem festen Rahmen von wenigen Wochen. Daraus entsteht eine belastbare Aussage über Nutzen und Kosten, bevor breiter ausgerollt wird. Self-Hosting in einer EU-Azure-Umgebung hält dabei Daten und Kontrolle im Haus.
Ein Wort zur Aktualität: Die Spezifikation entwickelt sich schnell. Ein Release Candidate vom 28. Juli 2026 führt einen zustandslosen Kern ein, der auf gewöhnlicher HTTP-Infrastruktur skaliert. Für die Architektur heißt das, Server und Gateway so zu bauen, dass sie der finalen Fassung folgen können. Wenn Sie einen konkreten Use Case im Kopf haben, besprechen wir den sinnvollsten ersten Schritt.
- Kostentreiber: fertige oder eigene Server, Auth-Tiefe, Prüf- und Logging-Anforderungen, Betrieb
- Einstieg mit einem Use Case, einem Server und fester Laufzeit statt Big-Bang-Rollout
- Self-Hosting in EU-Azure hält Daten und Kontrolle im Unternehmen
- Spezifikation entwickelt sich schnell (zustandsloser Kern, RC 28.7.2026): aktualisierbar bauen