Entwurf eines zentralisierten MCP-Registers: Architekturentscheidungen für den Unternehmenseinsatz

Datenmodell, Authentifizierungs-Metadaten, dynamische Tool-Erkennung und mandantenfähige Isolation für die Schicht zwischen Ihren Agenten und Ihren Tools.

Wenn zwanzig Entwickler jeweils ihre eigene ~/.cursor/mcp.json pflegen, haben Sie keine MCP-Infrastruktur aufgebaut. Sie haben ein verteiltes Notizzettel-System geschaffen, das bei jeder Rotation eines Anmeldeinformationen blockiert.

Dienstag, 02:47 UTC. Continental Aerospace Systems – ein fiktiver, aber leider plausibler Anbieter von Avionik-Plattformen mit 240 Ingenieuren – rotiert planmäßig seinen privaten GitHub App-Schlüssel. Um 09:00 Uhr, #platform-help hat 23 Threads von Squad-Leads, jeder eine Variante von „MCP ist in Cursor kaputt.“ Die Lösung ist jedes Mal identisch – den neuen Token einfügen in ~/.cursor/mcp.json, die IDE neu starten – aber das muss 187 Mal gemacht werden, und das Plattformteam verliert einen halben Tag, bevor es fertig ist.

Dieser Morgen ist kein MCP-Problem. Es ist ein Registry- Problem. Das Protokoll funktioniert; was fehlt, ist die Schicht zwischen dem Agenten und dem Protokoll, die weiß, welche Server existieren, wer welche Tools verwenden kann und wie man jeder IDE in der Organisation von einem rotierten Anmeldeinformationen erzählt, ohne 187 Git-Commits. Dieser Beitrag handelt von dieser Schicht, wobei TrueFoundrys MCP Gateway durchweg als Referenzimplementierung dient.

1. Das Konfigurationsdrift-Problem: Was 20 Entwickler × 8 MCP-Server tatsächlich kosten

Das Problem ist multiplikativ. Continentals 240 Ingenieure, verteilt auf 14 Squads, nutzen Claude Code, Cursor und VS Code mit acht MCP-Servern: GitHub, Sentry, Atlassian, Linear, Slack, einem internen Postgres-basierten fleet-telemetry -Server, einem airworthiness-kb Server, die sich auf ihre FAA-Richtlinien stützen, und Exa für die Suche. Grundsätzlich pflegt jeder Ingenieur eine ~/.cursor/mcp.json wie folgt.

~/.cursor/mcp.json — lokale MCP-Konfiguration, pro Entwickler

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp",
      "headers": { "Authorization": "Bearer ghp_..." }
    },
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp",
      "headers": { "Authorization": "Bearer sntrys_..." }
    },
    "linear":    { "url": "https://mcp.linear.app/mcp" },
    "atlassian": { "url": "https://mcp.atlassian.com/v1/mcp" },
    "slack":     { "url": "https://mcp.slack.com/mcp" },
    "fleet-telemetry": {
      "url": "https://fleet-mcp.internal.example/mcp",
      "headers": { "Authorization": "Bearer eyJ..." }
    },
    "airworthiness-kb": { "url": "https://kb-mcp.internal.example/mcp" },
    "exa": {
      "url": "https://mcp.exa.ai/mcp",
      "headers": { "Authorization": "Bearer exa_..." }
    }
  }
}

Acht Server pro Entwickler, 240 Entwickler, ergeben für das Plattformteam etwa 1.920 implizite Konfigurationseinträge, die korrekt gehalten werden müssen. Die Kosten verteilen sich auf fünf Bereiche.

Die MCP-Gateway-Übersicht stellt die Welt vor dem Registry als vier sich überschneidende Problembereiche dar — fragmentierte Infrastruktur, Wildwuchs an Zugangsdaten, fehlende Sichtbarkeit, keine Governance:

Ein Registry fasst alle fünf Zeilen zu einem architektonischen Grundelement zusammen: ein Ressourceneintrag pro MCP-Server, verwaltet von einer Steuerungsebene, den jede IDE und jeder Agent über eine ID referenziert. Der Rest dieses Beitrags beschreibt, was dieser Eintrag enthält und was das umgebende System leisten muss.

2. MCP-Server-Registry-Datenmodell: Was jeder Eintrag enthält

Vor der Erkennung, Authentifizierung oder Isolation müssen wir genau definieren, was ein Registry-Eintrag ist. Die Struktur, auf die wir uns geeinigt haben:

MCP-Server-Registry-Eintrag — konzeptionelles Modell (TypeScript-Schnittstelle)

// Conceptual model. The on-the-wire schema is exposed through
// the TrueFoundry UI and CLI, not as a public DDL.
interface McpServerRegistryEntry {
  server_id:        string;            // stable, tenant-scoped identifier
  display_name:     string;
  transport_type:   "streamable_http" | "sse" | "stdio";

  // Connectivity (one of, by transport)
  base_url?:        string;            // remote
  command?:         string;            // stdio: e.g. "npx"
  args?:            string[];          // stdio: argv beyond command

  auth_config:      AuthConfig;                // §4
  collaborators:    Collaborator[];            // §5
  tenant_id:        string;            // always present, always filtered on
  cached_tool_schema?:   ToolSchema[];         // last successful tools/list
  cached_schema_at?:     string;
  health_status:    "healthy" | "degraded" | "unhealthy" | "circuit_open";

  created_at:       string;
  updated_at:       string;
}

Konzeptionelles Schema — keine bereitstellbare DDLDie TrueFoundry-Steuerungsebene stellt die Registry-Struktur über die Benutzeroberfläche und die verifizierten YAML-Manifeste für stdio-Server bereit (siehe die stdio-Dokumentation). Die obige Schnittstelle benennt die Verantwortlichkeiten, die ein Registry-Eintrag abdecken muss; das Speicherlayout ist ein Implementierungsdetail.

Vier Felder übernehmen die strukturelle Arbeit. server_id + tenant_id ist der Primärschlüssel, worauf alles filtert. auth_config trennt „wo sich der Server befindet“ von „wie man mit ihm kommuniziert“ – der Schritt, der die Rotation von Anmeldeinformationen kostengünstig macht (§4). collaborators ist der Anknüpfungspunkt für Zugriffsrichtlinien. cached_tool_schema ist das, was die dynamische Erkennung schnell genug macht, um nutzbar zu sein.

So sehen Continentals Registrierungseinträge aus

Continentals acht Server werden zu acht Einträgen. Der interne fleet-telemetry-readonly ist ein streamable_http -Server, der Token Passthrough verwendet – das Okta-JWT des diensthabenden SRE wird vorgelagert weitergeleitet, das die Zielgruppe validiert und zeilenbasierte Sicherheit nach Team-Claim anwendet. Linear ist als ein stdio -Server über mcp-remoteregistriert, mit einem per_user -Authentifizierungsmodell, sodass jeder Ingenieur sein eigenes Linear-Konto autorisiert, pro die stdio-server-Dokumentation. Die vollständigen Manifeste befinden sich in der begleitenden mcp-registry-manifests.yaml.

3. Dynamische Tool-Erkennung: Wie Agenten Tools finden, für die sie nicht vorkonfiguriert waren

Sobald das Register gefüllt ist, besteht die zweite Aufgabe darin, es abfragbar zu machen. Der interessante Fall ist nicht ein Entwickler in Cursor – Cursor hat eine Konfigurationsdatei – sondern ein autonomer Agent, der als Dienst läuft und keine statische Tool-Liste besitzt. Der Agent erwacht mit einem Bearer-Token; das Gateway muss dies umwandeln in „hier sind die Tools, die Sie, speziell Sie, gerade verwenden dürfen“, ohne dass der Agent die Server im Voraus kennt.

Der Ablauf verwendet die Standard- MCP tools/list Methode als Einstiegspunkt, aber das Gateway fängt die Antwort ab und schreibt sie um. Das folgende Diagramm zeigt die Drei-Ebenen-Architektur.

Den Erkennungspfad Schritt für Schritt durchgehen:

1. Der Agent sendet tools/list mit seinem Bearer-Token an das Gateway. Es listet keine Server auf; es weiß nichts über Server.
2. Das Gateway führt aus Eingehende Authentifizierung — das Token validieren, es einem Benutzer, Team oder virtuellen Konto zuordnen. Die Auth-Dokumentation listet vier eingehende Methoden auf: PAT, Virtual Account Token, IdP JWT und TrueFoundry OAuth.
3. Das Gateway fragt das Register nach allen Servern im Tenant des Aufrufers ab, wo die aufgelöste Identität ein Kollaborateur ist. Indizierter Lesezugriff.
4. Für jeden zugänglichen Server gibt das Gateway dessen cached_tool_schema zurück, wenn eines aktuell ist — der Pfad, der im stabilen Zustand läuft — und greift auf ein frisches Upstream- tools/list nur bei Cache-Miss oder nach einer listChanged -Invalidierung (§7) zurück. Ein synchrones Fan-out zu jedem Upstream bei jeder Aufruferanfrage wäre betrieblich unhaltbar.
5. Die aggregierte Liste wird gefiltert nach RBAC auf Tool-Ebene. Der Bereitschaftsagent von Continental ist ein Kollaborateur bei fleet-telemetry-readonly , aber ihm werden Schreib-Tools immer noch verweigert — diese erfordern eine separate Rolle.
6. Das Gateway gibt eine konsolidierte tools/listzurück. Die Verdrahtung des Agenten muss nicht verfolgen, von welchem Upstream-Server jedes Tool stammt — obwohl Tool-Namen, Beschreibungen und Fehlermeldungen in der Praxis immer noch den Ursprung verraten können, weshalb Gateways Tool-Namen oft nach Servern benennen.

Zwei Konsequenzen sind erwähnenswert. Erstens kann ein Agent bei einem Mandanten ohne MCP-spezifische Konfiguration eingesetzt werden – man gibt ihm ein Virtual Account Token, weist ihn auf die Gateway-URL und er entdeckt, was er verwenden darf. Continentals Bereitschafts-Incident-Response-Agent wird als ein Container mit einer Umgebungsvariable ausgeliefert. Zweitens ist die Erweiterung der Tool-Oberfläche des Agenten eine Registry-Änderung, keine erneute Bereitstellung des Agenten: das Hinzufügen von airworthiness-kb zu der Kollaboratoren Liste lässt seine Tools in der nächsten tools/list Antwort erscheinen — gleiches Binary, gleiche Konfiguration.

4. Speicherung von Authentifizierungs-Metadaten: Entkopplung von Anmeldeinformationen von der Konfiguration

Die aufwendigste Operation in der Welt vor der Registry ist die Rotation von Anmeldeinformationen. Die günstigste in der Welt nach der Registry ist dieselbe Rotation. Der Grund ist eine architektonische Entscheidung: Authentifizierungs-Metadaten werden im Registry-Eintrag gespeichert, nicht beim Client.

Die Auth-Dokumentation fasst dies als Trennung zwischen eingehender Authentifizierung (wie der Client dem Gateway seine Identität nachweist) und ausgehender Authentifizierung (wie das Gateway jedem nachgeschalteten Server seine Identität nachweist). Die auth_config jedes Eintrags steuert die ausgehende Seite:

Zwei Eigenschaften von auth_config sind betrieblich relevant: Sie referenziert Anmeldeinformationen, speichert sie nicht; und sie gehört dem Plattformteam, nicht dem Anwendungsteam.

Die erste Eigenschaft ist das, wofür TrueFoundrys Secret-Manager-Integration dazu dient, Ordnung zu schaffen. Anmeldeinformationen in einem Registrierungseintrag werden als Referenzen gespeichert, indem tfy-secret://<tenant>:<secret-group>:<secret-key>. Das eigentliche Material befindet sich im Secret Store des Mandanten – TrueFoundry-nativ, AWS SSM, GCP Secret Manager, HashiCorp Vault oder Azure Key Vault – und das Gateway löst die Referenz zur Laufzeit auf. Für selbst gehostete Control Planes ist das Äquivalent tfy-k8s-secret://<KEY_NAME>, gestützt durch ein Kubernetes-Secret.

Wie Continentals Rotation nach der Registrierung verlief

Gleiche Rotation um 02:47 UTC. Vault legt den neuen Schlüssel unter tfy-secret://continental-aerospace:github-app:GITHUB_APP_PRIVATE_KEY. Die nächste GitHub-Tool-Aufrufung dereferenziert das Secret, erhält den neuen Wert und leitet die Anfrage weiter. Keine Änderungen an der Entwicklerkonfiguration. Keine Tickets. Das Plattformteam erfährt am nächsten Morgen über ein Dashboard von der Rotation.

5. Multi-Tenant-Isolation: Namespace-Architektur für Unternehmens-Registries

Eine Registrierung, die Server für einen Mandanten enthält, ist unkompliziert. Eine Registrierung, die Server für Hunderte – oder, auf einer selbst gehosteten Control Plane, für mehrere Geschäftseinheiten innerhalb desselben Unternehmens – enthält, muss eine stärkere Garantie bieten: Die Server von Org A müssen unsichtbar für Org B sein, nicht nur unerreichbar. „Unerreichbar“ ist ein 403, den der falsche Agent sehen könnte. „Unsichtbar“ ist ein Werkzeuge/Liste Antwort, die nicht darauf hindeutet, dass ein anderer Mandant existiert.

Mandant in der URL. Die v0.130 URL-Änderung verschob die Gateway-URL von /api/llm/mcp/<server>/server nach /api/llm/<tenant>/mcp/<server>/server. Der Mandant ist nun Teil des adressierbaren Pfades – was die MCP-OAuth-Verkettung ermöglicht und was es einem physischen Gateway erlaubt, viele Mandanten ohne Umgebungszustand zu bedienen.

Mandant in jeder Abfrage. Innerhalb der Registrierung wird jeder Lesevorgang parametrisiert durch tenant_id. Es gibt keinen Pfad "alle Server auflisten"; nur "alle Server auflisten in diesem Mandanten." Das Festcodieren des Filters auf der Datenzugriffsebene eliminiert nicht das mandantenübergreifende Leck als Fehlerklasse – Caching, asynchrone Kontextweitergabe, Hintergrund-Worker, Suchindizes und Telemetrie-Joins können alle immer noch undicht sein – aber es beseitigt den größten und wahrscheinlichsten Vektor, nämlich den, bei dem eine fehlende WHERE Klausel in einer RBAC-Prüfung die Zeilen des falschen Mandanten zurückgibt.

Mandant in der Identität. Kollaboratoren werden über das Identitätsmodell der Steuerungsebene aufgelöst. Benutzer gehören zu Mandanten; Teams sind auf Mandanten beschränkt; virtuelle Konten werden innerhalb von Mandanten erstellt. Die erste Prüfung der RBAC-Engine ist, dass der Mandant des Aufrufers mit dem Mandanten der Ressource übereinstimmt.

Konzeptueller Abfragepfad – Mandantenfilter ist zwingend erforderlich

// Tenant filter applied before the access-policy check.
// This shrinks the blast radius of an RBAC bug — the wrong tenant's
// rows aren't loaded — but caching, async context, and indexers
// still need their own tenant-scoping discipline.
function listAccessibleServers(caller: Identity): McpServerRegistryEntry[] {
  const rows = registry.query({
    tenant_id: caller.tenant_id,
    health_status: { $ne: "circuit_open" },
  });
  return rows.filter(server => rbac.canRead(caller, server));
}

Bereichsübergreifende Dienste bei Continental

Die Avionik- und Bodensystem-Abteilungen von Continental laufen als separate Mandanten auf derselben Steuerungsebene. In den meisten Fällen ist das genau richtig – der Flotten-Telemetrie-Server ist für Bodensystem-Ingenieure nicht relevant und rechtlich nicht angemessen einzusehen. Ein Server jedoch, ein MCP für Unternehmensdokumentation, sollte für beide sichtbar sein. Das Muster ist eine explizite mandantenübergreifende Freigabe für Kollaboratoren: der Eintrag tenant_id bleibt beim besitzenden Mandanten, aber die Kollaboratoren Liste enthält einen Prinzipal des anderen. Die gemeinsame Sichtbarkeit ist eine bewusste, geprüfte Freigabe – niemals ein Zufall.

6. Öffentliche vs. selbst gehostete Registrierungsabläufe

Die Registrierung eines öffentlichen MCP-Servers und die Registrierung eines selbst gehosteten Servers sind dieselbe konzeptionelle Operation – einen Registrierungseintrag erstellen – aber die Workflows sehen unterschiedlich aus, und das Register muss beide unterstützen.

Für öffentliche Server (GitHub, Linear, Sentry, Atlassian, Slack, Exa, Playwright MCP, DeepWiki, Context7) reduziert sich der Vorgang auf wenige Klicks. Der „MCP-Server hinzufügen“-Flow des MCP Gateways bietet fünf Registrierungspfade: Offizielle Remote-MCP-Server verbinden, Beliebigen Remote-MCP-Server verbinden, Virtuellen MCP-Server erstellen, Aus OpenAPI-Spezifikation importieren, und Gehosteter Stdio-basierter MCP-Server. Der erste wählt aus einem kuratierten Katalog mit vorausgefüllten Authentifizierungsmetadaten; Sie geben die OAuth-Client-ID/das Geheimnis an, und der Rest des Eintrags wird generiert.

Selbst gehostete Server – beispielsweise die internen von Continental fleet-telemetry-readonlynutzen Beliebigen Remote MCP-Server verbinden (für HTTPS-Endpunkte) oder Gehosteter Stdio-basierter MCP-Server (für CLI-basierte Server). Der Stdio-Pfad ist interessant, da das Gateway für die Ausführung des Prozesses verantwortlich wird und nicht nur für dessen Aufruf. Die Stdio-Dokumentation definieren die Form des verifizierten YAML-Manifests: command, args, und ein auth_data -Block mit entweder auth_level: per_user (wobei das Geheimnis jedes Aufrufers in {{API_KEY}}) oder auth_level: global (ein mandantenübergreifender gemeinsamer Wert). Die zugehörige Datei mcp-registry-manifests.yaml enthält vier Praxisbeispiele, die beide Authentifizierungsstufen und das Virtual MCP Server-Muster abdecken.

Unabhängig vom Pfad validiert die Registrierung, dass ein neu registrierter Server erreichbar ist, bevor sie ihn veröffentlicht. Für entfernte HTTPS-Server ist das eine Überprüfung tools/list. Für stdio startet das Gateway einen kurzlebigen Prozess, sendet initialize, und stellt sicher, dass der Server korrekt antwortet. Ein Server, der nicht überprüft werden kann, wird bei der Registrierung abgelehnt – er wird nicht in einem fehlerhaften Zustand hinzugefügt, der sich als 503er-Fehler äußert, sobald Entwickler versuchen, ihn zu nutzen.

7. Tool-Schema-Versionierung und Cache-Invalidierung

Das Caching des Tool-Schemas macht den Unterschied zwischen einer nutzbaren und einer unbrauchbaren Registrierung aus. Eine naive Implementierung, die tools/list bei jeder Agenten-Anfrage gegen jeden Upstream-Server aufruft, multipliziert die Latenz des Gateways mit der Anzahl der Upstreams und fügt pro Server einen Fehlerfall hinzu. Der Cache löst das Latenzproblem und schafft ein neues: Schema-Drift.

Das Gateway verwaltet ein cached_tool_schema pro Eintrag, das auf zwei Arten aktualisiert wird.

Ereignisgesteuerte Aktualisierung. Die MCP-Spezifikation definiert eine listChanged Benachrichtigung , die Server deklarieren { "tools": { "listChanged": true } } können senden, wenn sich ihre Tool-Liste ändert. Für Server, die sowohl die Fähigkeit deklarieren als auch zuverlässig über ihre persistente Verbindung senden, behandelt das Gateway die Benachrichtigung als Invalidierungssignal und ruft neue Daten ab, bevor der nächste Aufrufer veraltete Daten sieht. Dies ist der schnelle Pfad, wenn er verfügbar ist – aber er ist nicht universell: Viele MCP-Server implementieren listChanged überhaupt nicht, und einige deklarieren die Fähigkeit, senden aber inkonsistent über verschiedene Transportwege hinweg.

Regelmäßige Aktualisierung. Für alles andere prüft das Gateway in einem einstellbaren Intervall erneut (niedrige einstellige Minuten für aktive Server, länger für bekanntermaßen inaktive). Die Prüfung verwendet den bestehenden Verbindungspool wieder. In der Praxis verlassen sich die meisten Produktionsumgebungen auf die regelmäßige Aktualisierung als primären Mechanismus und behandeln listChanged als opportunistisch, wenn es funktioniert.

8. Zustandsprüfung und Schutzschaltung für MCP-Server

Die Registrierung muss wissen, was aktiv ist. Andernfalls tut sie das Schlimmste: Sie bewirbt ein Tool, dessen Server seit einer Stunde 503-Fehler ausgibt, und jeder Agent im Tenant läuft in einen Timeout, wenn er versucht, es aufzurufen.

Das Health-Subsystem führt drei Schleifen aus.

Prüfung. Ein Hintergrundprozess ruft tools/list für jeden Server in einem einstellbaren Intervall auf. Erfolg stuft den Server als fehlerfrei ein und aktualisiert das zwischengespeicherte Schema; ein Fehler (Netzwerkfehler, 5xx, fehlerhafte Nutzlast) erhöht einen Zähler.

Schwellenwert. Sobald der Zähler einen Schwellenwert überschreitet – der pro Serverklasse angepasst wird, da öffentliches SaaS mehr Spielraum erhält als internes – wechselt der Server in den Zustand fehlerhaft und seine Tools werden markiert. Nach einem zweiten Schwellenwert öffnet der Schutzschalter (circuit_open). Die meisten Implementierungen unterdrücken einen Server mit offenem Stromkreis vollständig aus tools/list -Antworten, sodass Agenten eine kleinere Tool-Liste sehen, anstatt eine mit fehlerhaften Einträgen; einige lassen die Tools sichtbar, markieren sie aber, unter der Annahme, dass Agentenplaner sich besser an „nicht verfügbar“ als an „fehlend“ anpassen können. Die richtige Entscheidung hängt davon ab, wie Ihre Agenten mit Abwesenheit umgehen.

Wiederherstellung. Der Schutzschalter ist nach einer Abkühlphase halboffen: ein Test; bei Erfolg geschlossen; bei Misserfolg verdoppelt sich die Abkühlphase. Standardmäßige exponentielle Rückzugsstrategie.

Der Grund, warum dies wichtig ist, ist nicht die Latenz – es ist die Zuverlässigkeitskomposition. Ohne Circuit Breaking fällt ein Agent, der von sieben Upstream-Servern abhängt, aus, wenn einer von ihnen ausfällt. Damit verliert der Agent die Tools eines Servers und arbeitet mit den anderen sechs weiter. Für Continentals Bereitschafts-Agenten zur Vorfallreaktion ist das der Unterschied zwischen „wir triagieren weiter, während Sentry ausgefallen ist“ und „der KI-Assistent ist selbst ausgefallen, weil Sentry ausgefallen ist“.

Verteilte Konfiguration vs. zentrale Registrierung

Die Unterschiede lassen sich in sechs Dimensionen einteilen.

Continental, vorher und nachher

9. Häufig gestellte Fragen

Muss die Registrierung in derselben Steuerungsebene wie der Rest unserer KI-Infrastruktur liegen?

Das muss es nicht , aber die gemeinsame Platzierung mit dem Modell-Gateway zahlt sich mehrfach aus – dieselbe RBAC-Engine, Secret-Manager-Integration, Audit-Pipeline und dasselbe Identitätsmodell dienen sowohl dem Modell- als auch dem Tool-Traffic. Das TrueFoundry MCP Gateway ist aus diesem Grund absichtlich Teil derselben Steuerungsebene wie das AI Gateway.

Was passiert, wenn die lokale IDE-Konfiguration eines Entwicklers mit der Registrierung in Konflikt gerät?

Das tut sie nicht, weil die IDE-Konfiguration keine Anmeldeinformationen mehr enthält – nur noch eine Gateway-URL. Nach v0.130, reduziert sich die Cursor- oder VS Code-Konfiguration für einen MCP-Server auf eine mandantenbezogene Gateway-URL plus jeglichen OAuth- oder IdP-Bootstrap, den Ihre Organisation bereits benötigt – das Gateway übernimmt die Auflösung der Anmeldeinformationen auf der anderen Seite. Es gibt kein serverseitiges Geheimnis in der IDE-Konfiguration, das von der Registrierung abweichen könnte.

Wie geht die Registry mit Servern um, die eine benutzerdefinierte oder nicht-standardmäßige Authentifizierung verwenden?

Durch Token-Weiterleitung. Der Client setzt x-tfy-mcp-headers mit der Authentifizierung, die der Upstream benötigt, und das Gateway leitet sie weiter. Dies ist die Notlösung für Server, deren Schemata keinem integrierten Modell entsprechen – häufig bei älteren internen Diensten.

Können wir nur eine Teilmenge von Tools eines registrierten Servers bereitstellen?

Ja, über einen virtuellen MCP-Server. Das Virtual-Server-Feature stellt ein kuratiertes Bündel von Tools zusammen, das von einem oder mehreren registrierten Servern stammt, und gewährt unabhängig Zugriff auf dieses Bündel. Das Incident-Response-Toolkit von Continental ist ein virtueller Server, der dem Bereitschaftsteam schreibgeschützte Sentry-Tools sowie schreibgeschützte Flotten-Telemetrie-Tools bereitstellt – keine der destruktiven Operationen sind erreichbar.

Was passiert, wenn ein Upstream-MCP-Server seinen Transport von streamable HTTP zu SSE ändert?

Das Gateway folgt dem Server. Ab v0.130, behält es den Transport des Upstreams bei, anstatt auf streamable HTTP zu normalisieren. Clients, die dem Muster der Spezifikation 'streamable HTTP zuerst, dann SSE-Fallback' folgen, funktionieren weiterhin ohne Konfigurationsänderungen.

Wie interagiert die Registry mit autonomen Agenten, die Tools zur Laufzeit entdecken müssen?

Darum geht es in §3. Ein Agent authentifiziert sich einmal beim Gateway, ruft tools/list, und erhält eine kuratierte, RBAC-gefilterte Tool-Liste. Anschließend kann er tools/call mit jedem Element aus dieser Liste aufrufen. Kein vorgefertigtes Inventar, keine erneuten Bereitstellungen.

Was ist der einfachste Weg, um zu beginnen?

Registrieren Sie einen Server, den Sie bereits nutzen – Linear, GitHub oder Sentry sind übliche erste Wahl, da die Authentifizierungsabläufe gut etabliert sind – und richten Sie die IDE-Konfiguration eines Teams auf die Gateway-URL aus. Versuchen Sie nicht, 240 Entwickler und 8 Server auf einmal zu migrieren; migrieren Sie einen Server und 10 Entwickler, lernen Sie aus der Einführung und erweitern Sie dann.

Nächster Schritt

Wenn ~/.cursor/mcp.json Drift Ihr Plattformteam Zeit zu kosten beginnt, ist das das Signal zur Zentralisierung. Das TrueFoundry MCP Gateway ist die Registry- und Policy-Schicht, die wir für diesen Übergang entwickelt haben; Sie können die Architektur-Dokumentation lesen oder kostenlos testen.

Weiterführende Lektüre

• TrueFoundry MCP Gateway – Übersicht · zentralisierte Registry, Vorher-Nachher-Darstellung
• MCP Gateway – Authentifizierung und Sicherheit · eingehende vs. ausgehende Authentifizierung, alle sieben ausgehenden Modelle
• MCP Gateway – Erste Schritte · die fünf Registrierungspfade und das Kollaborator-/Rollenmodell
• Gehosteter stdio-basierter MCP-Server · verifizierte YAML-Manifest-Struktur, umgebungsbasierte Authentifizierung
• Virtueller MCP-Server · kuratierte Tool-Bundles ohne Redeployment
• Secret Manager in Integrationen verwenden · der tfy-secret:// Referenzformat
• v0.130 URL- und Transportänderungen · Tenant in URL, OAuth-Verkettung, SSE-Fallback
• MCP-Spezifikation — Tools · tools/list, tools/call, listChanged Benachrichtigung
• Claude Enterprise-Sicherheit — MCP Gateway mit Allowlisting · Muster für einen gesteuerten Enterprise-Rollout

‍

‍