Red Hats Developer Preview eines MCP-Katalogs für OpenShift AI adressiert ein Problem jenseits des Experiments: Wie entdecken, installieren und verbinden Teams MCP-Server, ohne dass jeder Entwickler einen eigenen Pfad erfindet? Ein Katalog kann Paketierung und Lifecycle standardisieren. Er entscheidet jedoch nicht, welche Werkzeuge Zugriff auf Unternehmenssysteme verdienen.
Bedeutung für den Betrieb
Ein MCP-Server ist eine Integrationsgrenze. Er kann Daten bereitstellen, Operationen ausführen oder Modellanfragen in API-Aufrufe übersetzen. Die Freigabe braucht deshalb Belege zu Quellherkunft, Image-Signatur, Pflege, Credentials, Netzzielen, an das Modell zurückgegebenen Daten und Fehlerverhalten. Der bequeme Installationsknopf steht am Ende der Prüfung.
Eigene Katalogeinträge erhöhen die Bedeutung von Verantwortung. Plattformteams definieren, wer Server veröffentlichen darf, wie Versionen promoviert werden, wie Secrets eingebunden sind, welche Namespaces und Servicekonten gelten und wie eine Notfallentfernung funktioniert. Verbraucher benötigen eine klare Fähigkeitsbeschreibung, damit ein Lesekonnektor nicht mit einem Operations-Werkzeug verwechselt wird.
Ein sinnvoller Pilot beginnt mit einem risikoarmen Server, beschränkt Netz- und Datenumfang, protokolliert jeden Aufruf und testet Update sowie Widerruf. Gemessen wird nicht nur Bereitstellungstempo, sondern ob Security Benutzer, Zugriff und aktive Version nachweisen kann. Der Developer-Preview-Status ist ein Grund, den Lifecycle zu lernen, ohne den Katalog zur Produktionsabhängigkeit zu machen.
Praktische Konsequenz
Die praktische Schlussfolgerung: MCP-Kataloge sind Plattformprodukte. Ihr Wert ist der kontrollierte Weg von Entdeckung bis Entfernung. Endet Governance bei der Installation, gewinnt die Organisation schnelle Integration und langsame Störungsaufklärung. Der Katalog muss sichere Entscheidungen erleichtern und riskante Fähigkeiten vor ihrer Vergabe sichtbar machen.