KI-Anbindung wird enterprise-reif: Das Model Context Protocol unter der Linux Foundation

6 Min. Lesezeit

Als Anthropic Ende 2024 das Model Context Protocol vorstellte, war es ein cleverer Weg, Sprachmodelle an Werkzeuge und Daten anzubinden. Anderthalb Jahre später steht MCP unter dem Dach der Linux Foundation, trägt eine Apache-2.0-Lizenz und folgt einem planbaren Versions-Fahrplan. Aus dem Protokoll eines einzelnen Anbieters ist eine herstellerneutrale Grundlage geworden. Genau das entscheidet, ob Enterprise-IT es ernst nehmen kann.

Das Wichtigste in Kürze

• Governance statt Alleingang: MCP läuft seit Kurzem als Projekt der Linux Foundation unter Apache-2.0. Damit hängt das Protokoll nicht mehr an einem einzelnen Hersteller.
• Planbarer Lebenszyklus: Die stabile Spezifikation stammt vom 25. November 2025, die nächste Version liegt als Release Candidate vom 28. Juli 2026 vor. Neu ist ein Deprecation-Fenster von mindestens zwölf Monaten.
• Breite Basis: Neun offizielle SDKs, eine offizielle Server-Registry und zugesagte Unterstützung von OpenAI und Google geben Unternehmen die Reichweite, die sie brauchen.

Verwandt:AWS nimmt den Agenten-Unterbau ab  /  Cursor Cloud-Agents in der Praxis

Vom Anthropic-Protokoll zur Linux Foundation

Der wichtigste Schritt der letzten Monate ist kein technischer, sondern ein organisatorischer. MCP wurde als Projekt in die Linux Foundation überführt, die Beiträge laufen unter Apache-2.0. Für ein Protokoll, das die Verbindung zwischen KI-Modellen und Unternehmensdaten regelt, ist diese Verschiebung der eigentliche Reifetest. Wer eine Integration baut, will nicht, dass ein einzelner Anbieter die Spielregeln über Nacht ändert.

Die Maintainer sitzen weiterhin nah an der Praxis. Lead Maintainer ist David Soria Parra von Anthropic, an seiner Seite arbeitet Den Delimarsky, der aus dem Microsoft-Umfeld kommt. Das C#-SDK und die .NET-Anbindung tragen deutlich Microsoft-Handschrift. OpenAI und Google haben laut Branchenberichten Unterstützung für ihre Agentenplattformen zugesagt. Wenn die drei größten Modell-Anbieter dieselbe Schnittstelle sprechen, wird sie zum Standard.

Für Enterprise-IT zählt an diesem Punkt ein Wort: Herstellerunabhängigkeit. Eine offen lizenzierte Spezifikation in neutraler Trägerschaft lässt sich in Architektur-Entscheidungen einplanen, ohne dass ein Lizenz- oder Strategiewechsel eines Anbieters das ganze Fundament verschiebt.

Was enterprise-reif konkret bedeutet

Reife zeigt sich nicht am Funktionsumfang, sondern daran, wie berechenbar sich ein Protokoll über die Zeit verhält. Genau hier hat MCP zuletzt geliefert. Die stabile Spezifikation vom 25. November 2025 ist die Basis, auf der Teams heute bauen. Die nächste Version liegt seit Ende Mai als Release Candidate vor, der auf den 28. Juli 2026 datiert ist.

Neu und entscheidend ist der eingeführte Lebenszyklus. Funktionen durchlaufen klar benannte Zustände von aktiv über abgekündigt bis entfernt. Eine abgekündigte Funktion bleibt mindestens zwölf Monate erhalten. Für eine Produktivintegration ist das der Unterschied zwischen ruhiger Planung und hektischem Nachziehen bei jedem Update.

Dazu kommt die Sprachabdeckung. Neun offizielle SDKs decken Python, TypeScript, Java, Kotlin, C#, Go, Rust, Swift und Ruby ab. Ein Enterprise-Stack findet damit fast immer eine unterstützte Anbindung, ohne auf Community-Bastellösungen ausweichen zu müssen.

Die Registry und das Vertrauensproblem

Mit der Reife kommt eine neue Baustelle. Seit dem 8. September 2025 gibt es eine offizielle MCP-Registry in der Preview, die API wurde am 24. Oktober auf Version v0.1 eingefroren. Sie soll das werden, was Paket-Register für Programmiersprachen sind: die zentrale Stelle, an der man Server findet und einbindet.

Damit erbt MCP aber auch deren Kernproblem. Ein Register voller Server, die Modelle an echte Systeme lassen, ist ein attraktives Ziel. Wer einen manipulierten Server einbindet, öffnet einem Sprachmodell die Tür zu Daten und Aktionen. Die Lieferketten-Angriffe der letzten Monate im npm-Umfeld zeigen, wohin das führen kann. Für MCP-Server gilt dieselbe Sorgfalt.

Nicht zufällig sitzen in der Registry-Arbeitsgruppe Firmen mit Security-Fokus. Die Frage, wem ein Unternehmen im Register vertraut, ist kein Detail am Rand. Sie gehört ins Zentrum jeder MCP-Einführung.

Was IT-Teams jetzt evaluieren sollten

MCP ist an dem Punkt, an dem sich eine ernsthafte Bewertung lohnt. Vier Fragen führen durch die Entscheidung.

1. Server kuratieren. Nicht jeder Server aus der Registry gehört in die Produktion. Ein Unternehmen braucht eine eigene Liste geprüfter, freigegebener Server statt eines offenen Zugriffs auf alles.
2. Deprecation einplanen. Der zwölfmonatige Lebenszyklus ist eine Einladung, Migrationen im Voraus zu terminieren. Wer die Zustände aktiv überwacht, wird von keinem Update überrascht.
3. Registry-Vertrauen klären. Herkunft, Pflege und Berechtigungen jedes eingebundenen Servers gehören dokumentiert. Ein Server mit weitreichenden Rechten braucht dieselbe Prüfung wie eine neue Abhängigkeit im Code.
4. SDK-Wahl treffen. Die Sprache des eigenen Stacks bestimmt das SDK. Eine offiziell gepflegte Anbindung ist einer selbstgestrickten Lösung vorzuziehen, weil sie den Lebenszyklus automatisch mitgeht.

Bastelstand gegen enterprise-reifen Einsatz

Der Sprung der letzten anderthalb Jahre lässt sich an wenigen Punkten festmachen.

Was das für die Praxis heißt

MCP hat den Sprung vom interessanten Experiment zur planbaren Grundlage geschafft. Die neutrale Trägerschaft nimmt das größte Argument der Skeptiker vom Tisch, der Lebenszyklus macht Integrationen wartbar. Damit wird das Protokoll zu einer Option, die ein Architektur-Board ernsthaft abwägen kann.

Der Rest ist Handwerk. Wer heute mit MCP baut, gewinnt am meisten, wenn er die Registry mit derselben Vorsicht behandelt wie jede andere Lieferkette. Die Reife des Protokolls verschiebt die Verantwortung nicht, sie macht sie nur planbar. Genau das ist der Punkt, an dem aus einem Trend eine Infrastruktur-Entscheidung wird.

Häufige Fragen

Quelle Titelbild: KI-generiert (Juli 2026)