Wat is een MCP Gateway? Een praktische gids voor enterprise AI-teams

Waarom hebben AI-agents een gestandaardiseerde integratielaag nodig?

De eerste generatie LLM-systemen was grotendeels passief. U stuurde een prompt. U ontving tekst. Als het antwoord fout was, was dat onhandig, maar niet fataal. Dat model geldt niet meer.

Moderne AI-agents voeren databasequery's uit, passen tickets aan, versturen e-mails en starten downstream-automatisering. Ze genereren niet alleen taal. Ze voeren intentie uit. En zodra uitvoering in beeld komt, is de architectuur belangrijker dan prompt engineering.

De meeste teams beginnen met rechtstreekse integraties. Een agent krijgt een GitHub API-sleutel. Een andere krijgt Slack-credentials. Een derde maakt verbinding met het CRM. Elke integratie wordt onafhankelijk gebouwd, vaak binnen applicatiecode of wrapper-scripts. Het voelt snel. Het ís snel. Maar het schaalt niet.

Elke agent beheert zijn eigen credentials. Toegangsregels zijn verspreid. Observabiliteit raakt gefractioneerd over meerdere systemen. Om een nieuwe tool toe te voegen, moet u weer een rechtstreekse verbinding leggen. Al snel heeft niemand meer een helder overzicht van welke agent toegang heeft tot welk systeem.

Het patroon ziet er ongeveer zo uit:

Er is geen controlelaag. Geen centraal auditspoor. Geen uniform beleid voor afdwinging.

Naarmate het aantal agents toeneemt, wordt deze topologie kwetsbaar. Wat begint als flexibiliteit, verandert geleidelijk in een operationeel risico. Een gestandaardiseerde integratielaag gaat niet over elegantie. Het gaat over inperking (containment).

Wat is een Model Context Protocol (MCP)?

Het Model Context Protocol, of MCP, is een open protocol dat definieert hoe AI-modellen externe tools ontdekken en ermee communiceren. In plaats van dat elk model op een andere manier integreert met elke API, introduceert MCP een gemeenschappelijke taal tussen agents en systemen. Het bouwt voort op concepten die vergelijkbaar zijn met het Language Server Protocol en past hetzelfde idee van gestandaardiseerde capaciteitsonderhandeling toe op AI-toolgebruik.

In de kern gebruikt MCP JSON-RPC over HTTP. Wanneer een MCP client verbinding maakt met een MCP server, voert deze een ontdekkingsstap (discovery step) uit. Het model stuurt een tools/list-verzoek om te begrijpen welke beschikbare tools worden blootgesteld.

{

 "method": "tools/list"

}

De server reageert met een gestructureerde lijst van MCP tools, inclusief hun namen, invoerschema's en verwachte uitvoer. Van daaruit kan de agent een specifieke tool aanroepen met behulp van een call_tool-methode, waarbij argumenten worden doorgegeven die voldoen aan het gedeclareerde schema.

Deze handshake is essentieel. Het meent de ontdekking en aanroep van capaciteiten over verschillende providers en systemen heen te standaardiseren. Een GitHub-connector en een Postgres-connector stellen backend-tools anders beschikbaar, maar via MCP presenteren ze een uniforme interface aan het model.

In feite neemt MCP de explosieve toename van aangepaste integraties weg. In plaats van voor elke model–tool-combinatie maatwerkcode te schrijven, implementeren teams MCP servers eenmalig en laten ze modellen communiceren via een uniform protocol. Dit is de MCP-standaard geworden voor de manier waarop AI-modellen communiceren met backend-services en databronnen in het gehele MCP-ecosysteem.

Maar protocolstandaardisatie is niet hetzelfde als governance. Dat onderscheid wordt belangrijk.

Wat is een MCP Gateway?

Als MCP definieert hoe modellen met tools praten, definieert een MCP Gateway wie mag praten en onder welke voorwaarden.

Een MCP Gateway bevindt zich tussen AI-agents en een of meer MCP-servers. In plaats van dat agents rechtstreeks verbinding maken met GitHub-servers, databaseconnectoren of workflow-engines, maken ze verbinding met de gateway. De gateway wordt het enkele eindpunt: een centraal toegangspunt (ingress) voor het ontdekken en aanroepen van tools. Het fungeert als een gecentraliseerde proxy voor al het MCP-verkeer.

Vanuit het perspectief van de agent verandert er structureel niets. Het voert nog steeds een tools/list-handshake uit. Het verzendt nog steeds call_tool-verzoeken. Maar die verzoeken worden onderschept, geëvalueerd en gerouteerd door de gateway voordat een backendsysteem ze uitvoert.

Een MCP Gateway vervult minimaal vier rollen.

Ten eerste: discovery-beheer. Het filtert welke tools zichtbaar zijn voor welke agents.

Ten tweede: routing. Het stuurt verzoeken door naar de juiste MCP-server.

Ten derde: authenticatie. Het valideert identiteit en kan credentials namens een gebruiker doorgeven.

Ten vierde: afdwinging van beleid. Het kan rate limits, scope-beperkingen of uitvoeringsrestricties toepassen voordat het verkeer wordt doorgestuurd.

Architectonisch is het verschil eenvoudig maar ingrijpend:

De MCP Gateway centraliseert de controle zonder individuele servers aan te passen. MCP blijft het protocol. De gateway wordt de beheerlaag die protocolgebruik veilig maakt in productie.

Waar MCP alleen tekortschiet in enterprise-omgevingen

MCP standaardiseert interactie. Het standaardiseert geen controle.

Standaard definieert MCP geen rolegebaseerde toegangscontrole (RBAC). Als een agent verbinding kan maken met een server, kan deze elke tool ontdekken die die server beschikbaar stelt. Er is geen ingebouwd concept van het afbakenen van zichtbaarheid per team, per workload of per gebruiker. Toegang wordt een infrastructuurvraagstuk buiten het protocol zelf.

Er is ook geen gecentraliseerde auditlaag. Elke MCP-server kan zijn eigen activiteit loggen, maar er is geen inherent aggregatiepunt dat toont welke agent welke tool heeft aangeroepen, namens wie en in welke volgorde. Het reconstrueren van intenties over verschillende MCP-servers wordt een handmatige taak.

Kostenbeheer vertoont een vergelijkbaar gat. MCP houdt het tokenverbruik niet bij en dwingt geen gebruiksgrenzen af. Een agent kan herhaaldelijk tools aanroepen, wat modelaanroepen of databasequery's triggert, zonder ingebouwde budgetbeperkingen.

Dan is er het probleem van de tool-explosie. Naarmate organisaties meer connectoren toevoegen — GitHub, Slack, interne diensten, observabiliteitssystemen — groeit de lijst met ontdekbare tools. Zonder zichtbaarheidscontrole worden agents blootgesteld aan functionaliteiten die ze mogelijk niet nodig hebben. Dit bemoeilijkt de logica en vergroot de impact bij eventuele fouten (blast radius). In de praktijk verandert het ontbreken van beveiligingsbeleid een governance-gat in een actief risico.

MCP is noodzakelijk. Het is niet voldoende. Enterprise-implementatie vereist een aanvullende controlelaag.

Wat is een MCP Gateway en de rol ervan in productie-AI-systemen

Hoe kan een MCP Gateway het beste worden begrepen in productieomgevingen? Het is niet zomaar een routing-proxy, het gedraagt zich meer als een control plane boven meerdere execution planes.

Het execution plane bestaat uit MCP-servers. Ze maken verbinding met GitHub, Postgres, Slack, interne API's en legacy-systemen. Ze voeren acties uit. Ze retourneren resultaten.

Het control plane bevindt zich bij de gateway. Het bepaalt welke agent welke tools kan zien, onder welke identiteit en met welke beperkingen. Dat onderscheid is subtiel, maar verandert de manier waarop risico's worden beheerd. Een MCP Gateway is een reverse proxy die speciaal is gebouwd voor MCP-verkeer, met beveiligingsfuncties die standaard proxy's niet bieden.

Een cruciale mogelijkheid is identiteitsdoorgifte (identity propagation). In veel echte systemen handelt een AI-agent namens een menselijke gebruiker. Zonder doorgifte draait de agent vaak met een gedeeld service-account. Met een gateway kan de identiteit van de geauthenticeerde gebruiker downstream worden geïnjecteerd via OAuth- of OIDC-tokens.

De stroom ziet er ongeveer zo uit:

De gateway valideert de JWT, koppelt deze aan de machtigingen van Alice en stuurt het verzoek door met haar specifieke credentials. Als Alice een repository niet mag verwijderen, kan de agent die namens haar handelt dat ook niet. Autorisatie wordt afgedwongen op de protocollaag, niet aangenomen in prompts.

Tool slicing is een andere kernfunctie. De gateway filtert tools/list-antwoorden en toont alleen een subset die relevant is voor een specifiek team of specifieke workload. Gevaarlijke functies verschijnen simpelweg nooit in de context van de agent. Gevoelige gegevens en eindpunten met hoge privileges blijven onzichtbaar voor agents die er geen toegang toe horen te hebben.

Ten slotte vindt afdwinging van beleid plaats op de protocollaag. Voordat een call_tool-verzoek een server bereikt, kan de gateway argumenten inspecteren, quota toepassen of bewerkingen volledig blokkeren.

In productie-AI-systemen wordt deze intermediatielaag het verschil tussen experimenteren en beheersbare infrastructuur.

Beveiligings- en operationele risico's zonder een MCP Gateway

Rechtstreekse model-naar-tool-verbindingen lijken efficiënt totdat u de mogelijke foutscenario's bekijkt.

Het eerste probleem is credential sprawl (wildgroei van inloggegevens). Elke agent draagt vaak zijn eigen API-sleutels of service-accounts met zich mee. Die sleutels bevinden zich in omgevingsvariabelen, configuratiebestanden of secret stores verspreid over verschillende diensten. Het roteren van credentials wordt tijdrovend. Het intrekken van rechtstreekse toegang voor een gecompromitteerde workflow is nog erger. Er is geen centraal controlepunt.

Daarna volgt overmatige blootstelling van tools. Wanneer agents brede, rechtstreekse toegang krijgen tot alle beschikbare MCP-servers, kan de reactie op tools/list overvol raken. Modellen presteren beter wanneer de actieruimte beperkt is. Het tonen van tientallen losjes gerelateerde externe tools verhoogt de complexiteit van de redenering en vergroot de kans op het selecteren van de verkeerde tool. Met andere woorden: beveiligingsniveau en modelprestaties nemen samen af.

Ook de observabiliteit lijdt eronder. Zonder een gateway die het MCP-verkeer aggregeert, vereist het traceren van het gedrag van een agent het uitpluizen van logs over meerdere MCP-servers. Er is geen geünificeerde tijdlijn van uitvoering. Foutopsporing (debugging) wordt giswerk.

Ten slotte is er de blast radius. Als een agent rechtstreeks verbinding maakt met productiesystemen met hoge privileges, planten fouten zich onmiddellijk voort. Een verkeerd geïnterpreteerde instructie kan onomkeerbare bewerkingen starten.

Het ontbreken van een controlelaag vermindert niet alleen de elegantie. Het verhoogt het operationele risico op een manier die zich in de loop van de tijd stilzwijgend opbouwt.

MCP Gateway vs Server

De terminologie kan verwarrend zijn, vooral omdat beide componenten MCP spreken.

Een MCP server is een uitvoerder (executor). Deze maakt verbinding met een specifiek systeem (GitHub, Slack, Postgres, een interne API) en stelt tools beschikbaar die concrete acties uitvoeren. Het weet hoe het een call_tool-verzoek moet vertalen naar een databasequery of een API-aanroep. Het voert het werk uit.

Een MCP Gateway daarentegen is een orchestrator. Het voert geen zakelijke logica uit. Het beheert de toegangscontrole tot backend-servers. Het filtert discovery-antwoorden, dwingt authenticatie af, geeft identiteiten door, past beveiligingsbeleid toe en routeert verzoeken naar het juiste uitvoerings-eindpunt.

Het onderscheid is structureel:

Zonder servers zijn er geen tools. Zonder gateways is er geen gecentraliseerde controle. In productiearchitecturen bestaan beide rollen meestal naast elkaar, waarbij elk op een ander verantwoordelijkheidsniveau opereert. Het toevoegen van nieuwe MCP-servers is eenvoudig wanneer ze via een gateway worden geregistreerd; nieuwe servers worden eenmalig geonboard en hun tools worden selectief in plaats van universeel beschikbaar gemaakt.

Is MCP beter dan een API Gateway?

MCP is geen vervanging voor API's, en het is geen vervanging voor een API-gateway.

API's blijven de fundamentele interface tussen systemen. Ze definiëren contracten, dwingen schema's af en stellen zakelijke functionaliteiten op een gestructureerde manier beschikbaar. API-gateways bevinden zich voor die interfaces en verwerken authenticatie, rate limiting, verkeersbeheer en soms transformaties.

MCP opereert op een ander niveau. Het vervangt geen REST-eindpunten of GraphQL. In plaats daarvan maakt het die API's bruikbaar voor AI-modellen. Via gestandaardiseerde tool-discovery en -aanroepen vertaalt MCP gestructureerde API-functionaliteiten naar een formaat waar modellen over kunnen redeneren. Dit onderscheid is vooral belangrijk voor systeemintegraties waarbij zowel traditionele diensten als AI-gestuurde workflows betrokken zijn.

In moderne enterprise-architecturen bestaan de twee vaak naast elkaar. API's bedienen applicatiediensten en integraties. API-gateways beheren het traditionele HTTP-verkeer. MCP-servers stellen geselecteerde functionaliteiten beschikbaar aan agents. Een MCP Gateway beheert vervolgens de toegangscontrole van de agent.

De relatie is complementair, niet competitief. Het verwijderen van API's zou systeemintegratie laten instorten. Het verwijderen van MCP zou die API's onzichtbaar maken voor modellen. Productie-AI-systemen vereisen meestal dat beide lagen samenwerken.

Kernfunctionaliteiten van een Enterprise MCP Gateway

Niet elke gateway die JSON-RPC-verkeer doorstuurt, is enterprise-ready. Productieomgevingen vereisen meer dan alleen routing. Ze vereisen identiteit, zichtbaarheid en bewuste afbakening over use-cases variërend van klantenservice tot complexe meerstaps-workflows.

Geünificeerde authenticatie (On-Behalf-Of toegang)

In professionele implementaties handelen agents zelden alleen. Ze handelen voor iemand. Een enterprise MCP gateway valideert de inkomende gebruikerscontext, meestal via JWT of OIDC, en geeft die identiteit downstream door. In plaats van een gedeelde service-sleutel worden verzoeken uitgevoerd namens een specifieke gebruiker.

Dit voorkomt het probleem van de "generieke agent". Als een gebruiker geen toegang heeft tot een productierepository, heeft de agent dat ook niet. Identiteit wordt afgedwongen op het niveau van het protocol, niet aangenomen in prompts.

Gecentraliseerd tool-register

Een enterprise MCP Gateway onderhoudt een register van beschikbare MCP-servers en MCP-tools. In plaats van dat elke agent standaard alles ontdekt, wordt het overzicht centraal beheerd. Nieuwe functionaliteiten van nieuwe servers worden eenmalig geregistreerd en selectief beschikbaar gesteld. Deze configuratie neemt het gat in de documentatie weg dat ontstaat wanneer teams het overzicht verliezen over welke tools bestaan en wie ze mag gebruiken.

Audit logging

Elke tools/list- en call_tool-aanroep kan worden gelogd met metadata: agent-identiteit, gebruikerscontext, argumenten en responsstatus. Dit creëert een samenhangend auditspoor over systemen heen. Foutopsporing en nalevingscontroles (compliance) worden daardoor beheersbaar in plaats van een forensische zoektocht.

Logische groepering van tools

Productiesystemen vereisen vaak een afgebakende blootstelling. Een support-agent heeft geen tools voor databasebeheer nodig. Een financiële workflow heeft geen deployment-functies nodig. Dit type afbakening verbetert de gebruikerservaring direct; agents gedragen zich voorspelbaarder wanneer hun actieruimte bewust is beperkt.

Een eenvoudige configuratie kan er als volgt uitzien:

virtual_server:

 name: support-scope

 allow_tools:

   - github.list_issues

   - github.get_comments

   - crm.update_ticket

De gateway filtert discovery-antwoorden dienovereenkomstig. Agents zien alleen wat ze horen te zien.

Enterprise-functionaliteit gaat niet over het toevoegen van meer tools. Het gaat over het verkleinen van het ongecontroleerde aanvalsoppervlak.

Hoe helpt TrueFoundry’s MCP Gateway organisaties?

De MCP Gateway van TrueFoundry is ontworpen om te werken waar enterprise-workloads zich daadwerkelijk bevinden: binnen de cloudomgeving van de klant. Het kan worden geïmplementeerd in een toegewezen VPC met behulp van Docker-containers, wat betekent dat toolverkeer, credentials en modelinteracties niet over externe, gedeelde infrastructuur hoeven te reizen. Voor gereguleerde sectoren verlaagt dat implementatiemodel alleen al de drempel enorm.

Toegangscontrole wordt afgehandeld met gedetailleerde RBAC over agents, MCP-tools en teams. In plaats van credentials hard te coderen in agent-runtimes, integreert de gateway met gecentraliseerde identiteitsproviders en koppelt rollen aan afgebakende tool-zichtbaarheid. Beveiligingsbeleid is declaratief. Autorisatie vindt plaats vóór de uitvoering.

Het beheer van credentials is een ander praktisch punt. API-sleutels en service-tokens worden centraal opgeslagen en beheerd in plaats van ingebed in code of omgevingsbestanden. Rotatiebeleid kan eenmalig op het niveau van de MCP Gateway worden toegepast, in plaats van op tientallen agents afzonderlijk.

Veilige testomgevingen zijn even belangrijk. Teams kunnen geïsoleerde tool-scopes definiëren voor staging-agents, wat onbedoelde rechtstreekse toegang tot productiesystemen voorkomt. Die scheiding wordt structureel afgedwongen, niet alleen volgens afspraak.

Observabiliteit bindt het systeem samen. Tool-aanroepen, identiteitsdoorgifte, telemetrie en beleidsbeslissingen zijn volledig traceerbaar. Metriek over gebruikspatronen, latentie en MCP-verkeer wordt weergegeven in één enkel dashboard. Wanneer iets zich niet naar behoren gedraagt, kunt u de uitvoeringsketen inspecteren zonder gebeurtenissen over meerdere systemen te hoeven reconstrueren.

Het doel is geen abstractie om de abstractie. Het gaat om inperking, helderheid en gecontroleerde uitvoering over MCP-automatiseringsplatforms binnen infrastructuur die u al zelf beheert.

MCP Gateway vs traditionele benaderingen

Wanneer teams MCP-gateways evalueren, is de echte vergelijking niet alleen met andere gateways. Het is met de alternatieven die ze al gebruiken.

Een gedetailleerde vergelijking om de positionering van TrueFoundry te zien.

Rechtstreekse toegangscontrole maximaliseert de snelheid, maar laat de controle versnipperd en kwetsbaar achter. Een API-gateway verbetert de perimeterbeveiliging, maar begrijpt de intentie van de agent of de afbakening van tools niet. De beste MCP gateway introduceert een beheerlaag die specifiek op de hoogte is van modelgestuurde uitvoering en MCP-verkeer.

Het onderscheid is subtiel, maar het bepaalt of AI-systemen experimenten blijven of volwaardige infrastructuur worden.

Boek een demo om meer te weten te komen over hoe de TrueFoundry MCP Gateway werkt in enterprise-omgevingen.

Tot slot over MCP Gateways

MCP biedt een gemeenschappelijke taal tussen modellen en tools. Dat alleen al is een belangrijke stap voorwaarts. Het vermindert de wildgroei aan integraties en standaardiseert hoe agents externe systemen ontdekken en aanroepen. Maar standaardisatie is geen governance.

Naarmate AI-agents dichter bij operationele systemen komen te staan, wordt de architectuur eromheen doorslaggevend. Wie kan welke tools zien? Onder wiens identiteit worden acties uitgevoerd? Waar bevinden de auditsporen zich? Hoe wordt risico ingeperkt? Die vragen liggen boven het niveau van de protocollaag.

Een MCP gateway beantwoordt ze door controle te introduceren zonder de interoperabiliteit te verstoren.

Voor enterprise-teams is de echte verandering mentaal. Agents zijn geen experimenten meer die aan API's zijn gekoppeld. Het zijn actoren binnen uw productie-infrastructuur. Zodra u dat accepteert, wordt de noodzaak van een control plane minder een optie en meer een structurele vereiste.

Veelgestelde vragen

Wat doet een MCP gateway?

Een MCP gateway bevindt zich tussen AI-agents en MCP-servers. Het bepaalt welke tools een agent kan zien, dwingt authenticatie af, routeert verzoeken en logt activiteiten. In plaats van dat agents rechtstreeks verbinding maken met systemen zoals GitHub of databases, maken ze verbinding met de gateway, die fungeert als een controlelaag. TrueFoundry operationaliseert dit door een geünificeerde interface te bieden die deze verbindingen over uw gehele AI-ecosysteem beheert.

Wat is het verschil tussen een MCP gateway en een server?

Een MCP gateway beheert de toegang tot die servers. Het verwerkt identiteit, zichtbaarheid en afdwinging van beleid voordat een tool wordt aangeroepen. Een MCP server voert acties uit. Het maakt verbinding met een specifieke tool of databron en voert bewerkingen uit. Met de TrueFoundry MCP Registry kunt u deze servers organiseren in beheerde groepen voor een betere administratieve controle.

Wat is het verschil tussen een API gateway en een MCP gateway?

Een MCP Gateway is ontworpen voor agentgestuurde workflows. Het beheert de ontdekking en uitvoering van MCP-tools binnen het MCP-protocol en voegt autorisatie en observabiliteit toe die API-gateways niet bieden. Een API-gateway beheert traditioneel applicatieverkeer. Het begrijpt HTTP-routes, authenticatie en rate limits. TrueFoundry overbrugt deze kloof door een gespecialiseerd AI-control plane te bieden dat de unieke context van LLM-naar-tool-interacties begrijpt.

Is MCP beter dan een API?

Nee, MCP en API's dienen verschillende doelen: API's definiëren systeeminterfaces en REST-eindpunten, terwijl MCP die interfaces bruikbaar en ontdekbaar maakt voor AI-modellen. In de meeste enterprise-systemen moeten beide lagen samenwerken om een naadloze integratie te garanderen. Het TrueFoundry-platform ondersteunt deze samenwerking door standaard connectorinterfaces te bieden waarvoor geen SDK-wijzigingen in bestaande tools nodig zijn.

Hoe helpt TrueFoundry's MCP gateway organisaties?

TrueFoundry biedt een beheerde MCP gateway die in uw cloud draait. Het centraliseert het beheer van credentials, dwingt gedetailleerde toegangscontrole af en biedt observabiliteit over alle workflows van agents.