TL;DR. MCP ist keine Wette mehr. Seit Dezember 2025 liegt das Model Context Protocol bei der Agentic AI Foundation unter dem Dach der Linux Foundation, mitgetragen von Anthropic, OpenAI, Block, Google, Microsoft, AWS, Cloudflare und Bloomberg. Am 28. Juli 2026 ist die neue Spezifikation erschienen: MCP ist jetzt zustandslos und lässt sich erstmals sauber hinter gewöhnlichen Load-Balancern betreiben. Sicherheit liefert das Protokoll aber nicht mit. Trend Micro zählte im April 1.467 offen erreichbare MCP-Server ohne Authentifizierung, fast dreimal so viele wie im ersten Scan. Wer anschließt, muss selbst absichern. Die Checkliste dafür steht unten.
Vom Experiment zur Stiftung: was im Dezember passiert ist
Als Anthropic das Model Context Protocol Ende 2024 veröffentlichte, war es ein Vorschlag: ein offener Standard, über den KI-Assistenten mit Werkzeugen und Datenquellen sprechen, statt für jede Kombination aus Modell und System eine eigene Anbindung zu bauen. Ob sich dieser Vorschlag durchsetzt, war lange die eigentliche Frage für jeden, der Budget investieren sollte.
Diese Frage ist beantwortet. Am 9. Dezember 2025 hat Anthropic das Protokoll an die Agentic AI Foundation übergeben, einen zweckgebundenen Fonds der Linux Foundation. Gegründet wurde sie mit drei Projekten: MCP von Anthropic, AGENTS.md von OpenAI und dem Agenten-Framework goose von Block. Als Platin-Mitglieder sind neben diesen drei auch AWS, Bloomberg, Cloudflare, Google und Microsoft dabei.
Für Entscheider ist das der relevante Punkt. Ein Standard, der einem einzelnen Hersteller gehört, ist ein Risiko. Ein Standard unter neutraler Stiftung mit formaler Regel für Abkündigungen ist Infrastruktur, auf der man planen kann. Zum Zeitpunkt der Übergabe gab es über 10.000 aktive öffentliche MCP-Server und mehr als 97 Millionen SDK-Downloads im Monat. MCP lief in ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor und VS Code. Im Juli 2026 meldete das Projekt für die wichtigsten SDKs bereits knapp eine halbe Milliarde Downloads im Monat.
Ein Server, alle Clients: warum sich das rechnet
Die betriebswirtschaftliche Logik von MCP ist unspektakulär und genau deshalb überzeugend. Vor MCP hieß „unsere Daten für KI nutzbar machen“: für jeden Assistenten eine eigene Anbindung, jede mit eigener Wartung, eigenem Anmeldekonzept und eigenem Risiko, bei Updates zu brechen. Mit MCP bauen Sie die Anbindung einmal, als MCP-Server vor Ihrem ERP, Ihrer Wissensdatenbank oder Ihrem Ticketsystem. Jeder MCP-fähige Client kann sie nutzen.
Dass dieses Muster trägt, sehen wir in unserer eigenen Arbeit. Wir bauen MCP-Server als Werkzeugschicht für Fachanwendungen, nach dem Prinzip „ein Backend, zwei Türen“: eine Oberfläche für Menschen, ein MCP-Zugang für Agenten. Dieselben Werkzeuge, dieselben Datenverträge, keine doppelte Pflege. Der Aufwand steckt einmal im sauberen Werkzeugdesign, nicht in der x-ten Anbindung an einen weiteren Client.
Auch die Großen bauen längst produktiv. Stripe, PayPal, Shopify, Figma, Notion, Linear, Atlassian, Zapier, MongoDB und Microsoft betreiben eigene MCP-Server. Mit MCP Apps gibt es inzwischen eine offizielle Erweiterung, über die Werkzeuge nicht nur Text zurückgeben, sondern kleine interaktive Oberflächen im Chat. Der MCP-Server wird damit vom Datenlieferanten zur eigenen Mini-Anwendung beim Kunden.
Die Spezifikation vom 28. Juli: zustandslos heißt betreibbar
Die nächste Fassung der Spezifikation ist am 28. Juli 2026 erschienen. Die wichtigste Änderung klingt technisch, ist aber ein Signal an jede IT-Abteilung: MCP ist jetzt zustandslos.
Bisher brauchte jede MCP-Verbindung einen Handschlag zum Start und eine Sitzungskennung. Der Server musste sich also merken, mit wem er spricht. Für ein Entwicklerwerkzeug auf dem Laptop ist das egal. Für den Betrieb hinter einem Load-Balancer war es ein Problem, denn Anfragen derselben Sitzung mussten immer beim selben Server landen. Die neue Spezifikation streicht den Handschlag und die Sitzungskennung. Jede Anfrage kann bei jeder Instanz landen. Das ist Skalierung wie bei jeder gewöhnlichen Web-Schnittstelle.
Weitere Neuerungen zeigen in dieselbe Richtung:
| Neuerung | Was sie bedeutet |
|---|---|
| Zustandsloser Betrieb | Gewöhnliche Load-Balancer statt fester Zuordnung von Sitzungen |
| Pflicht-Header Mcp-Method und Mcp-Name | Gateways, Rate-Limiter und Firewalls können routen und messen, ohne den Inhalt zu lesen |
| Rückfragen ohne offenen Kanal | Braucht der Server eine Eingabe, sagt er es in der Antwort, und der Client fragt erneut an |
| Härtere Anmeldung | Prüfung des Ausstellers nach RFC 9207, Zugangsdaten an den Aussteller gebunden |
| Rahmen für Erweiterungen | Tasks, MCP Apps und Anmeldung über das Unternehmen als saubere Erweiterungen |
| Regel für Abkündigungen | Mindestens zwölf Monate Vorlauf, etwa für den alten SSE-Transport |
Header für Rate-Limiter, strengere Anmeldung, Fristen für Abkündigungen: Das sind keine Funktionen für Bastler. Das ist die Ausstattung, die ein Protokoll braucht, um in Unternehmensnetzen zu leben.
Die Kehrseite: Das Ökosystem wächst schneller als seine Absicherung
Genau hier muss die Begeisterung eine Pause machen. Denn während Stiftung und Spezifikation gereift sind, gilt das für die Masse der real existierenden MCP-Server nicht.
Trend Micro hat im Juli 2025 erstmals das Internet nach offen erreichbaren MCP-Servern abgesucht und 492 ohne jede Authentifizierung gefunden. Im Update vom 28. April 2026 waren es 1.467, fast dreimal so viele. 1.227 davon nutzen noch den alten SSE-Transport, den die neue Spezifikation abkündigt. Das sind Werkzeugschichten mit Zugriff auf interne Systeme, die ungeschützt im Netz stehen.
Offen erreichbare MCP-Server ohne Authentifizierung
ohne Authentifizierungdavon 1.227 mit altem SSE-Transport
Für dasselbe Update hat Trend Micro über 19.000 Quelltexte von MCP-Servern ausgewertet. 48 % davon empfehlen, Geheimnisse wie API-Schlüssel ungeschützt in .env-Dateien oder als Klartext in JSON abzulegen. Dazu fanden die Forscher drei kritische Lücken mit CVSS 9,8 in inoffiziellen MCP-Servern für Azure und AWS.
19.000 Quelltexte von MCP-Servern
Auch die Client-Seite ist Angriffsfläche. Check Point meldete im Februar 2026 zwei inzwischen behobene Lücken in Claude Code (CVE-2025-59536 und CVE-2026-21852). Präparierte Projektdateien in einem Code-Repository konnten MCP-Server starten, bevor der Nutzer dem Projekt vertraut hatte, oder Anfragen samt API-Schlüssel an einen fremden Server umleiten. Die Lehre: Schon das Klonen eines fremden Repositories mit MCP-Konfiguration ist ein sicherheitsrelevanter Vorgang.
Tool Poisoning, also manipulierte Werkzeugbeschreibungen, die dem Modell versteckte Anweisungen unterschieben, gilt in der Branche als neue Form der Prompt-Injection. Kurz: Das Protokoll ist erwachsen geworden. Die Disziplin im Umgang damit noch nicht überall.
Fünf Punkte, bevor ein MCP-Server in Ihren Betrieb darf
Aus unserer Praxis beim Bau und Betrieb von MCP-Servern, verdichtet auf das, was ein Mittelständler ohne eigenes Sicherheitsteam leisten kann:
- Inventar führen, Schatten-IT verhindern. Legen Sie fest, wer MCP-Server anschließen darf, und führen Sie eine Liste: Welcher Server läuft wo, mit Zugriff auf welche Systeme? Die 1.467 offen erreichbaren Server sind selten böswillig entstanden. Meist hat sie schlicht niemand erfasst.
- Keine Verbindung ohne Authentifizierung. Ein MCP-Server ohne Anmeldung gehört nicht ins Netz, auch nicht „nur intern, nur kurz“. Die neue Spezifikation gibt mit gehärtetem OAuth den Standardweg vor. Nutzen Sie ihn, oder mindestens einen eigenen Schlüssel je Client.
- Herkunft prüfen statt blind installieren. Bevorzugen Sie Server der Hersteller selbst, etwa von Stripe, Notion oder Atlassian, oder aus dem offiziellen Verzeichnis. Bei allem anderen gilt: Code ansehen oder ansehen lassen. Wenn fast jeder zweite Quelltext Schlüssel unsicher ablegt, ist Vertrauensvorschuss fehl am Platz.
- Werkzeugbeschreibungen als Angriffsfläche behandeln. Prüfen Sie bei der Freigabe eines Servers nicht nur den Code, sondern auch die Beschreibungen der Werkzeuge, dort setzt Tool Poisoning an. Fixieren Sie geprüfte Versionen und lassen Sie sich warnen, wenn sich Werkzeugdefinitionen nach einem Update ändern.
- Rechte minimieren, Konfigurationen kontrollieren. Geben Sie jedem Server nur die Zugriffe, die seine Werkzeuge wirklich brauchen, lesend, wo lesend reicht. Behandeln Sie MCP-Konfigurationen in fremden Repositories wie ausführbaren Code. Halten Sie Clients und Server konsequent aktuell und stellen Sie vom alten SSE-Transport um.
Nichts davon ist Raketentechnik. Es ist dieselbe Hygiene, die Sie bei jedem neuen Stück Internet-Infrastruktur anwenden würden. MCP-Server brauchen sie nur besonders, weil sie per Definition tief in Ihre Systeme greifen. Wie sich ein Agent anmelden kann, ohne Passwörter zu sehen, zeigt unser Beitrag zum Agent-Authenticator.
Was das für Ihren Betrieb heißt
Die strategische Frage „Setzen wir auf MCP oder warten wir ab?“ hat sich erledigt. Eine Stiftung unter der Linux Foundation, die großen Modellanbieter als Träger, eine Spezifikation, die seit dem 28. Juli für den skalierten Betrieb gebaut ist: Wer heute eine Datenquelle oder ein Fachsystem für KI-Assistenten öffnen will, hat mit MCP einen Standard, der bleibt und der mit einer Anbindung alle relevanten Clients erreicht.
Die operative Frage hat sich dafür verschärft: nicht ob, sondern wie kontrolliert. Die Zahlen von Trend Micro und Check Point zeigen ein Ökosystem, in dem die Qualität der Bausteine stark schwankt und ungesicherte Server sich binnen Monaten fast verdreifachen. Unsere Empfehlung ist deshalb unaufgeregt: Fangen Sie mit einem klar umrissenen System an, ein MCP-Server, sauber angemeldet und mit minimalen Rechten. Arbeiten Sie die fünf Punkte oben ab, bevor der erste Agent produktiv zugreift. Dann ist MCP, was es inzwischen sein kann: Industrie-Infrastruktur und kein offenes Fenster. Wenn Sie den ersten Server sauber aufsetzen wollen, sprechen Sie uns gern an.
