Een gecentraliseerd MCP Registry ontwerpen: Architectuurbeslissingen voor enterprise-schaal

Datamodel, auth-metadata, dynamische tool-discovery en multi-tenant-isolatie voor de laag tussen je agents en je tools.

Wanneer twintig ontwikkelaars elk hun eigen ~/.cursor/mcp.json onderhouden, heb je geen MCP-infrastructuur gebouwd. Je hebt een gedistribueerd geeltjessysteem gebouwd dat elke keer vastloopt wanneer een credential roteert.

02:47 UTC, dinsdag. Continental Aerospace Systems — een fictieve maar helaas zeer plausibele leverancier van avionica-platformen met 240 engineers — roteert volgens planning de privé-sleutel van zijn GitHub App. Om 09:00 uur heeft #platform-help 23 threads van squad-leads, elk een variant van "MCP werkt niet in Cursor." De oplossing is telkens identiek — plak het nieuwe token in ~/.cursor/mcp.json, herstart de IDE — maar het moet 187 keer worden gedaan, en het platformteam verliest een halve dag voordat ze klaar zijn.

Die ochtend is geen MCP-probleem. Het is een registry-probleem. Het protocol werkt; wat ontbreekt is de laag tussen de agent en het protocol die weet welke servers bestaan, wie welke tools mag gebruiken en hoe elke IDE in de organisatie op de hoogte wordt gesteld van een geprocureerd credential zonder 187 git-commits. Dit artikel gaat over die laag, waarbij TrueFoundry's MCP Gateway door de hele tekst als referentie-implementatie dient.

1. Het probleem van configuratiedrift: Wat 20 ontwikkelaars × 8 MCP-servers werkelijk kosten

De vorm van het probleem is een vermenigvuldiging. Continental's 240 engineers verdeeld over 14 squads draaien Claude Code, Cursor en VS Code tegen acht MCP-servers: GitHub, Sentry, Atlassian, Linear, Slack, een interne Postgres-gebackte fleet-telemetry-server, een airworthiness-kb-server gebackt door hun FAA-richtlijnen, en Exa voor zoekopdrachten. Standaard onderhoudt elke engineer een ~/.cursor/mcp.json zoals dit.

~/.cursor/mcp.json — lokale MCP-configuratie, per ontwikkelaar

Acht servers per ontwikkelaar, 240 ontwikkelaars, geeft het platformteam ongeveer 1.920 impliciete configuratie-items om correct te houden. De kosten komen op vijf plaatsen terecht.

Het MCP Gateway overzicht schetst de wereld van vóór het registry als vier overlappende pathologieën — gefragmenteerde infrastructuur, credential-wildgroei, nul zichtbaarheid, geen governance:

Een registry brengt al deze vijf rijen terug tot één architectonische primitieve: één resourcerecord per MCP-server, eigendom van een control plane, waarnaar elke IDE en elke agent verwijst via ID. De rest van dit artikel gaat over wat dat record bevat en wat het systeem eromheen moet doen.

2. MCP Server Registry-datamodel: Wat elke vermelding bevat

Voordat we kijken naar discovery, auth of isolatie, moeten we precies definiëren wat een registry-vermelding is. De vorm waar we op uitkwamen:

MCP server registry-vermelding — conceptueel model (TypeScript-interface)

Conceptueel schema — geen uitrolbare DDLHet TrueFoundry control plane stelt de registry-vorm beschikbaar via de UI en de geverifieerde YAML-manifesten voor stdio-servers (zie de stdio-documentatie). De bovenstaande interface noemt de verantwoordelijkheden die een registry-vermelding moet dekken; de opslagindeling is een implementatiedetail.

Vier velden voeren het structurele werk uit. server_id + tenant_id is de primaire sleutel waarop alles filtert. auth_config scheidt "waar de server is" van "hoe ermee te communiceren" — de stap die credential-rotatie goedkoop maakt (§4). collaborators is het aankoppelpunt voor het toegangsbeleid. cached_tool_schema maakt dynamische discovery snel genoeg om bruikbaar te zijn.

Hoe Continental's registry-vermeldingen eruitzien

Continental's acht servers worden acht vermeldingen. De interne fleet-telemetry-readonly is een streamable_http-server die Token Passthrough gebruikt — het Okta JWT van de dienstdoende SRE wordt stroomopwaarts doorgestuurd, wat de doelgroep valideert en beveiliging op rijniveau toepast per team-claim. Linear is geregistreerd als een stdio-server via mcp-remote, met een per_user-authmodel zodat elke engineer zijn eigen Linear-account autoriseert, volgens de stdio-server documentatie. De volledige manifesten staan in de bijbehorende mcp-registry-manifests.yaml.

3. Dynamische Tool-discovery: Hoe agents tools vinden waarvoor ze niet vooraf zijn geconfigureerd

Zodra de registry is gevuld, is de tweede taak deze bevraagbaar te maken. Het interessante geval is niet een ontwikkelaar in Cursor — Cursor heeft een configuratiebestand — maar een autonome agent die als een service draait, zonder statische toollijst. De agent wordt wakker met een bearer token; de gateway moet dat omzetten in "dit zijn de tools die jij, specifiek, op dit moment mag gebruiken," zonder dat de agent vooraf een van de servers kent.

De stroom gebruikt de standaard MCP tools/list methode als ingang, maar de gateway onderschept en herschrijft de respons. Het onderstaande diagram toont de architectuur met drie vlakken.

Stap voor stap het discovery-pad doorlopen:

1. De agent stuurt tools/list naar de gateway met zijn bearer token. Het somt geen servers op; het weet niets van servers.
2. De gateway voert inkomende authenticatie uit — valideer het token, herleid het naar een gebruiker, team of virtueel account. De auth-documentatie vermeldt vier inkomende methoden: PAT, Virtual Account Token, IdP JWT en TrueFoundry OAuth.
3. De gateway bevraagt de registry voor alle servers in de tenant van de aanroeper waar de herleide identiteit een medewerker is. Geïndexeerde leesactie.
4. Voor elke toegankelijke server retourneert de gateway de cached_tool_schema wanneer deze actueel is — het pad dat in stabiele toestand draait — en valt alleen terug op een verse stroomopwaartse tools/list bij een cache-miss of na een listChanged-invalidatie (§7). Synchrone uitwaaiering naar elke stroomopwaartse server bij elk verzoek van een aanroeper zou operationeel onhoudbaar zijn.
5. De samengevoegde lijst wordt gefilterd tegen RBAC op tool-niveau. Continental's piket-agent is een medewerker op fleet-telemetry-readonly maar heeft nog steeds geen toegang tot schrijf-tools — die vereisen een afzonderlijke rol.
6. De gateway retourneert één geconsolideerde tools/list. De configuratie van de agent hoeft niet bij te houden van welke stroomopwaartse server elke tool afkomstig is — hoewel toolnamen, beschrijvingen en foutmeldingen in de praktijk nog steeds de herkomst kunnen verraden, wat de reden is dat gateways toolnamen vaak voorzien van een namespace per server.

Twee consequenties zijn het noemen waard. Ten eerste kan een agent worden uitgerold tegen een tenant met nul MCP-specifieke configuratie — geef het een Virtual Account Token, richt het op de gateway-URL, en het ontdekt wat het mag gebruiken. Continental's incident-response agent voor piketdiensten wordt geleverd als één container met één omgevingsvariabele. Ten tweede is het uitbreiden van het tool-oppervlak van de agent een registry-wijziging, geen hernieuwde uitrol van de agent: het toevoegen van airworthiness-kb aan de collaborators-lijst zorgt ervoor dat de tools verschijnen in de volgende tools/list-respons — hetzelfde binaire bestand, dezelfde configuratie.

4. Opslag van Auth-metadata: Credentials loskoppelen van configuratie

De duurste enkele handeling in de wereld van vóór de registry is credential-rotatie. Dezelfde rotatie is de goedkoopste in de wereld na de registry. De reden is een enkele architectonische keuze: auth-metadata wordt opgeslagen in de registry-vermelding, niet op de client.

De auth-documentatie kader dit als een scheiding tussen inkomende authenticatie (hoe de client zijn identiteit bewijst aan de gateway) en uitgaande authenticatie (hoe de gateway zijn identiteit bewijst aan elke stroomafwaartse server). De auth_config van elke vermelding sturt de uitgaande zijde aan:

Twee eigenschappen van auth_config zijn operationeel van belang: het verwijst naar credentials, het slaat ze niet op; en het is eigendom van het platformteam, niet van het applicatieteam.

De eerste eigenschap is waarvoor TrueFoundry's secret-manager integratie bestaat om het overzichtelijk te houden. Credentials in een registry-vermelding worden opgeslagen als referenties met tfy-secret://<tenant>:<secret-group>:<secret-key>. Het daadwerkelijke materiaal bevindt zich in de secret store van de tenant — TrueFoundry-native, AWS SSM, GCP Secret Manager, HashiCorp Vault of Azure Key Vault — en de gateway herleidt de referentie tijdens runtime. Voor self-hosted control planes is het equivalent tfy-k8s-secret://<KEY_NAME>, ondersteund door een Kubernetes secret.

Hoe Continental's rotatie verliep na de registry

Zelfde rotatie om 02:47 UTC. Vault plaatst de nieuwe sleutel op tfy-secret://continental-aerospace:github-app:GITHUB_APP_PRIVATE_KEY. De volgende aanroep van de GitHub-tool derefereert het geheim, haalt de nieuwe waarde op en stuurt het verzoek door. Nul configuratiewijzigingen voor ontwikkelaars. Nul tickets. Het platformteam leert de volgende ochtend via een dashboard over de rotatie.

5. Multi-Tenant-isolatie: Namespace-architectuur voor Enterprise Registries

Een registry die servers voor één tenant bevat, is eenvoudig. Een registry die servers bevat voor honderden — of, op een self-hosted control plane, voor meerdere bedrijfsonderdelen binnen dezelfde onderneming — moet een sterkere garantie bieden: de servers van Org A moeten onzichtbaar zijn voor Org B, niet louter onbereikbaar. "Onbereikbaar" is een 403 die de verkeerde agent zou kunnen zien. "Onzichtbaar" is een tools/list-respons die op geen enkele manier verraadt dat er een andere tenant bestaat.

Tenant in de URL. De v0.130 URL-wijziging verplaatste de gateway-URL van /api/llm/mcp/<server>/server naar /api/llm/<tenant>/mcp/<server>/server. De tenant is nu onderdeel van het adresseerbare pad — wat het ketenen van MCP OAuth laat werken, en wat één fysieke gateway in staat stelt vele tenants te bedienen zonder omgevingsstatus.

Tenant in elke query. Binnen de registry wordt elke leesactie geparametriseerd door tenant_id. Er is geen "lijst alle servers"-pad; alleen "lijst alle servers in deze tenant." Het hardcoderen van het filter in de datatoegangslaag sluit lekken tussen tenants niet uit als categorie van bugs — caching, asynchrone context-propagatie, achtergrond-workers, zoekindexen en telemetrie-joins kunnen allemaal nog steeds lekken — maar het verwijdert de grootste en meest waarschijnlijke vector, namelijk die waar een ontbrekende WHERE-clausule in een RBAC-controle de rijen van de verkeerde tenant retourneert.

Tenant in de identiteit. Medewerkers worden herleid via het identiteitsmodel van het control plane. Gebruikers behoren tot tenants; teams zijn afgebakend tot tenants; virtuele accounts worden aangemaakt binnen tenants. De eerste controle van het RBAC-engine is of de tenant van de aanroeper overeenkomt met de tenant van de resource.

Conceptueel querypad — tenant-filter is niet onderhandelbaar

Gedeelde diensten over bedrijfsonderdelen bij Continental

Continental's divisies voor avionica en grondsystemen draaien als afzonderlijke tenants op hetzelfde control plane. Meestal is dat exact de bedoeling — de vloot-telemetrieserver is niet relevant, en wettelijk niet gepast, voor engineers van grondsystemen om te zien. Maar één server, een enterprise documentatie-MCP, moet voor beiden zichtbaar zijn. Het patroon is een expliciete cross-tenant medewerkerstoekenning: de tenant_id van de vermelding blijft in de beherende tenant, maar de collaborators-lijst bevat een principal van de andere. Gedeelde zichtbaarheid is een bewuste, geauditeerde toekenning — nooit een ongeluk.

6. Openbare vs. Self-Hosted Registratieflows

Het registreren van een openbare MCP-server en het registreren van een self-hosted server zijn conceptueel dezelfde handeling — het produceren van een registry-vermelding — maar de workflows zien er anders uit, en de registry moet beide ondersteunen.

Voor openbare servers (GitHub, Linear, Sentry, Atlassian, Slack, Exa, Playwright MCP, DeepWiki, Context7) wordt de handeling teruggebracht tot een paar kliks. De "Add MCP Server"-flow van de MCP Gateway biedt vijf registratiepaden: Connect Official Remote MCP Servers, Connect any Remote MCP Server, Create a Virtual MCP Server, Import from OpenAPI Spec, en Hosted Stdio-based MCP Server. De eerste kiest uit een samengestelde catalogus met vooraf ingevulde auth-metadata; u levert de OAuth client-ID/geheim en de rest van de vermelding wordt gegenereerd.

Self-hosted servers — Continental's interne fleet-telemetry-readonly, bijvoorbeeld — gebruiken Connect any Remote MCP Server (voor HTTPS-endpoints) of Hosted Stdio-based MCP Server (voor CLI-achtige servers). Het stdio-pad is interessant omdat de gateway verantwoordelijk wordt voor het uitvoeren van het proces, niet alleen voor het aanroepen ervan. De stdio-documentatie definieert de geverifieerde YAML-manifestvorm: command, args, en een auth_data-blok met hetzij auth_level: per_user (het geheim van elke aanroeper gesubstitueerd in {{API_KEY}}) of auth_level: global (één gedeelde waarde binnen de tenant). De bijbehorende mcp-registry-manifests.yaml bevat vier uitgewerkte voorbeelden voor beide auth-niveaus en het Virtual MCP Server-patroon.

Ongeacht het pad valideert de registry of een nieuw geregistreerde server bereikbaar is voordat deze wordt gepubliceerd. Voor remote HTTPS-servers is dat een probe tools/list. Voor stdio start de gateway een kortstondig proces op, stuurt initialize, en zorgt ervoor dat de server correct reageert. Een server die niet geprobed kan worden, wordt geweigerd bij registratie — niet toegevoegd in een kapotte staat die later als 503's naar boven komt zodra ontwikkelaars deze proberen te gebruiken.

7. Tool Schema-versiebeheer en Cache-invalidatie

Het cachen van het tool-schema maakt het verschil tussen een bruikbare registry en een onbruikbare. Een naïeve implementatie die tools/list aanroept tegen elke stroomopwaartse server bij elk agent-verzoek vermenigvuldigt de latentie van de gateway met het aantal stroomopwaartse servers en voegt een foutmodus per server toe. De cache lost het latentieprobleem op en creëert een nieuwe: schema-drift.

De gateway onderhoudt een cached_tool_schema per vermelding, die op twee manieren wordt ververst.

Event-driven verversing. De MCP-specificatie definieert een listChanged notificatie die servers die { "tools": { "listChanged": true } } declareren kunnen uitzenden wanneer hun toollijst veranderd. Voor servers die zowel de functionaliteit declareren als betrouwbaar uitzenden via hun permanente verbinding, ziet de gateway de notificatie als een invalidatiesignaal en haalt verse gegevens op voordat de volgende aanroeper verouderde gegevens te zien krijgt. Dit is het snelle pad wanneer het beschikbaar is — maar het is niet universeel: veel MCP-servers implementeren listChanged helemaal niet, en sommige declareren de functionaliteit wel maar zenden inconsistent uit over verschillende transporten.

Periodieke verversing. Voor al het andere voert de gateway op een instelbare frequentie opnieuw een probe uit (lage enkele minuten voor actieve servers, langer voor bekende rustige servers). De probe hergebruikt de bestaande verbindingspool. In de praktijk leunen de meeste productie-uitrollen op periodieke verversing als het primaire mechanisme en behandelen listChanged als opportunistisch wanneer het werkt.

8. Health Checking en Circuit Breaking voor MCP-servers

De registry moet weten wat actief is. Anders gebeurt het ergste: het beveelt een tool aan waarvan de server al een uur 503's geeft, en elke agent in de tenant krijgt een timeout bij de poging deze aan te roepen.

Het health-subsysteem draait drie lussen.

Probe. Een achtergrond-worker roept tools/list aan tegen elke server op een instelbare frequentie. Succes bevordert de server naar healthy en ververst het gecachte schema; mislukking (netwerkfout, 5xx, ongeldige payload) verhoogt een teller.

Drempelwaarde. Zodra de teller een drempelwaarde overschrijdt — ingesteld per serverklasse, aangezien openbare SaaS meer speling krijgt dan interne systemen — gaat de server over naar unhealthy en worden de tools gemarkeerd. Na een tweede drempelwaarde opent de breaker (circuit_open). De meeste uitrollen kiezen ervoor om een server met een open circuit volledig te onderdrukken in tools/list-responsen zodat agents een kleinere toollijst zien in plaats van een lijst met defecte vermeldingen; sommige houden de tools zichtbaar maar markeren ze, onder de gedachte dat agent-planners zich beter kunnen aanpassen aan "niet beschikbaar" dan aan "ontbrekend." De juiste keuze hangt af van hoe uw agents omgaan met afwezigheid.

Herstel. De breaker is halfopen na een afkoelperiode: één probe; bij succes gesloten; bij mislukking verdubbelt de afkoelperiode. Standaard hygiëne voor exponentiële back-off.

De reden waarom dit belangrijk is, is niet latentie — het is de compositie van betrouwbaarheid. Zonder circuit breaking faalt een agent die afhankelijk is van zeven stroomopwaartse servers wanneer een van hen faalt. Met circuit breaking verliest de agent de tools van één server en gaat door met de overige zes. Voor Continental's incident-response agent tijdens piketdienst is dat het verschil tussen "we gaan door met triageren terwijl Sentry plat ligt" en "de AI-assistent ligt zelf plat omdat Sentry plat ligt."

Gedistribueerde configuratie vs. gecentraliseerde registry

De verschillen manifesten zich op zes dimensies.

Continental, voor en na

9. Veelgestelde vragen (FAQs)

Moet de registry in dezelfde control plane staan als de rest van onze AI-infrastructuur?

Dat hoeft niet per se, maar het combineren met de model gateway levert steeds meer voordelen op — dezelfde RBAC-engine, secret-manager-integratie, audit-pipeline en identiteitsmodel bedienen zowel modelverkeer als toolverkeer. De TrueFoundry MCP Gateway maakt om deze reden bewust deel uit van dezelfde control plane als de AI Gateway.

Wat gebeurt er als de lokale IDE-configuratie van een ontwikkelaar conflicteert met de registry?

Dat gebeurt niet, omdat de IDE-configuratie geen credentials meer bevat — alleen een gateway-URL. Na v0.130 klapt de Cursor- of VS Code-configuratie voor een MCP-server in elkaar tot een tenant-scoped gateway-URL plus de OAuth- of IdP-bootstrap die uw organisatie al vereist — de gateway regelt de credential-afhandeling aan de andere kant. Er is geen geheim per server in de IDE-configuratie dat kan afwijken van de registry.

Hoe gaat de registry om met servers met aangepaste of niet-standaard authenticatie?

Via Token Forwarding. De client stelt x-tfy-mcp-headers in met de authenticatie die de upstream vereist, en de gateway stuurt deze door. Dit is de ontsnappingsroute voor servers waarvan de schema's niet overeenkomen met een ingebouwd model — wat vaak voorkomt bij verouderde interne diensten.

Kunnen we slechts een subset van tools van een geregistreerde server beschikbaar stellen?

Ja, via een Virtual MCP Server. De virtual-server-functie stelt een samengestelde bundel tools samen uit een of meer geregistreerde servers en verleent onafhankelijk toegang tot die bundel. De incident-response-toolkit van Continental is een virtuele server die read-only Sentry-tools plus read-only vloot-telemetrietools beschikbaar stelt aan het on-call team — geen van de destructieve bewerkingen is bereikbaar.

Wat als een upstream MCP-server zijn transport wijzigt van streamable HTTP naar SSE?

De gateway volgt de server. Vanaf v0.130 behoudt deze het transport van de upstream in plaats van te normaliseren naar streamable HTTP. Clients die het patroon van de specificatie volgen (eerst streamable-http, dan SSE-fallback) blijven werken zonder configuratiewijzigingen.

Hoe werkt de registry samen met autonome agents die tijdens runtime tools moeten ontdekken?

Dat is precies het doel van §3. Een agent authenticeert zich eenmalig bij de gateway, roept tools/list aan en ontvangt een samengestelde, door RBAC gefilterde tool-lijst. Vervolgens kan deze tools/call aanroepen met alles uit die lijst. Geen vooraf vastgelegde inventaris, geen hernieuwde deployments.

Wat is de eenvoudigste manier om te beginnen?

Registreer één server die u al gebruikt — Linear, GitHub of Sentry zijn meestal de eerste keuzes omdat de auth-flows goed beproefd zijn — en richt de IDE-configuratie van één team op de gateway-URL. Probeer niet 240 ontwikkelaars en 8 servers in één keer te migreren; migreer één server en 10 ontwikkelaars, leer van de uitrol en breid daarna uit.

Neem de volgende stap

Als ~/.cursor/mcp.json-drift uw platformteam tijd begint te kosten, is dat het signaal om te centraliseren. De TrueFoundry MCP Gateway is de registry-en-policy-laag die we voor die overgang hebben gebouwd; u kunt de architectuurdocumentatie lezen of het gratis proberen.

Aanbevolen lectuur

• TrueFoundry MCP Gateway — overzicht · gecentraliseerde registry, voor-en-na-kadering
• MCP Gateway — authenticatie en beveiliging · inkomende vs uitgaande auth, alle zeven uitgaande modellen
• MCP Gateway — aan de slag · de vijf registratiepaden en het medewerker-/rolmodel
• Gehoste op stdio gebaseerde MCP-server · geverifieerde YAML-manifestvorm, op env gebaseerde auth
• Virtual MCP Server · samengestelde toolbundels zonder hernieuwde deployment
• Secret Manager gebruiken in Integrations · het tfy-secret://-referentieformaat
• v0.130 URL- en transportwijzigingen · tenant-in-URL, OAuth chaining, SSE-fallback
• MCP-specificatie — tools · tools/list, tools/call, listChanged melding
• Claude enterprise-beveiliging — MCP Gateway met allowlisting · patroon voor beheerde enterprise-uitrol

‍

‍