MCP-Registry erklärt: Wie zentrale Kataloge das N×M-Problem lösen

Ein MCP-Registry ist mehr als nur eine Liste verfügbarer Tools: Es ist das zentrale Nervensystem für die Verwaltung von MCP-Servern in Unternehmen. Statt dass jede Entwicklerin und jeder Agent ihre eigene Konfigurationsdatei pflegt, sammelt das Registry alle relevanten Informationen an einem Ort – von Verbindungseinstellungen über Authentifizierungsmethoden bis hin zu detaillierten Zugriffsrechten. Doch warum ist das so revolutionär?

Nehmen wir an, Ihr Team nutzt mehrere MCP-Server: einen für GitHub, einen für Jira, einen für interne Datenbanken und einen für Slack. Ohne Registry müssten alle Teammitglieder jeweils ihre eigene mcp.json oder .claude/settings.json aktualisieren, sobald sich ein Endpunkt ändert oder ein Token rotiert. Selbst bei nur sechs Servern und zwölf Entwickler:innen wird daraus schnell ein Albtraum aus veralteten Konfigurationen und Sicherheitslücken. Ein Registry übernimmt diese Aufgabe zentral – und reduziert die Komplexität von N×M auf N+M.

Was ein MCP-Registry genau ist

Ein MCP-Registry ist eine zentrale Datenbank, die alle Metadaten zu MCP-Servern in Ihrem Unternehmen speichert. Dazu gehören:

• Identität und Beschreibung des Servers, inklusive verantwortlichem Team und Freigabestatus
• Verbindungsdetails wie Endpunkt-URL und Transportprotokoll (z. B. stdio, Streamable HTTP oder SSE)
• Authentifizierungsinformationen, die beschreiben, welche Anmeldemethoden der Server unterstützt
• Tool-Schema, also eine detaillierte Liste aller verfügbaren Funktionen und deren Parameter
• Zugriffsrichtlinien, die definieren, wer welche Tools nutzen darf

Der entscheidende Vorteil liegt in der Trennung von Verbindungsdaten und Authentifizierung. Wenn sich beispielsweise ein GitHub-Token ändert, reicht ein einziger Eintrag im Registry aus – alle Agenten und Entwickler:innen greifen automatisch auf die neuen Anmeldedaten zu. Ohne Registry müsste jede:r einzeln die Konfiguration aktualisieren.

Das N×M-Problem: Warum dezentrale Konfigurationen scheitern

In der Praxis führt die direkte Verbindung von N Agenten mit M MCP-Servern zu einer exponentiell wachsenden Komplexität. Bei drei Agenten und drei Servern sind es bereits neun Integrationpunkte. Bei acht Agenten und sechs Servern steigt die Zahl auf 48. Und bei 240 Entwickler:innen und acht Servern müssen rund 1.900 Konfigurationen manuell verwaltet werden – eine Aufgabe, die schnell unüberschaubar wird.

Ein Registry löst dieses Problem, indem es die Integration auf N+M reduziert. Jeder Server wird nur einmal registriert, und jeder Agent fragt beim Registry nach den benötigten Tools und Zugriffsrechten. Wird ein Server verschoben, aktualisiert man nur einen Eintrag im Registry – alle Abhängigkeiten bleiben intakt. Zudem ermöglicht das Registry eine granulare Zugriffskontrolle, die in direkten Verbindungen nicht möglich wäre.

Drei Mythen über MCP-Registries – und was sie wirklich leisten

MCP-Registries werden oft mit anderen Konzepten verwechselt. Hier die wichtigsten Klarstellungen:

1. Das öffentliche MCP-Registry (z. B. bei `registry.npmmcp.com`) dient lediglich der Entdeckung. Es ist wie ein App Store für MCP-Server: Entwickler:innen können darin nach verfügbaren Tools suchen und sie herunterladen. Doch Authentifizierung, Zugriffskontrolle oder Protokollierung gehören nicht zu seinen Aufgaben. Es ist ein nützliches Werkzeug für die Suche – aber keine Produktionsinfrastruktur.

2. Ein unternehmensinternes Registry ist die Lösung für skalierbare MCP-Nutzung. Während das öffentliche Registry Tools nur auflistet, verwaltet das interne Registry deren Verbindung, Sicherheit und Berechtigungen. Es entscheidet, wer welche Tools nutzen darf – und wie diese Tools angesprochen werden.

3. Ein Registry ist kein Proxy. Ein Proxy übernimmt den Transport der Daten, während das Registry für Metadaten und Richtlinien zuständig ist. In der Praxis arbeiten beide oft zusammen: Das Registry weiß, welche Server existieren, und der Proxy leitet die tatsächlichen Anfragen weiter. Doch die Verantwortlichkeiten bleiben klar getrennt.

Sicherheitslücken in rohem MCP – und wie Registries sie schließen

Das MCP-Protokoll selbst bietet keine eingebaute Zugriffskontrolle. Jeder Agent mit der URL eines Servers kann alle dessen Tools aufrufen – unabhängig davon, ob es sich um eine Junior-Entwicklerin oder einen Senior Engineer handelt. Selbst ein überprivilegierter Sub-Agent hat denselben Zugriff wie ein Service-Account. Das Registry fügt hier eine entscheidende Schicht ein:

• Rollenbasierte Zugriffskontrolle (RBAC): Statt nur zu definieren, wer auf einen Server zugreifen darf, legt das Registry fest, welche konkreten Tools eine Person oder ein Agent nutzen kann. So darf ein Team beispielsweise search_issues und create_issue in Jira nutzen, nicht aber delete_issue.

• Filterung vor dem Tool-Aufruf: Wenn ein Agent die Liste der verfügbaren Tools abfragt, erhält er nur diejenigen, für die er berechtigt ist. Ein Agent, der keine destruktiven Funktionen sieht, kann sie auch nicht versehentlich aufrufen.

• Zentrale Verwaltung von Anmeldedaten: Nutzer:innen authentifizieren sich einmalig im Registry. Alle weiteren Zugriffe erfolgen über temporäre Tokens oder Service-Accounts, die zentral verwaltet werden. Bei einer Token-Rotation müssen keine individuellen Konfigurationen angepasst werden.

Fazit: Warum jedes Team mit MCP-Servern ein Registry braucht

Die Einführung von MCP-Registries markiert einen Wendepunkt in der Verwaltung von MCP-Servern. Statt sich in veralteten Konfigurationen und manuellen Updates zu verlieren, können Teams ihre Integrationen standardisieren, Sicherheitsrisiken minimieren und die Skalierbarkeit sicherstellen. Besonders in größeren Unternehmen, in denen viele Entwickler:innen und Agenten auf mehrere Server zugreifen, wird ein Registry schnell zur unverzichtbaren Infrastruktur.

Die Zukunft der MCP-Nutzung liegt nicht in isolierten Konfigurationen, sondern in zentralisierten Ökosystemen, die Sicherheit, Skalierbarkeit und Benutzerfreundlichkeit vereinen. Wer heute in ein MCP-Registry investiert, spart morgen nicht nur Zeit – sondern auch Ärger und Sicherheitslücken.