Sie haben wahrscheinlich schon von MCP gehört. Model Context Protocol, der Standard, mit dem KI-Agenten mit externen Tools kommunizieren können. Vielleicht haben Sie bereits ein oder zwei Server eingerichtet. Doch dann erwähnt jemand „die Registry“, und Sie nicken, als wüssten Sie genau, was damit gemeint ist.
Die meisten Menschen wissen es nicht. Zumindest nicht genau. Und diese Unschärfe verursacht echte Probleme, sobald Sie etwas entwickeln, das tatsächlich skalieren muss.
Hier erfahren Sie, was die MCP Registry wirklich ist, was sie nicht ist und warum Teams, die sie heute überspringen, später meist viel Zeit damit verbringen, fest codierten Spaghetti-Code zu entwirren.
Was die meisten Teams erst sechs Monate zu spät lernen
- Die Registry speichert Metadaten und Installationsverweise, keine Server-Binärdateien – diese liegen in npm oder PyPI.
- Ohne Registry ist jede Agent-zu-Tool-Verbindung ein individuell fest codierter Endpunkt, der unabhängig ausfällt, sobald sich etwas ändert.
- Die Einführung von KI im Unternehmen hängt von Registry-gestützter Governance ab: Discovery allein reicht nicht aus.
Was die MCP Registry wirklich ist (und was nicht)
Die MCP Registry ist das offizielle zentralisierte Metadaten-Repository für öffentlich zugängliche MCP-Server. Diese Formulierung ist bewusst präzise. Kein Runtime-Host. Kein Paket-Store. Ein Metadaten-Repository.
Wenn ein Server-Autor in der Registry veröffentlicht, werden dort strukturierte Metadaten hinterlegt: Servername, Beschreibung, Transporttyp, Verbindungsdetails und Installationsanweisungen, codiert in einem mcp.json-Schema. Die eigentliche Server-Binärdatei wird nicht verschoben. Das Artefakt bleibt in npm, PyPI oder der Container-Registry, in der es bereits liegt. Die MCP Registry weiß lediglich, wo sie zu finden ist und wie sie beschrieben werden kann.
Das ist das Missverständnis, das ich am häufigsten sehe. Jemand fragt, warum er ein Tool nicht aus der Registry „herunterladen“ kann oder warum ein dort gefundener MCP-Server nicht über die Registry-URL ausgeführt wird. Er wird nicht von dort ausgeführt. Das war auch nie vorgesehen. Die Registry ist eine Control Plane, kein Host.
Stellen Sie sie sich wie den Katalogeintrag in einem Bibliothekssystem vor. Der Eintrag sagt Ihnen, was das Buch ist, wo es steht und ob es verfügbar ist. Das Buch steht im Regal. Der Katalog ist etwas völlig anderes.
Im April 2026 waren in der offiziellen Registry unter registry.modelcontextprotocol.io mehr als 9.600 Einträge gelistet, während Anthropic von mehr als 10.000 aktiven öffentlichen Servern im gesamten Ökosystem spricht. Diese Größenordnung ist ein wesentlicher Grund, warum ein strukturierter Discovery-Mechanismus nicht länger optional ist.
Die Architektur der Registry: Metaregistry, API und Sub-Registries
Die MCP Registry ist nicht einfach nur eine einzelne gehostete Website. Sie ist eine Spezifikation mit einer darauf aufbauenden gehosteten Referenzimplementierung.
Wie die Metaregistry Metadaten speichert und bereitstellt
Die Registry arbeitet als Metaregistry: eine zentrale Quelle der Wahrheit für strukturierte Metadaten, während die tatsächlichen Artefakte in externen Paket-Registries liegen. Jeder Eintrag folgt einem definierten Schema, das meist über mcp.json verfügbar gemacht wird und Verbindungsdetails, unterstützte Transports (SSE, streamable HTTP), Umgebungskonfigurationen sowie ausreichend Beschreibungen enthält, damit ein Agent oder Entwickler entscheiden kann, ob der Server relevant ist.
Die Registry stellt einen Katalog aus Installationsverweisen und maschinenlesbaren Beschreibungen bereit. Sie ist kein Binär-Repository. Sie fragen sie ab, um herauszufinden, was existiert und wie Sie es beziehen können. Um es tatsächlich zu beziehen, gehen Sie woanders hin. Diese Trennung ist beabsichtigt und für die Sicherheit wichtig: Die Registry kann moderiert werden, ohne selbst zum Paket-Host zu werden.
Öffentliche und private Sub-Registries
Die Registry-API ist eine Spezifikation. Das bedeutet, dass jeder neben oder unterhalb der offiziellen Registry eine konforme Registry implementieren kann. Unternehmen müssen nicht ausschließlich die offizielle MCP Registry verwenden. Sie können eine private Sub-Registry für interne Server betreiben, die nicht für eine öffentliche Listung geeignet sind, und diese mit der offiziellen Registry föderieren, sodass Agenten eine einheitliche Discovery-Oberfläche sehen.
Namespaces sowie öffentliche und private Sub-Registries ermöglichen es Unternehmen, die Sichtbarkeit pro Umgebung, Team oder Entwicklerprofil zu steuern, ohne alles in einer undifferenzierten Liste zusammenzufassen. Ein Staging-Namespace zeigt andere Server als ein Produktions-Namespace. Ein Teamprofil mit Sicherheitsfreigabe zeigt Server, die ein allgemeines Engineering-Profil nicht sieht. Dieses Föderationsmodell ermöglicht es der Registry-Spezifikation, die Fragmentierung bestehender Registries zu reduzieren, statt jeden zum Neustart zu zwingen.
📊 In der Praxis:
Die offizielle Registry wurde im Preview-Status eingeführt. Teams, die Produktionssysteme entwickeln, sollten konforme private Sub-Registries für interne Server implementieren, statt auf die allgemeine Verfügbarkeit zu warten, da das Föderationsmodell der Spezifikation dies direkt unterstützt und Sie nicht von einem einzigen Abhängigkeitspunkt abhängig macht.
Das N×M-Problem: Warum KI-Agenten bei Skalierung eine Registry brauchen
Hier ist das Skalierungsproblem, das Registries notwendig macht, ganz klar formuliert.
Stellen Sie sich vor, Sie haben fünf KI-Agenten. Jeder muss vier verschiedene MCP-Tools aufrufen: einen Grafana-Server, einen Gmail-Server, einen Jira-Server und eine interne Wissensdatenbank. Ohne Registry codiert jeder Agent den Endpunkt für jedes Tool fest. Das sind fünf Agenten mal vier Tools: zwanzig separate fest codierte Verbindungen. Jede einzelne muss den exakten Endpunkt, die Transportkonfiguration und die Authentifizierungsdetails kennen.
Nun verdoppelt sich Ihre Agentenzahl auf zehn. Sie fügen drei neue Tools hinzu. Jetzt haben Sie zweiundfünfzig Verbindungen, die alle einzeln gepflegt werden müssen. Ein Tool verschiebt seinen Endpunkt. Sie aktualisieren ihn bei einigen Agenten, übersehen aber zwei. Diese beiden beginnen auf eine Weise auszufallen, die wie Authentifizierungsprobleme aussieht, bis jemand die veraltete URL als Ursache identifiziert.
Das ist das N×M-Problem. Wie TrueFoundry es beschreibt: Ohne Registry erfordert jede neue Agent-Tool-Kombination eine neue individuelle Verbindung, und die Wartungskosten wachsen multiplikativ statt linear.
Eine Registry durchbricht diese Multiplikation. Agenten fragen die Registry ab, um herauszufinden, was verfügbar ist und wo. Tools registrieren sich einmal und werden von jedem Agenten entdeckt, der sie benötigt. Die Registry enthält die verlässlichen Endpunktinformationen. Agenten müssen sie nicht mehr selbst vorhalten.
🤔 Denken Sie darüber nach:
Teams überspringen Registry-Governance oft mit der Begründung: „Wir haben derzeit nur vier Tools.“ Genau diese Teams haben sechs Monate später dreißig fest codierte Verbindungen, wenn sich ihre Agentenzahl verdreifacht hat. Die N×M-Mathematik wartet nicht darauf, dass Sie sich bereit dafür fühlen.
Was die MCP Registry ermöglicht: Discovery, Authentifizierung und Governance
Discovery ist die offensichtliche Funktion. Governance ist die Funktion, die bei Skalierung wichtiger wird.
Tool-Discovery für KI-Agenten und LLM-Anwendungen
Ein Agent, der eine Registry verwendet, muss nicht im Voraus wissen, welche MCP-Tools existieren. Er fragt die Registry dynamisch ab und erhält eine Liste verfügbarer MCP-Server mit ausreichend Metadaten, um zu entscheiden, welcher zum aktuellen Vorgang passt. Das ist der Unterschied zwischen einem Agenten, der nur Tools aufrufen kann, die sein Entwickler beim Aufbau kannte, und einem Agenten, der das richtige Tool für einen neuen Kontext finden kann, für den er nicht ausdrücklich entwickelt wurde.
Praktisch bedeutet das: Ein Kundensupport-Agent fragt die Registry ab, findet einen Grafana MCP-Server für Infrastrukturmetriken und einen Gmail MCP-Server für die Kundenhistorie, wählt beide anhand ihrer Beschreibungen und Schemata aus und arbeitet weiter. Keiner der Endpunkte wurde im Agenten fest codiert. Die Registry ist die Infrastruktur, die dies für KI-Anwendungen in großem Maßstab ermöglicht.
Bei mehr als 9.600 Servern in der offiziellen Registry ist eine manuelle Auswahl faktisch keine Option mehr. Die Registry macht dieses Ökosystem nutzbar, statt es lediglich groß zu machen.
Authentifizierung und zugriffssteuerung mit Namespace-Geltungsbereich
Registries steuern auch, was Agenten überhaupt sehen dürfen. Eine Registry kann Authentifizierung und auf Namespaces begrenzte Konfigurationen durchsetzen, welche die Server-Sichtbarkeit nach Umgebung, Rolle oder Entwicklerprofil beschränken.
AWS Q Developer setzt beispielsweise über eine in Entwicklerprofilen eingebettete Registry-URL erlaubnisgelistete MCP-Server durch. Ein Agent, der in dieser Umgebung ausgeführt wird, sieht nur die genehmigten MCP-Server, welche die Registry für dieses Profil bereitstellt. Server außerhalb der Erlaubnisliste erscheinen schlicht nicht. Es gibt keinen Konflikt mit Sperrlisten und keine Ablehnung zur Laufzeit: Die Konfiguration bestimmt den Discovery-Umfang, bevor der Agent überhaupt fragt.
Das ist RBAC auf der Discovery-Ebene, nicht nur auf der Ausführungsebene. So können Sie dem Agentenprofil eines Junior-Entwicklers Zugriff auf Dokumentations- und Such-Tools geben, während das Profil eines erfahrenen Platform Engineers Infrastruktur- und Deployment-Server erreichen kann. Dieselbe Registry, unterschiedliche Geltungsbereiche.
Governance, Moderation und Community-basierte Vertrauensrichtlinien
Die Registry ist außerdem ein Kontrollpunkt für Sicherheit. Die Berichterstattung von InfoWorld zur MCP-Einführung in Unternehmen formuliert dies ausdrücklich: Die Registry ist nicht nur ein Tool-Katalog, sondern eine zentrale Control Plane für agentische KI. Die Position der MACH Alliance zu herstellerneutraler Governance unterstreicht dies: Die Governance-Schicht sollte unabhängig vom Durchsetzungsmechanismus eines einzelnen Anbieters sein.
In der Praxis bedeutet das: Die offizielle Registry nutzt Community-basierte Moderation, um Server zu markieren, die nicht verifiziert erscheinen, legitime Dienste imitieren oder nicht anhand grundlegender Sicherheitskriterien geprüft wurden. Enterprise-Sub-Registries können darüber hinaus interne Validierungs-Workflows ergänzen. Bevor ein Server gelistet wird, kann verlangt werden, dass er Audit-Prüfungen besteht, einen zugewiesenen Verantwortlichen hat und eine dokumentierte Risikoklassifizierung trägt. Die Registry wird zum Durchsetzungspunkt, nicht nur zum Katalog.
Wo die MCP Registry in einen Enterprise-KI-Stack passt
Enterprise-Teams, die MCP in großem Maßstab einführen, beginnen meist mit demselben Discovery-Problem: Jemand muss einen Server finden, öffnet elf Tabs, ist nicht sicher, welche Registry maßgeblich ist, und kopiert schließlich eine Konfiguration aus einer GitHub-Readme, die zuletzt vor acht Monaten aktualisiert wurde.
Ab diesem Moment wird eine Enterprise-MCP-Registry zur Infrastruktur statt zu einer bloßen Annehmlichkeit.
InfoWorlds Bericht zur MCP-Implementierung in Unternehmen beschreibt das Muster klar: Unternehmen stellen schnell fest, dass einfache Tool-Kataloge nicht ausreichen. Sie benötigen Autorisierung pro Agent, umfassende Beobachtbarkeit des Agentenverhaltens und Inline-Durchsetzung von Richtlinien, wenn die Zahl laufender MCP-Server wächst. JFrog, WorkOS, TrueFoundry und AWS betrachten die Registry allesamt als Governance-orientierten Infrastrukturbaustein und nicht als Entwicklerkomfort.
Die Registry liegt zwischen Ihren Agenten und Ihren Tools. Sie zentralisiert die Metadaten, die Ihre Agenten für Routing-Entscheidungen benötigen, enthält die Zugriffskontrolllogik, die bestimmt, welche Agenten welche MCP-Server erreichen, und führt den Audit-Nachweis, der Sicherheitsteams im Nachhinein zeigt, was passiert ist. Für einen Enterprise-KI-Stack ist dies die vorgelagerte MCP-Registry-Schicht: die Ebene, auf der Governance tatsächlich stattfindet.
Ein Implementierungsmuster, das sich bewährt hat: Ein Platform-Team erstellt in Latenode einen Workflow, der potenzielle Einträge aus der offiziellen Registry-API abruft, die Metadaten jedes Servers mithilfe eines der mehr als 1.200 verfügbaren KI-Modelle mit konsistenten internen Beschreibungen und Risikokennzeichnungen anreichert und das kuratierte Ergebnis anschließend in eine interne Registry schreibt. Derselbe Workflow wird nach Zeitplan ausgeführt, um mit dem Wachstum des Ökosystems aktuell zu bleiben. Sechs Schritte, eine Ausführung in Latenodes Preismodell, und das Team verbringt keine Tage mehr mit manueller Discovery. Der Workflow ersetzt die Registry nicht. Er baut die interne Kontrollschicht darauf auf.
Drei Missverständnisse, die Registry-Setups von Teams immer wieder beeinträchtigen
Diese Punkte treten immer wieder auf. Sie früh falsch zu verstehen, führt zu Problemen, die später mühsam zu entwirren sind.
Die Registry hostet tatsächliche Server und Binärdateien
Das ist das häufigste Missverständnis. Teams erwarten, in der Registry ausführbare Serverpakete zu finden, so wie sie Pakete in npm finden würden. Stattdessen finden sie Metadaten: Beschreibungen, Schemata, Transporttypen und Installationsanweisungen, die auf npm, PyPI oder eine Container-Registry verweisen. Wenn sie etwas nicht über die Registry-URL „ausführen“ können, nehmen sie an, dass etwas nicht funktioniert. Das stimmt nicht. Die Registry ist ein Metadaten-Repository. Wer sie als Marketplace oder Paket-Store behandelt, sucht am richtigen Ort nach dem Falschen.
Sie müssen ausschließlich die offizielle MCP Registry verwenden
Die offizielle Registry unter
registry.modelcontextprotocol.ioist eine Referenzimplementierung, nicht die einzige zulässige Registry. Die Registry-API ist eine Spezifikation, die jedes Unternehmen implementieren kann. Sie können eine private Sub-Registry für interne Server betreiben, sie mit der offiziellen Registry föderieren und Ihren Agenten eine einheitliche Discovery-Oberfläche bereitstellen, die beides umfasst. Teams, die davon ausgehen, an die offizielle Registry gebunden zu sein, veröffentlichen entweder interne Server öffentlich – problematisch – oder pflegen einen separaten, nicht auffindbaren Katalog, den Agenten nicht dynamisch nutzen können – ebenfalls problematisch. Die offizielle Registry ist eine gute primäre Quelle der Wahrheit für MCP-Server, aber nicht die einzige Quelle.Registries sind nur für Demos und Experimente, nicht für die Produktion
Die offizielle Registry wurde im Preview-Status eingeführt, was manchen Teams einen Vorwand gibt, sie aufzuschieben. Der Preview-Status bedeutet, dass vor der allgemeinen Verfügbarkeit Daten zurückgesetzt werden und Breaking Changes möglich sein können – ein Faktor, den Sie bei der Entwicklung von Produktionssystemen berücksichtigen sollten. Das ist jedoch ein Argument dafür, eine konforme private Registry mit stabilen Zusicherungen zu betreiben, und kein Argument dafür, die Registry-Schicht vollständig zu überspringen. Die MCP-Registries, die Enterprise-Teams derzeit in Produktion einsetzen, sind private Implementierungen derselben Spezifikation. Das offiziell gehostete Preview ist eine Instanz eines umfassenderen Musters, das in Enterprise-Umgebungen bereits produktionsreif ist.
Dieses letzte Missverständnis ist das kostspielige.
