Wat is MCP Registry? En waarom je geen Agents kunt draaien zonder

Als je hebt gespeeld met Anthropic’s Model Context Protocol (MCP), ben je waarschijnlijk tegen de "localhost-muur" gelopen.

Je clonet een repository, voert npx @modelcontextprotocol/server-postgres uit, verbindt het met Claude Desktop en het voelt als magie. Je LLM kan plotseling met je database praten. Maar op het moment dat je die architectuur naar productie probeert te brengen -- waar je vijftig agents, twintig databronnen en strikte IAM-rollen hebt -- verandert de "magie" in een nachtmerrie van gedistribueerde systemen.

Je hebt niet alleen een protocol nodig. Je hebt een telefoonboek nodig. Je hebt een broker nodig die weet waar elke tool zich bevindt, wie deze mag aanroepen en of deze momenteel goed functioneert.

In de industrie krijgt dit concept vorm als de MCP Registry.

Bij TrueFoundry behandelen we de registry niet zomaar als een statische lijst met URL's. We implementeren het als een actieve, routende infrastructuurlaag met behulp van wat wij Virtual MCP Servers noemen. Hier is een diepgaande blik op waarom de registry het meest kritieke onderdeel is dat je waarschijnlijk negeert.

Het probleem: De "N x M" verbindingsmatrix

Zonder een centrale registry is de topologie van een agentic systeem een rommel.

Stel dat je drie Agents hebt (Support, Sales, DevOps) en drie Tools (Jira, Salesforce, AWS). Als je ze rechtstreeks verbindt, moet je de endpoints en authenticatie voor elke tool in de configuratie van elke agent hardcoden.

Als het DevOps-team de Jira-tool naar een nieuw cluster verplaatst, breekt elke agent. Als je de API key voor Salesforce roteert, moet je elke agent opnieuw deployen.

De MCP Registry lost dit op door de consument (de Agent) los te koppelen van de provider (de Tool). De Agent verbindt met de Registry, en de Registry routet het verzoek naar de juiste tool.

Hier is het verschil in topologie.

Fig 1: Workflow van rechtstreekse verbindingen versus Registry-topologie

De aanpak van TrueFoundry: De "Virtual" Registry

We hebben het registry-patroon geïmplementeerd met behulp van een functie genaamd de Virtual MCP Server. Dit verandert de Gateway effectief in een geïntegreerde MCP registry and ai gateway, die discovery, beveiliging en runtime routing combineert in één control plane voor agentic systemen.

In plaats van een afzonderlijke "catalogus"-database te bouwen die agents moeten bevragen, hebben we de registry rechtstreeks in het netwerkpad ingebouwd. De TrueFoundry AI Gateway fungeert als een "Virtual" MCP-server die zich voor je werkelijke backend-services bevindt.

Zoals uitgelegd in de TrueFoundry documentatie over Virtual MCP Servers:

"A Virtual MCP Server aggregates multiple MCP Servers into a single MCP Server. This allows an MCP Client to connect to a single endpoint and access tools/prompts/resources from multiple MCP Servers."

Dit is een subtiele maar enorme verschuiving. Voor je Agent ziet de Gateway eruit als één gigantische MCP-server met oneindige mogelijkheden. Achter de schermen routet de Gateway verkeer naar een postgres-mcp pod in Cluster A en een slack-mcp pod in Cluster B.

Mogelijkheden van een actieve Registry

Een goeie registry doet meer dan alleen tools opstommen. Het beheert de levenscyclus van de interactie.

1. Dynamische Discovery

Wanneer een agent verbinding maakt met de TrueFoundry Gateway, hoeft deze van tevoren niet te weten welke tools er bestaan. De verbinding maakt gebruik van Server-Sent Events (SSE). Bij de handshake inspecteert de Gateway de identiteit van de Agent en bouwt dynamisch een lijst op van tools die de agent mag zien.

Als je morgen een nieuwe Vector Search Tool deployt, voeg je deze gewoon toe aan de Gateway-configuratie. De volgende keer dat de Agent verbinding maakt, is de nieuwe tool automatisch beschikbaar. Er zijn geen code-wijzigingen nodig aan de kant van de Agent.

2. Gecentraliseerde Authenticatie (De Portier)

Dit is het gedeelte waar InfoSec blij van wordt. Als je ruwe MCP draait, heeft je agent de database-credentials nodig. Dat is vanuit beveiligingsoogpunt een absolute no-go.

Met een op registry gebaseerde aanpak maken we gebruik van Gateway Auth & Security. De Agent bezit alleen een TrueFoundry API Key. De Gateway beheert de secrets voor de daadwerkelijke downstream services.

"The Gateway validates the client's API key... and then proxies the request to the backend MCP server using secure headers."

3. Shadowing en Governance

Omdat elke tool call via de Registry (de Gateway) stroomt, krijg je een gecentraliseerde audit log. Je kunt precies zien welke agent op welk moment de delete_user tool heeft aangeroepen. Je kunt ook rate limits afdwingen, zodat een oneindige loop in een agent je productie-database niet laat crashen.

Tabel 1: Dit is de vergelijking van Registry-typen

Integratie: Hoe het erin ziet in code

Het mooie van deze abstractie is hoe schoon de clientcode wordt. Je hoeft je geen zorgen meer te maken over de infrastructuur.

Zoals gedetailleerd beschreven in de gids over het gebruik van de MCP Gateway in een Agent, verwijs je je MCP-client eenvoudig naar het virtuele endpoint.

Waarom dit belangrijk is

We bewegen voorbij de "chatbot"-fase van AI en gaan de "agentic"-fase in. In de praktijk betekent dit dat LLM agents nu afhankelijk zijn van infrastructuurlagen zoals MCP registries om tools te ontdekken, rechten af te dwingen en betrouwbaar uit te voeren in verschillende omgevingen. In deze nieuwe wereld zijn je interne API's de meest waardevolle assets die je hebt.

Het veilig beschikbaar stellen daarvan aan LLM's is een infrastructuurprobleem, geen modelleringsprobleem. Dit is een van de redenen waarom MCP vs RAG van belang is bij het ontwerpen van enterprise agent-workflows.

Door de MCP Registry te behandelen als een essentieel onderdeel van de infrastructuur -- beheerd via TrueFoundry’s Virtual MCP Servers -- krijgen we de mogelijkheid om tools te behandelen als microservices. We kunnen ze deployen, schalen, beveiligen en uitfaseren zonder de agents te verstoren die ervan afhankelijk zijn.

Het verandert een chaotische wirwar van Python-scripts in een opbouwbare enterprise-architectuur.

‍

‍