Zum Hauptinhalt
Intelliger
MCP-Registerarchitektur

MCP Gateway Registry vs. MCP Server Registry

Trennen Sie eine MCP-Serverregistrierung für die Erkennung und Herkunft von den Gateway-Richtlinien, Anmeldeinformationen und Laufzeitdatensätzen, die jeden Toolaufruf erzwingen.

Separate MCP Discovery Registry und Gateway Enforcement Records, verbunden durch stabile Identifikatoren
Intelliger•
8 Minuten Lesezeit · MCP und Security Expert Review vor Veröffentlichung erforderlich

Ein MCP-Server-Register beantwortet, welche Server existieren, wem sie gehören, wo sie laufen und welche Funktionen sie bewerben. Ein MCP-Gateway-Register beantwortet, was ein Mandant genehmigt hat, wie der Datenverkehr erreicht wird, welche Identitäts- und Anmelderegeln gelten und welche Richtlinien Laufzeitaufrufe regeln. Ein Katalog kann beide Ansichten speichern, aber die Datensätze sollten unterschiedlich bleiben.

Die MCP Gateway Guide Dieser Artikel verhindert, dass eine Entdeckungsaufzeichnung mit einer Erlaubnis verwechselt wird.

Modellieren Sie die beiden Datensätze

type ServerCatalogRecord = {
  serverId: string;
  name: string;
  publisher: string;
  endpoint: string;
  transport: string;
  advertisedToolsDigest: string;
  provenance: string[];
  observedAt: string;
};

type GatewayAdmissionRecord = {
  tenantId: string;
  serverId: string;
  approvedEndpoint: string;
  ownerId: string;
  status: 'approved' | 'quarantined' | 'revoked';
  allowedTools: string[];
  credentialProfile: string;
  policyDigest: string;
  metadataDigest: string;
  reviewedAt: string;
};

Der Katalog kann öffentliche, private und nicht überprüfte Server enthalten. Nur eine genehmigte Zulassungsaufzeichnung sollte das Gateway-Routing beeinflussen. Namen sind Anzeigeetiketten, keine Identitäten. Verwenden Sie stabile IDs und binden Sie genehmigte Endpunkte und Metadaten-Digests.

Detektionsdrift

Werkzeugbeschreibungen und Schemata können sich nach der Sicherheitsüberprüfung ändern. Vergleichen Sie den aktuellen Metadaten-Digest mit dem Zulassungsprotokoll. Eine wesentliche Änderung sollte das Werkzeug unter Quarantäne stellen oder eine neue Überprüfung gemäß den Richtlinien auslösen.

DriftAusfallreaktion
Beschreibung nur WortlautAufzeichnen und Anwenden der konfigurierten Überprüfungsregel
Eingabeschema fügt optionales Feld hinzuNeubewertung von Richtlinie und Validierung
Tool-Änderungen Read to Write VerhaltenQuarantäne
Endpunkt-HoständerungenQuarantäne und Überprüfung des Eigentums
Änderungen des Autorisierungsserversbis zur Vertrauensüberprüfung ablehnen
Serversignierung oder Paketherkunft fehlschlägtAufhebung oder Quarantäne

Die Toolliste des Servers bleibt untrusted input. tools/call Ein nicht genehmigtes Tool vor der Entdeckung zu verstecken, ist nützlich, aber der Call-Pfad muss es auch leugnen.

Mietereintritt getrennt halten

Zwei Unternehmen können denselben Server mit unterschiedlichen Tools, Anmeldeinformationen und Richtlinien genehmigen. Niemals einen globalen Anmeldenachweis an einen öffentlichen Katalogeintrag anhängen. Partitionseinweisungsaufzeichnungen, geheime Referenzen, Richtlinien und Beweise nach Mieter. Testen Sie identische Server- und Tool-IDs zwischen Mietern, um Cache-Schlüsselauslassungen zu erfassen.

Die MCP Architekturdokumentation Das Protokoll definiert die Interaktion und nicht den Workflow für die Unternehmensgenehmigung.

Durchsetzung beweisen

Eine Registerüberprüfung sollte diese Einrichtung enthalten:

given: approved metadata digest A
when:
  server advertises digest B
  client calls newly added tool transfer_funds
then:
  discovery_result: hidden_or_quarantined
  runtime_result: denied
  upstream_calls: 0
  alert: metadata_drift

Neue Tool-Aufrufe sollten aufhören, ohne darauf zu warten, dass der Client seine Liste aktualisiert.

Siehe MCP Gateway Architektur und Open-Source-Gateway-BewertungsverfahrenIntelliger lebt Übersicht über die Plattform ist der zugehörige Produktpfad für die geregelte Serverzulassung und die Durchsetzung von Anforderungen.

Dieses Design bedeutet nicht, dass Intelliger einen universellen MCP-Serverkatalog betreibt. Öffentliche Materialien beschreiben Gateway- und OATI-Entwickler-Vorschau-Fähigkeiten; Produktionsregistrierungsoperationen bleiben Bereitstellungsspezifisch.

Fragen zur Gestaltung des Registers

Wer darf einen Server veröffentlichen und wer darf einen Server zulassen?

Das Veröffentlichen macht einen Server in einem Katalog auffindbar. Der Eintritt macht ihn in einem Mandanten nutzbar. Diese Berechtigungen getrennt halten. Ein Anbieter oder Entwickler kann Metadaten veröffentlichen, während ein Mandanten-Sicherheits- oder Plattformbesitzer Endpunkt, Tools, Aussteller und Anmeldeprofil genehmigt. Beide Akteure aufzeichnen und eine neue Zulassungsentscheidung erfordern, wenn sich der Besitz oder ein geschützter Endpunkt ändert.

Wie wird der Publisher Ownership verifiziert?

Verwenden Sie eine Provenienzmethode, die für den Katalog geeignet ist, wie verifizierte Domains, Repository-Besitz, Paketsignierung oder einen Enterprise-Onboarding-Prozess. Kein einzelnes Signal beweist, dass der Code sicher ist. Kombinieren Sie die Publisher-Identität mit Artefaktüberprüfung, Endpunktüberprüfung und aktuellem Sicherheitsstatus. Behalten Sie, was überprüft wurde, damit ein späterer Vorfall nicht auf einem Display-Badge beruht.

Sollte die Registry Live-Tool-Listen abrufen?

Es kann sie zum Vergleich sammeln, aber ein nicht vertrauenswürdiger Endpunkt kann mandantenspezifische Inhalte ändern oder zurückgeben. Netzwerkzugriff, Antwortgröße und Parsing. Beobachtungszeit und -verdau speichern. Das Gateway sollte eine zugelassene Snapshot- und Drift-Richtlinie verwenden, anstatt blind von der neuesten abgerufenen Beschreibung zu schalten.

Was passiert, wenn ein Server widerrufen wird?

Beenden Sie neue Erkennungs- und Laufzeitaufrufe, deaktivieren oder drehen Sie die Anmeldeinformationen, beenden oder verfallen relevante Sitzungen und identifizieren Sie Arbeiten während des Fluges. Bewahren Sie die historische Zulassung und Beweise für die Untersuchung auf. Eine Änderung des Katalogetiketts, die keine Gateway-Repliken oder Upstream-Service-Identität erreicht, ist kein wirksamer Widerruf.

Wie sollten private Server vertreten sein?

Endpunkt- und Tool-Metadaten innerhalb der Mandanten- oder genehmigten Organisationsgrenze aufbewahren. Ein gemeinsam genutzter Registrierungsdienst sollte Suchen, Cache und Beweise partitionieren. Interne Servernamen und -fähigkeiten durch Autovervollständigung oder Fehlermeldungen vermeiden.

Wie können Teams die Konsistenz von Katalog zu Gateway testen?

Wählen Sie zugelassene Datensätze aus und vergleichen Sie Besitzer, Endpunkt, Metadaten-Digest, Tool-Richtlinie und Status mit aktiver Gateway-Konfiguration. Wählen Sie dann Gateway-Datenverkehr und lösen Sie dessen Zulassungsdatensatz. Automatisieren Sie Warnmeldungen für unbekannte Datensätze, veraltete Snapshots und Anrufe nach Widerruf. Führen Sie die Überprüfung über Regionen hinweg aus, da eine veraltete Replik einen Bypass erhalten kann.

Behandeln Sie das Löschen als Lebenszyklusereignis, nicht als fehlende Zeile. Beenden Sie vor dem Entfernen eines Servers die Zulassung, blockieren Sie neue Anrufe, identifizieren Sie Sitzungen und in die Warteschlange gestellte Arbeiten, widerrufen Sie Anmeldeinformationen und bewahren Sie die historischen Metadaten, die für die Interpretation früherer Beweise erforderlich sind. Wenn ein Server ersetzt wird, geben Sie eine neue stabile Kennung aus, es sei denn, der Vertrauens-, Endpunkt- und Eigentümervertrag bleiben wirklich gleich.

Registrierungssuche erfordert auch Missbrauchstests. Ein Benutzer von Mandant A sollte nicht die privaten Servernamen, Werkzeugbeschreibungen oder Besitzer von Mandanten B durch Autovervollständigung, Ergebniszählung oder Fehler-Timing ableiten. Testen Sie allgemeine Präfixe und identische Anzeigenamen. Öffentliche Kataloge und private Unternehmenszulassung können Software teilen, aber sie sollten keinen uneingeschränkten Suchindex oder Cache-Schlüssel teilen.

Während des Widerrufs können Betreiber einen unbenutzten Katalogeintrag von einem Server unterscheiden, dessen Entfernung aktive Arbeit stranden wird. Abhängigkeitsdaten sollten die Kommunikation leiten und nicht den Laufzeitblock schwächen.

Die Eigentümer sollten erreichbar sein, Alternativen sollten benannt werden und der Gateway-Block sollte auch dann wirksam bleiben, wenn Ersatzarbeiten länger dauern als erwartet.