MCP Mitte 2026: Vom Anthropic-Experiment zur Industrie-Infrastruktur

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 — mitgegründet von Anthropic, OpenAI und Block, unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg.
• Am 28. Juli 2026 — in zwölf Tagen — wird die neue Spezifikation final. MCP wird stateless und damit erstmals sauber hinter gewöhnlichen Load-Balancern betreibbar. Das ist die Sprache von Rechenzentren, nicht von Hackathons.
• Security liefert das Protokoll nicht mit. Trend Micro zählte binnen weniger Monate eine Verdreifachung offen erreichbarer MCP-Server ohne Authentifizierung — von 492 auf 1.467. 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 Integration 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 Directed Fund unter dem Dach der Linux Foundation. Co-Founder sind Anthropic, Block und OpenAI — also ausgerechnet die beiden großen Modellanbieter gemeinsam. Google, Microsoft, AWS, Cloudflare und Bloomberg unterstützen die Stiftung.

Für Entscheider ist das der relevante Punkt: Ein Standard, der einem einzelnen Hersteller gehört, ist ein Risiko. Ein Standard unter neutraler Stiftungs-Governance mit formaler Deprecation-Policy — Änderungen werden zwölf Monate vorher angekündigt — ist Infrastruktur, auf der man planen kann. Die Zahlen zum Zeitpunkt der Übergabe: über 10.000 öffentliche MCP-Server, mehr als 97 Millionen SDK-Downloads pro Monat, native Unterstützung in ChatGPT, Claude, Gemini, Copilot, Cursor und VS Code.

Ein Server, alle Clients: Warum sich das rechnet

Die betriebswirtschaftliche Logik von MCP ist unspektakulär und genau deshalb überzeugend. Vor MCP bedeutete „unsere Daten für KI nutzbar machen": pro Assistent eine eigene Anbindung, jede mit eigener Wartung, eigenem Auth-Konzept, eigenem Bruchrisiko bei Updates. Mit MCP bauen Sie die Anbindung einmal — als MCP-Server vor Ihrem ERP, Ihrer Wissensdatenbank, Ihrem Ticketsystem — und jeder MCP-fähige Client kann sie nutzen.

Dass dieses Muster trägt, sehen wir bei azena in der eigenen Arbeit: Wir bauen für Kundenprojekte MCP-Server, unter anderem als Backend eines Brand-Studios und als Werkzeugschicht für Vertical Agents. Das Prinzip dort: ein Backend, zwei Türen — eine Web-Oberfläche für Menschen, ein MCP-Endpunkt für Agenten. Dieselben Werkzeuge, dieselben Datenverträge, keine doppelte Pflege. Der Aufwand steckt einmal im sauberen Werkzeug-Design, nicht in der x-ten Client-Integration.

Auch die Großen bauen längst produktiv: Stripe, PayPal, Shopify, Figma, Notion, Linear, Atlassian, Zapier, MongoDB und Microsoft betreiben eigene MCP-Server. Seit Januar 2026 gibt es mit MCP Apps zudem die erste offizielle Protokoll-Erweiterung — gemeinsam von Anthropic und OpenAI spezifiziert: Werkzeuge liefern nicht mehr nur Text zurück, sondern interaktive Oberflächen in abgeschotteten Iframes. Der MCP-Server wird damit vom Datenlieferanten zur eigenen Mini-Anwendung im Chat des Kunden. Welche UI-Patterns sich für Agenten-Oberflächen bewährt haben, zeigt unser Pattern-Katalog.

Die Spec vom 28. Juli: Stateless heißt betreibbar

Der Release Candidate der nächsten Spezifikation liegt seit dem 21. Mai 2026 vor; am 28. Juli wird sie final. Die wichtigste Änderung klingt technisch, ist aber ein Signal an jede IT-Abteilung: MCP wird stateless.

Bisher brauchte jede MCP-Verbindung einen Initialize-Handshake und eine Session-ID — der Server musste sich also merken, mit wem er spricht. Das ist für ein Entwickler-Tool auf dem Laptop egal, für den Betrieb hinter einem Load-Balancer aber ein Problem: Anfragen derselben Sitzung mussten immer beim selben Server landen. Die neue Spezifikation streicht den Handshake; der nötige Kontext reist als Metadaten in jedem einzelnen Request mit. Damit funktioniert schlichtes Round-Robin über beliebig viele Server-Instanzen — Skalierung wie bei jeder gewöhnlichen Web-API.

Dazu kommen weitere Punkte, die dieselbe Richtung markieren:

Header für Rate-Limiter, formale Auth-Härtung, Abkündigungsfristen — das sind keine Features 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 Euphorie eine Pause machen. Denn während Governance und Spezifikation gereift sind, gilt das für die Masse der real existierenden MCP-Server nicht.

Trend Micro hat Ende Mai 2026 über 19.000 öffentliche MCP-Server-Repositories analysiert und schätzt, dass 600 bis 1.650 davon — also gut drei bis knapp neun Prozent — ausnutzbare Schwachstellen enthalten: SQL-Injection, Remote Code Execution, Path Traversal. Bemerkenswert: 42,6 Prozent der bestätigt verwundbaren Repositories enthielten KI-generierten Code. Und die vielleicht wichtigste Zahl für KMU: Die Menge der offen aus dem Internet erreichbaren MCP-Server ganz ohne Authentifizierung hat sich im Beobachtungszeitraum von 492 auf 1.467 verdreifacht. Das sind Werkzeugschichten mit Zugriff auf interne Systeme, die ungeschützt im Netz stehen.

Auch die Client-Seite ist Angriffsfläche: Check Point meldete zwei inzwischen gepatchte Schwachstellen (CVE-2025-59536, CVE-2026-21852), bei denen präparierte Konfigurationsdateien in Code-Repositories — etwa eine mitgelieferte .mcp.json — Consent-Abfragen umgehen und im Extremfall Codeausführung auslösen konnten. Die Lehre daraus: Schon das Klonen eines fremden Repos mit MCP-Konfiguration ist ein sicherheitsrelevanter Vorgang.

Tool Poisoning — manipulierte Werkzeugbeschreibungen, die dem Modell versteckte Anweisungen unterschieben — wird in der Branche bereits als „das neue Prompt Injection" gehandelt. Die Cloud Security Alliance hat Best Practices veröffentlicht, eine OWASP MCP Top 10 ist in Arbeit.

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 eigenen Praxis beim Bau und Betrieb von MCP-Servern — verdichtet auf das, was ein KMU ohne eigenes Security-Team leisten kann:

1. 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.
2. Keine Verbindung ohne Authentifizierung. Ein MCP-Server ohne Auth gehört nicht ins Netz, auch nicht „nur intern, nur kurz". Die neue Spezifikation gibt Ihnen mit gehärtetem OAuth 2.0/OIDC den Standardweg vor — nutzen Sie ihn, oder mindestens API-Keys pro Client.
3. Herkunft prüfen statt blind installieren. Über 10.000 öffentliche Server stehen rund 2.000 Einträgen im offiziellen Registry gegenüber. Bevorzugen Sie Server der Hersteller selbst (Stripe, Notion, Atlassian & Co.) oder aus dem offiziellen Registry. Bei allem anderen gilt: Code ansehen oder ansehen lassen — die Trend-Micro-Quote von drei bis neun Prozent verwundbaren Repos ist zu hoch für Vertrauensvorschuss.
4. Tool-Beschreibungen als Angriffsfläche behandeln. Prüfen Sie bei der Freigabe eines Servers nicht nur den Code, sondern die Werkzeugbeschreibungen selbst — dort setzt Tool Poisoning an. Fixieren Sie geprüfte Versionen und lassen Sie sich alarmieren, wenn sich Tool-Definitionen nach einem Update ändern.
5. Rechte minimieren, Repo-Configs kontrollieren. Geben Sie jedem Server nur die Zugriffe, die seine Werkzeuge wirklich brauchen — lesend, wo lesend reicht. Und behandeln Sie MCP-Konfigurationsdateien in fremden Repositories wie ausführbaren Code: Die Check-Point-Funde zeigen, dass genau dort angesetzt wird. Clients und Server konsequent aktuell halten.

Nichts davon ist Raketentechnik. Es ist dieselbe Hygiene, die Sie bei jedem neuen Stück Internet-Infrastruktur anwenden würden — nur dass MCP-Server sie besonders brauchen, weil sie per Definition tief in Ihre Systeme greifen.

Was das für Ihren Betrieb heißt

Die strategische Frage „Setzen wir auf MCP oder warten wir ab?" hat sich in den letzten sieben Monaten von selbst erledigt. Stiftungs-Governance unter der Linux Foundation, beide großen Modellanbieter als Co-Founder, eine Spezifikation, die ab dem 28. Juli offiziell 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 verdreifachen. Unsere Empfehlung ist deshalb unaufgeregt: Fangen Sie mit einer klar umrissenen Vertikale an — ein System, ein MCP-Server, sauber authentifiziert und mit minimalen Rechten. Arbeiten Sie die fünf Punkte oben ab, bevor der erste Agent produktiv zugreift. Dann haben Sie das, was MCP Mitte 2026 tatsächlich ist: Industrie-Infrastruktur — und kein offenes Fenster.