Was ist eine MCP Registry? Das zentrale Verzeichnis für MCP-Server

Wer wissen will, welche MCP-Server in seiner Organisation laufen, muss heute die Konfigurationsdateien der Agents durchsuchen. Dutzende Dateien in Repositories und auf Entwickler-Laptops beschreiben, welcher Agent welchen Server erreichen darf und welche Tools er dort vorfindet. Zusammengenommen sind diese Dateien die MCP Registry des Unternehmens, allerdings ohne Suchfunktion, ohne Zugriffskontrolle und ohne Audit-Trail.

Eine MCP Registry bündelt diese verstreuten Informationen in einem geführten Verzeichnis. Sie inventarisiert alle MCP-Server einer Organisation, regelt den Zugriff auf deren Tools und protokolliert, welcher Agent was aufruft. Dieser Artikel ordnet ein, warum dieser Baustein unverzichtbar wird, sobald Agents produktive Systeme erreichen, und worin sich eine MCP Registry von einem MCP Gateway und den öffentlichen Server-Verzeichnissen unterscheidet.

Warum sich die Frage gerade jetzt stellt

In den vergangenen zwölf Monaten haben viele Teams ihre ersten Agents in produktive Abläufe gebracht. Mit jedem Anwendungsfall kamen MCP-Server hinzu. Eigene Server für interne APIs, fertige Server für GitHub, Jira oder Datenbanken, dazu Experimente einzelner Entwickler. Ein Bestand von zehn oder mehr Servern entsteht auf diesem Weg schneller, als die meisten vermuten.

In der API-Welt gleicht ein menschliches Sicherheitsnetz vieles aus. Ein Entwickler, dem eine Information fehlt, fragt im Zweifel den Kollegen und merkt dabei, wenn etwas nicht stimmt. Einem Agenten fehlt dieses Korrektiv. Er arbeitet mit dem, was seine Konfiguration ihm anbietet, und zwar mit jeder Berechtigung, die der hinterlegte Token hergibt. Eine veraltete oder zu großzügige Konfiguration bleibt deshalb oftmals so lange unbemerkt, bis ein Agent produktive Daten ändert, die er nur hätte lesen sollen.

Auffällig ist dabei eine Asymmetrie. Für APIs existieren in den meisten Organisationen Kataloge, Review-Prozesse und Audit-Trails. Für die MCP-Server, über die Agents auf dieselben APIs zugreifen, gibt es vielerorts noch nicht einmal eine vollständige Liste.

Was eine MCP Registry ist und was nicht

Eine MCP Registry ist die Inventar- und Governance-Schicht für MCP-Server. Sie führt jeden Server mit Endpoint, Transport und Authentifizierung samt der Liste seiner Tools auf, macht diesen Bestand durchsuchbar und legt fest, wer was verwenden darf. Der Begriff wird derzeit allerdings für drei unterschiedliche Dinge verwendet, was die Einordnung erschwert.

• Eine interne MCP Registry inventarisiert und governt die Server der eigenen Organisation. Um diese Form geht es in diesem Artikel.
• Ein MCP Gateway sitzt zur Laufzeit zwischen Agent und Server. Es leitet Tool-Aufrufe weiter, übernimmt Authentifizierung und Rate-Limiting und gehört damit zur Runtime-Infrastruktur.
• Öffentliche Verzeichnisse wie Glama, PulseMCP oder Smithery listen frei verfügbare Server aus dem gesamten Ökosystem. Sie helfen zwar bei der Suche nach fertigen Bausteinen, treffen aber keine Aussage darüber, was im eigenen Unternehmen läuft oder erlaubt ist.

Die wichtigste Abgrenzung betrifft das Gateway. Eine MCP Registry ist kein Runtime-Proxy, sondern Design-Time-Governance. Sie muss daher auch dann funktionieren, wenn Tool-Aufrufe direkt vom Agenten zum Server laufen, und sie bleibt neutral, wenn mehrere Gateways im Einsatz sind.

Die vier Säulen einer MCP Registry

Vier Fähigkeiten machen aus einem Verzeichnis eine Registry. Jede von ihnen beantwortet eine Frage, die ohne Registry regelmäßig offen bleibt.

Der Katalog beantwortet, welche Server existieren und welche Tools sie anbieten. Fehlt er, bauen Teams Server doppelt oder binden veraltete Endpoints an, weil schlicht niemand den Bestand kennt.

Die Zugriffskontrolle beantwortet, wer ein Tool verwenden darf. Ohne sie erbt jeder Agent die vollen Rechte seines Tokens, und ein Assistent für Dokumentationsfragen kann plötzlich produktive Tickets anlegen.

Der Audit-Trail beantwortet, wer ein Tool tatsächlich verwendet hat. Spätestens im Security-Review wird diese Frage verbindlich, und ohne Protokoll bleibt dann nur die mühsame Rekonstruktion aus den Logs verteilter Systeme.

Policies machen Regeln schließlich durchsetzbar, etwa dass produktive Tools für experimentelle Agents gesperrt bleiben. In den meisten Organisationen entsteht diese Säule zuletzt, weil sie auf den drei anderen aufsetzt.

Die Tool-Ebene ist die eigentliche Berechtigungsebene

Wer den Zugriff auf MCP-Server regelt, denkt zunächst in Servern. Diese Granularität ist jedoch trügerisch. Ein einzelner Server exponiert häufig dutzende Tools, und zwischen einem lesenden Status-Tool und einem schreibenden Lösch-Tool liegt der gesamte Risikoraum eines Systems.

Eine MCP Registry muss Berechtigungen deshalb pro Tool abbilden. In der Praxis hat sich Allowlisting bewährt. Freigegeben ist, was explizit erlaubt wurde, alles andere bleibt gesperrt. Das kehrt die Beweislast um und verhindert, dass neue Tools eines aktualisierten Servers unbemerkt nutzbar werden.

Woher die Registry ihre Wahrheit bezieht

Ein Verzeichnis, das von Hand gepflegt wird, läuft den Änderungen zwangsweise hinterher. Bei MCP-Servern verschärft sich das noch, weil sich die Tool-Liste eines Servers mit jedem Deployment ändern kann. Die tragfähige Quelle ist daher der Server selbst.

Das Model Context Protocol liefert die Grundlage gleich mit. Jeder MCP-Server beantwortet die Anfrage tools/list mit einer maschinenlesbaren Beschreibung seiner Tools samt Parametern.

{
  "tools": [
    {
      "name": "search_api_schemas",
      "description": "Search schema definitions across all registered APIs",
      "inputSchema": {
        "type": "object",
        "properties": { "query": { "type": "string" } }
      }
    }
  ]
}

Eine Registry, die diese Antwort regelmäßig abruft und mit dem letzten Stand vergleicht, erkennt neue, geänderte und entfernte Tools automatisch. Der Mechanismus entspricht dem Git-Sync eines API-Katalogs, nur dass die Quelle hier der laufende Server ist. Warum automatischer Abgleich gegenüber zentraler Pflege so deutlich gewinnt, haben wir am Beispiel von API-Katalogen in großen Organisationen beschrieben.

Registry und API-Katalog gehören zusammen

Die Nähe der beiden Disziplinen ist kein Zufall. MCP-Server exponieren in den meisten Fällen APIs, die bereits dokumentiert und katalogisiert sind, oftmals direkt aus der OpenAPI-Spec erzeugt. Eine Organisation, die einen gepflegten API-Katalog betreibt, besitzt damit schon die halbe Registry. Ownership, Lifecycle-Status und Konsumenten-Beziehungen sind erfasst, es fehlt lediglich die Verbindung zur MCP-Schicht.

Für regulierte Branchen kommt eine zweite Verbindung hinzu. Wenn Agents auf Konto- oder Patientendaten zugreifen, gelten dieselben Anforderungen wie für jede andere Verarbeitung, vom Audit-Trail über die Datenresidenz bis zum Betrieb in der eigenen Infrastruktur. Eine Bank, die ihre API Governance bereits etabliert hat, wird MCP-Zugriffe denselben Regeln unterwerfen und braucht dafür eine Registry, die EU-Hosting und On-Premise-Betrieb beherrscht.

Wie api-portal.io unterstützt

api-portal.io bringt die Registry-Bausteine aus der API-Welt mit und führt sie für MCP zusammen. Der API-Katalog inventarisiert MCP-Server als eigenständige Einträge samt ihrer Tool-Listen. Rollen und Business Groups steuern den Zugriff bis auf die Tool-Ebene, und der Audit-Trail protokolliert Änderungen ebenso wie Zugriffe. Der eingebaute MCP Server exponiert das API-Wissen des Portals zusätzlich selbst als Tools für Claude, GPT und LangChain, abgesichert über OAuth2 und mandantenfähig getrennt.

Das API Portal katalogisiert, sichert und auditiert schon heute den MCP-Zugriff auf Ihr API-Portfolio. Testen Sie den eingebauten MCP Server 14 Tage lang mit Ihren eigenen Specs.