Top 10 MCP-gateways en -proxies voor lokale AI in 2026

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Top 10 MCP Gateways and Proxies for Local AI in 2026 - Zima Store Online

Eén MCP-server is eenvoudig. Tien ervan kunnen elke AI-client veranderen in een wirwar van endpoints, tokens, toolschema's, transporteigenaardigheden en dubbele machtigingen.

Een MCP-gateway vormt één controlepunt in het midden. Je agents maken één keer verbinding; de gateway beheert tot welke servers ze toegang hebben, welke tools ze kunnen zien, hoe inloggegevens worden geïnjecteerd en hoe elke toolaanroep wordt gerouteerd of geaudit.

Wat is een MCP-gateway en waarom heeft lokale AI er een nodig?

Het Model Context Protocol biedt AI-clients een standaardmanier om tools, resources en prompts te ontdekken en aan te roepen. Het protocol vereist niet dat elke implementatie een gateway heeft.

Als je één AI-client en één of twee MCP-servers gebruikt, zijn directe verbindingen meestal eenvoudiger:

AI-client
   |
   +---- Bestandsysteem-MCP
   |
   +---- GitHub MCP

Het probleem ontstaat wanneer beide kanten zich vermenigvuldigen.

Claude Code ----\
Codex -----------\
OpenClaw ---------> MCP-gateway
Cline ------------/      |
                     +----+-------+-------+
                     |            |       |
                  GitHub       Bestanden    Database
                    MCP         MCP       MCP

In plaats van GitHub-, bestandsysteem-, database-, browser-, automatiserings- en interne MCP-servers afzonderlijk in elke client te configureren, wordt de gateway de gedeelde controlelaag.

Dit is vooral nuttig voor lokale AI-agents. Het model kan op je eigen hardware draaien, maar zodra het geprivilegieerde tools kan aanroepen, lossen lokale uitvoering en eigenaarschap alleen authenticatie, autorisatie, isolatie of auditing niet op.

De belangrijkere architectuurvraag wordt dan:

Modelintentie
     |
     v
MCP-gateway
     |
Authenticatie / Beleid / Toolfilter
Inloggegevens / Logboeken / Routering
     |
     v
Geprivilegieerde tools

Die gatewaylaag houdt nauw verband met de vertrouwensgrens voor tooluitvoering: een model kan een actie aanvragen, maar een afzonderlijke uitvoeringslaag moet bepalen of die actie daadwerkelijk is toegestaan.

Hoe we de beste MCP-gateways en -proxies hebben gerangschikt

Dit is geen ranglijst op basis van GitHub-sterren, en de tien projecten lossen niet allemaal exact hetzelfde probleem op.

Sommige zijn volwaardige MCP-platforms. Andere zijn beveiligingsgateways, aggregators, agentgateways of lichtgewicht transportproxies. We hebben ze gerangschikt op basis van wat het belangrijkst is voor lokale en zelfgehoste AI:

Zelf te hosten: Kun je de gateway draaien op infrastructuur die je zelf beheert?
MCP-aggregatie: Kunnen meerdere MCP-servers achter één endpoint worden samengebracht?
Toolfiltering: Kun je beperken welke tools een agent daadwerkelijk ziet?
Authenticatie en autorisatie: Ondersteunt het clientidentiteit, OAuth, tokens, RBAC, ACL's of beleidsengines?
Beheer van inloggegevens: Kunnen geheimen worden gecentraliseerd in plaats van naar elke AI-client te worden gekopieerd?
Transportondersteuning: Kan het werken met stdio, SSE, Streamable HTTP of andere implementatiepatronen?
Isolatie: Kunnen MCP-servers of de uitvoering van tools worden gescheiden van de host?
Observeerbaarheid: Zijn logboeken, traces, metingen of auditrecords beschikbaar?
Flexibiliteit van implementatie: Past het op een laptop, homeserver, Docker-host, VM of Kubernetes-cluster?
Huidige koers: Is het project nog relevant voor de snel veranderende MCP-stack van 2026?

De numerieke volgorde is redactioneel en geen synthetische benchmarkscore.

De 10 beste MCP-gateways en -proxies voor lokale AI in één oogopslag

Rang	Gateway / proxy	Ideaal voor	Self-hosted	Aggregatie	Beveiliging / beleid	Belangrijkste verschil
1	Docker MCP Gateway	Lokale AI op basis van Docker	Ja	Ja	Sterk	Containerisolatie + beheer van de levenscyclus
2	ToolHive	Beheerde self-hosted MCP-platforms	Ja	Ja	Sterk	Gateway + register + runtime + portaal
3	agentgateway	Uniforme agentinfrastructuur	Ja	Ja	Sterk	MCP + LLM + A2A-gateway
4	MCPJungle	Eenvoudig gedeeld MCP-eindpunt	Ja	Ja	Gemiddeld tot sterk	Soepele migratie van lokaal naar teamgebruik
5	IBM ContextForge	Protocol- en API-federatie	Ja	Ja	Sterk	Federatie van MCP + A2A + REST/gRPC
6	Microsoft MCP Gateway	MCP-infrastructuur voor Kubernetes	Ja	Ja	Sterk	Sessiebewuste routering + beheer van de serverlevenscyclus
7	OpenZiti MCP Gateway	Zero-trust-toegang tot externe MCP	Ja	Ja	Sterk	Geen openbare poorten vereist
8	MetaMCP	Vermindering van toolschemacontext	Ja	Ja	Gericht	Voegt veel MCP-tools samen tot vier metatools
9	Kong AI Gateway	Bestaande gatewaystacks voor ondernemingen	Ja, afhankelijk van de implementatie	Ja	Sterk	Governance voor API + AI + MCP
10	Supergateway	Conversie van MCP-transport	Ja	Beperkt	Basis	stdio ↔ Streamable HTTP / SSE / WebSocket

1. Docker MCP Gateway — Beste algemene keuze voor lokale AI op basis van Docker

Docker MCP Gateway: uniforme, veilige infrastructuur voor agentische AI Docker MCP Gateway: open-source, veilige infrastructuur voor agentische AI | Docker

Docker MCP Gateway is een van de meest natuurlijke startpunten voor een lokale AI-omgeving, omdat MCP-servers uiteindelijk programma's zijn die een veilige en voorspelbare plek nodig hebben om te draaien.

De gateway van Docker bevindt zich tussen AI-clients en MCP-servers en centraliseert configuratie, inloggegevens, routering, authenticatie en beheer van de serverlevenscyclus.

De belangrijkste functie voor self-hosters is isolatie. In plaats van elke MCP-server en diens afhankelijkheden rechtstreeks op de host te installeren, kan Docker servers uitvoeren in beperkte containers met beheermogelijkheden voor privileges, netwerktoegang, CPU-bronnen en geheimen.

De gateway kan ook alleen geselecteerde tools beschikbaar stellen in plaats van elke tool van elke server naar de client door te sturen. De MCP-tooling van Docker bevat profiel- en toolbeheer om ruis en onnodig tokengebruik te verminderen.

Een client kan verbinding maken met één gateway:

{
  "mcpServers": {
    "MCP_DOCKER": {
      "command": "docker",
      "args": ["mcp", "gateway", "run"]
    }
  }
}

terwijl Docker de MCP-serverprocessen erachter beheert.

Dit past bijzonder goed bij een homeserver:

Claude Code / Codex / Cline
            |
     Docker MCP Gateway
            |
    +-------+-------+
    |       |       |
 Bestandssysteem GitHub  n8n
 Container  Server  Server

Ideaal voor: lokale AI-gebruikers die Docker al gebruiken en één gateway willen met geïsoleerde uitvoering van MCP-servers, beheer van geheimen, filtering van tools en gecentraliseerde logs.

Afweging: Docker biedt nu verschillende gerelateerde MCP-ervaringen, waaronder MCP Toolkit, Gateway, Sandboxes en nieuwere governancefuncties. Sommige functies van Docker AI Governance zijn afzonderlijk afgeschermd, dus controleer welke functieset je implementatie daadwerkelijk bevat in plaats van ervan uit te gaan dat elke Docker MCP-mogelijkheid in elke editie beschikbaar is.

2. ToolHive — Beste volledig zelfgehoste MCP-beheerplatform

GitHub - stacklok/toolhive: ToolHive is een platform op ondernemingsniveau voor het uitvoeren en beheren van Model Context Protocol (MCP)-servers. · GitHub

ToolHive gaat veel verder dan een lichtgewicht proxy.

De architectuur is opgedeeld in verschillende lagen:

Gateway: stelt gecontroleerde MCP-endpoints beschikbaar voor clients;
Registry: beheert een catalogus van goedgekeurde MCP-servers en vaardigheden;
Runtime: implementeert en beheert MCP-servers;
Portal: biedt een beheer- en detectie-interface.

De gateway kan meerdere tools samenvoegen, integreren met OAuth/OIDC-identiteitsproviders, toegangsbeleid toepassen, tools en beschrijvingen filteren en auditing centraliseren.

De runtime kan MCP-servers lokaal starten via Docker of Podman, terwijl de Kubernetes Operator dezelfde aanpak uitbreidt naar grotere clusters. Ondersteuning voor OpenTelemetry en Prometheus zorgt voor een veel sterker operationeel verhaal dan een eenvoudige reverse proxy.

Dit maakt ToolHive bijzonder interessant voor teams. Een ontwikkelaar hoeft niet langer een willekeurige MCP-repository te zoeken, deze handmatig te installeren, inloggegevens in een clientconfiguratie te plakken en te hopen dat iedereen dezelfde configuratie correct herhaalt.

In plaats daarvan:

Vertrouwde registry
      |
    Runtime
      |
 MCP-servers
      |
   Gateway
      |
+-----+------+------+
Claude     Codex   VS Code

Ideaal voor: teams die MCP-detectie, implementatie, beveiliging, beleid, observability en gatewaytoegang in één zelfgehost platform willen onderbrengen.

Afweging: ToolHive is aanzienlijk uitgebreider dan nodig voor een configuratie voor één gebruiker. Als je slechts vijf servers achter één endpoint wilt, is MCPJungle eenvoudiger.

3. agentgateway — Ideaal voor MCP-, LLM- en agent-tot-agentverkeer in één laag

Agentgateway v1.0.x – agentgateway | Agentconnectiviteit opgelost

agentgateway is een van de belangrijkste projecten om in de gaten te houden, omdat het een grotere vraag stelt:

Waarom zou je één gateway bouwen voor MCP, een andere voor LLM-API's en nog een andere voor agent-naar-agentverkeer?

De architectuur combineert drie steeds belangrijkere verkeersklassen:

Agent
  |
  +--> LLM-gateway
  |
  +--> MCP-gateway
  |
  +--> A2A-gateway

Voor MCP ondersteunt het federatie van tools en de transports stdio, HTTP, SSE en Streamable HTTP. Authenticatieopties omvatten OAuth, JWT en API-sleutels, terwijl fijnmazige RBAC, snelheidsbeperking, TLS en OpenTelemetry de governance-laag bieden.

Het heeft ook een directe lokale-AI-insteek: agentgateway kan inferentie doorsturen naar zelf gehoste modellen en Kubernetes-inferentie-infrastructuur, in plaats van ervan uit te gaan dat elke modelaanroep naar een cloudprovider gaat.

Het project past zich ook actief aan nieuwe generaties van het MCP-protocol aan, waaronder de veel grotere protocolwijzigingen van 2026 en het compatibiliteitsprobleem dat ontstaat wanneer clients en servers op verschillende momenten worden bijgewerkt.

Het meest geschikt voor: geavanceerde zelf te hosten AI-infrastructuur waarin agents één connectiviteitslaag nodig hebben voor modellen, tools en andere agents.

Afweging: als je enige probleem het consolideren van enkele lokale MCP-servers is, kan agentgateway een uitgebreidere architectuur zijn dan je nodig hebt.

4. MCPJungle — Beste eenvoudige, zelf te hosten gateway voor meerdere MCP-servers

🚀 MCPJungle wordt vandaag geïntroduceerd. Ik heb een project waar ik al een tijd aan werk vandaag als open source beschikbaar gemaakt. SCENARIO Je implementeert AI-agents in je bedrijf. Verschillende teams binnen je organisatie stellen hun interne… |

MCPJungle is waarschijnlijk het eenvoudigste project op deze lijst om uit te leggen:

registreer je MCP-servers één keer en laat je AI-clients vervolgens verbinding maken met één endpoint.

GitHub MCP ------\
Postgres MCP -----\
Filesystem MCP ----> MCPJungle ----> /mcp
Browser MCP -------/                    |
n8n MCP ----------/          +----------+---------+
                              Claude   Cursor   Codex

Het project ondersteunt externe MCP-servers en MCP-servers via stdio en biedt tegelijkertijd uniforme ontdekking van tools, prompts en resources.

Met Tool Groups kun je een implementatie slechts een zorgvuldig geselecteerde subset van de beschikbare tools laten aanbieden voor een specifieke toepassing, in plaats van elke client de volledige toolcatalogus te geven.

MCPJungle biedt ook een nuttige ontwikkeling van persoonlijke naar gedeelde infrastructuur. Je kunt beginnen met Docker Compose en een lokaal endpoint en vervolgens overstappen op clientidentiteiten, toegangstokens, expliciete allowlists voor servers, PostgreSQL en OpenTelemetry naarmate de implementatie belangrijker wordt.

Dat maakt het bijzonder geschikt voor een homelab. Je hoeft niet te beginnen met het installeren van Kubernetes of het bouwen van een enterprise-identiteitsarchitectuur.

Beste voor: ontwikkelaars en kleine teams die één duidelijk MCP-endpoint willen zonder een veel groter AI-infrastructuurplatform te adopteren.

Afweging: geavanceerdere governancefuncties zijn gekoppeld aan de productie- en enterprisegerichte modi, en het beveiligingsmodel is niet zo breed als dat van ToolHive, agentgateway of een volwassen API-gateway.

5. IBM ContextForge — Beste voor het federeren van MCP met bestaande API's en agents

GitHub - IBM/mcp-context-forge: Een AI-gateway, registry en proxy die vóór alle MCP-, A2A- of REST-/gRPC-API's staat en een uniform endpoint met gecentraliseerde ontdekking, guardrails en beheer beschikbaar maakt. Optimaliseert Agent

IBM ContextForge wordt vooral nuttig wanneer je infrastructuur niet netjes uit MCP-servers bestaat.

In echte omgevingen komt meestal een mix voor:

MCP-server
REST-API
gRPC-service
A2A-agent
Verouderde interne API
       |
       v
  ContextForge
       |
       v
   AI-clients

ContextForge fungeert als registry-, proxy- en federatielaag voor MCP-, A2A-, REST- en gRPC-services.

De huidige architectuur omvat functies voor toolgateways, API-vertaling, agentroutering, uitbreidbaarheid via plug-ins, snelheidsbeperking, authenticatie, nieuwe pogingen en op OpenTelemetry gebaseerde observability.

Het project bereikte in 2026 de mijlpaal van algemene beschikbaarheid (1.0), met verdere beveiligingsverharding, protocolverbeteringen, catalogusverbeteringen en productiegerichte implementatiewijzigingen.

Het kan via Python-packaging of Docker worden uitgevoerd en opschalen naar Kubernetes- en multiclusterimplementaties.

Beste voor: organisaties of geavanceerde homelabs die bestaande REST-/gRPC-systemen beschikbaar willen maken voor agents zonder elke service te herschrijven als een speciale MCP-server.

Afweging: ContextForge is breder dan een gateway die alleen voor MCP is bedoeld. Die flexibiliteit brengt meer operationele complexiteit met zich mee dan MCPJungle of Supergateway.

6. Microsoft MCP Gateway — Beste voor stateful MCP-servers op Kubernetes

GitHub - microsoft/mcp-gateway: MCP Gateway is een reverse proxy en beheerlaag voor MCP-servers, waarmee schaalbare, sessiebewuste stateful routering en lifecyclebeheer van MCP-servers in Kubernetes-omgevingen mogelijk worden. · GitHub

Microsoft MCP Gateway is vooral relevant wanneer MCP-servers zelf beheerde infrastructuur moeten worden.

Het project combineert een datagateway met een besturingslaag.

De datalaag routeert MCP-verkeer, terwijl de beheerlaag servers als beheerde resources kan weergeven en implementatie-, update- en verwijderbewerkingen kan afhandelen.

De opvallendste functie is sessiebewuste stateful routering.

Sommige MCP-servers zijn geen onderling uitwisselbare stateless HTTP-endpoints. Een clientsessie moet mogelijk dezelfde backendinstantie blijven bereiken. Microsoft MCP Gateway kan aanvragen met dezelfde sessie-ID terugsturen naar dezelfde serverinstantie, terwijl meerdere instanties achter de gateway mogelijk blijven.

Clientsessie A ----> Gateway ----> MCP-pod 1
Clientsessie A ----> Gateway ----> MCP-pod 1

Clientsessie B ----> Gateway ----> MCP-pod 2

Het project omvat ook autorisatie, telemetrie, integratie met toegangsbeheer en lifecyclebeheer, ontworpen voor Kubernetes-omgevingen.

Ideaal voor: teams die Kubernetes al gebruiken en stateful of dynamisch beheerde MCP-serverparken uitvoeren.

Compromis: dit is niet de meest voor de hand liggende keuze voor één enkele thuisserver. Docker MCP Gateway of MCPJungle is doorgaans veel eenvoudiger te beheren.

7. OpenZiti MCP Gateway — Ideaal voor zero-trust-toegang op afstand tot privé-MCP-tools

We hebben zojuist een open-source LLM Gateway en MCP Gateway uitgebracht, gebaseerd op OpenZiti en zrok: r/OpenSourceeAI

OpenZiti MCP Gateway lost een van de meest praktische problemen met lokale AI op:

Wat gebeurt er als de agent en de MCP-server zich niet op hetzelfde LAN bevinden?

Een veelvoorkomende privéconfiguratie ziet er als volgt uit:

Laptop / AI-client
        |
      Internet
        |
 Thuisserver / NAS
        |
 Privé-MCP-tools

Het conventionele antwoord is vaak om een HTTPS-endpoint beschikbaar te maken, firewallregels te configureren, een VPN op te zetten of een andere reverse proxy vóór de service te plaatsen.

OpenZiti gebruikt daarentegen een zero-trust-overlaybenadering. De MCP Gateway kan interne tools beschikbaar maken als dark services die niet naar openbare IP-adressen luisteren en geen traditionele port forwarding vereisen.

Cryptografische identiteiten, mTLS, isolatie per client en beheer op toolniveau vormen de toegangslaag. Het project kan ook meerdere backends samenvoegen en lokale stdio-servers omzetten in op afstand toegankelijke MCP-services.

Daarom is dit bijzonder relevant voor een privéwerkruimte voor AI-agents waarin de runtime van de agent, bestanden en services op een always-on-thuisserver staan, maar veilig vanaf een ander apparaat toegankelijk moeten zijn.

Ideaal voor: gebruikers die op afstand toegang willen tot privé-MCP-tools zonder die tools rechtstreeks aan het openbare internet bloot te stellen.

Compromis: je neemt het OpenZiti/zrok-netwerkmodel als onderdeel van de oplossing over. Als een conventioneel privélan of een bestaande VPN het verbindingsprobleem al oplost, is dit mogelijk overbodig.

8. MetaMCP — het beste voor het verminderen van contextoverhead door toolschema's

MetaMCP-documentatie - MetaMCP

MetaMCP pakt een ander MCP-schalingsprobleem aan.

Stel dat een agent rechtstreeks verbinding maakt met:

Playwright-MCP      52 tools
Database-MCP        20 tools
GitHub-MCP          30 tools
Filesystem-MCP      15 tools
Monitoring-MCP      18 tools

Het model moet mogelijk een grote verzameling JSON-toolschema's ontvangen voordat het überhaupt nuttig werk kan doen.

Dat neemt context in beslag en kan de toolselectie onrustiger maken.

MetaMCP plaatst die onderliggende servers achter een kleine, stabiele interface. Het huidige ontwerp stelt vier primaire metatools beschikbaar voor discovery, provisioning, aanroepen en uitvoering in meerdere stappen, in plaats van elk downstreamtoolschema rechtstreeks beschikbaar te stellen.

De architectuur wordt:

               +-- Playwright
               +-- GitHub
Lokale LLM --> MetaMCP -- Database
               +-- Bestanden
               +-- Meer servers

Het model ziet: 4 metatools

Dit is vooral interessant voor lokale modellen. Frontier-cloudmodellen beschikken steeds vaker over grote contextvensters en sterk gedrag bij toolselectie, maar kleinere zelfgehoste modellen kunnen gevoeliger zijn voor promptgrootte en grote toolcatalogi.

De documentatie van MetaMCP laat zien hoe de schema-overhead ongeveer constant kan blijven wanneer extra onderliggende MCP-servers worden toegevoegd, in plaats van lineair te groeien met elke downstreamtool.

Het beste voor: lokale AI-implementaties met veel MCP-servers waarbij toolschema's te veel context innemen of de toolselectie van het model verwarren.

Compromis: deze abstractielaag verandert de manier waarop het model met tools communiceert. Je wint contextuele efficiëntie, maar voegt een extra discovery- en routeringslaag toe tussen het model en de daadwerkelijke MCP-tools.

9. Kong AI Gateway — het beste als je al een API-gateway gebruikt

Kong Gateway | Kong Docs

Kong AI Gateway biedt een ander voorstel dan de hierboven genoemde projecten die primair op homelabs zijn gericht.

Als je organisatie Kong al gebruikt voor API's, authenticatie, routering of servicegovernance, kan MCP toevoegen aan hetzelfde control plane aantrekkelijker zijn dan een volledig afzonderlijk MCP-platform implementeren.

De huidige AI Gateway-architectuur van Kong herkent MCP en A2A naast conventioneel modelverkeer. De MCP-serverconfiguratie ondersteunt aggregatie en toegangsbeheer op toolniveau, terwijl bestaande gatewaymogelijkheden authenticatie, routering, metrieken en breder governancebeleid kunnen bieden.

Een nuttig patroon ziet er als volgt uit:

AI-clients
     |
Kong AI Gateway
     |
+----+-------+--------+
|            |        |
MCP A       MCP B    REST API
|            |
Tools       Tools

Dit wordt vooral waardevol wanneer hetzelfde platform al toezicht houdt op normale applicatie-API's en AI-modelverkeer.

Het beste voor: teams die Kong al gebruiken en MCP-governance willen inpassen in een bestaande strategie voor API- en AI-gateways.

Afweging: De beschikbaarheid van Kongs MCP-functionaliteit varieert per implementatie en productconfiguratie, en sommige nieuwere secure-MCP-recepten hebben momenteel specifieke beperkingen voor Konnect. Het is niet de eenvoudigste keuze voor een kleine lokale Docker-server.

10. Supergateway — Beste lichtgewicht MCP-transportbrug

Activiteit · supercorp-ai/supergateway · GitHub

Supergateway hoort om een veel beperktere reden in deze lijst thuis: transportcompatibiliteit.

Veel vroege MCP-software was gebouwd rond stdio. Dat is handig wanneer de MCP-server als childproces draait op dezelfde machine als de AI-client.

Het wordt omslachtig wanneer de server op een NAS, VM, containerhost of een andere machine in het netwerk moet draaien.

Supergateway kan een brug vormen tussen MCP-transporten zoals:

stdio
  |
  +--> SSE
  |
  +--> WebSocket
  |
  +--> Streamable HTTP

en externe Streamable HTTP weer vertalen naar stdio voor clients die nog steeds een lokaal proces verwachten.

Een lokale stdio-bestandsserver kan bijvoorbeeld worden aangeboden als Streamable HTTP:

npx -y supergateway \
  --stdio "npx -y @modelcontextprotocol/server-filesystem ./data" \
  --outputTransport streamableHttp \
  --port 8000

Het ondersteunt ook headers, bearer-authenticatie, health-eindpunten, stateful Streamable HTTP-sessies en verschillende implementatieopties.

Het beste voor: ontwikkelaars die al werkende MCP-servers hebben, maar transportverschillen tussen lokale en externe clients moeten overbruggen.

Afweging: Supergateway is een transportproxy, geen volledig governanceplatform. Het is geen vervanging voor ToolHive, Docker MCP Gateway of agentgateway wanneer je gecentraliseerd beleid, identiteitsbeheer, levenscyclusbeheer en auditing nodig hebt.

Welke MCP-gateway moet je kiezen?

Als je...	Begin met	Waarom
Lokale MCP-servers op basis van Docker	Docker MCP Gateway	Containerisolatie, levenscyclus, geheimen, profielen en toolfiltering
Een compleet MCP-beheerplatform	ToolHive	Gateway, register, runtime, beleid en portal in één stack
MCP-, model- en agent-tot-agent-routering	agentgateway	Verenigt drie lagen voor agentverkeer
Eén eenvoudig zelfgehost MCP-eindpunt	MCPJungle	Aggregatie met weinig frictie en een duidelijke upgrade-route voor teams
REST, gRPC, MCP en agents samen	IBM ContextForge	Bestaande API's federeren in plaats van een infrastructuur die uitsluitend MCP vereist
MCP-fleets op Kubernetes	Microsoft MCP Gateway	Sessiebewuste routering en beheer van de levenscyclus van servers
Externe privét tools zonder geopende poorten	OpenZiti MCP Gateway	Zero-trust-overlayconnectiviteit
Minder toolschema's in de modelcontext	MetaMCP	Grote toolcatalogi samenvatten in metatools
MCP-governance binnen een bestaande API-gateway	Kong AI Gateway	Gebruikt gevestigde infrastructuur voor authenticatie, ACL's, routering en gateways
Conversie van stdio- en HTTP-transport	Supergateway	Eenvoudige transportbrug zonder volledig platform

Docker MCP Gateway versus ToolHive versus MCPJungle

Dit zijn drie van de meest relevante keuzes voor een zelfgehoste omgeving, maar ze richten zich op verschillende complexiteitsniveaus.

Gebied	Docker MCP Gateway	ToolHive	MCPJungle
Primaire gedachte	Voer gecontaineriseerde MCP-servers uit en beheer ze	Beheer een MCP-platform	Plaats veel MCP-servers achter één endpoint
Geschikt voor homelabs	Uitstekend	Goed	Uitstekend
Serverisolatie	Sterke Docker-integratie	Docker / Podman / Kubernetes	Afhankelijk van de implementatie
Registry	Docker MCP-ecosysteem	Registry als kernfunctie	Geregistreerde servercatalogus
Identiteit / beleid	Sterke besturing	Sterk, gericht op teams	Toegangsbeheer voor clients
Observability	Logboekregistratie en tracing	OpenTelemetry / Prometheus	OpenTelemetry-opties
Beste keuze	Docker-gebruikers	Teams / platformengineering	Persoonlijke server tot klein team

Kies Docker MCP Gateway wanneer Docker al de basis vormt van je zelfgehoste AI-stack en containerisolatie belangrijk is.

Kies ToolHive wanneer meerdere ontwikkelaars een vertrouwde MCP-catalogus, gecentraliseerde implementatie, identiteitsintegratie, beleid en monitoring nodig hebben.

Kies MCPJungle wanneer je belangrijkste probleem simpelweg is dat Claude, Codex, Cursor en andere clients niet langer dubbele MCP-configuraties moeten bevatten.

MCP-gateway versus proxy versus aggregator versus transportbrug

De terminologie rond MCP-infrastructuur is nog steeds inconsistent, waardoor alleen productnamen misleidend kunnen zijn.

Laag	Belangrijkste taak	Voorbeeld
Gateway	Centraal toegangspunt met routering, identiteit, beveiliging en governance	Docker MCP Gateway, ToolHive
Proxy	Stuur MCP-verkeer door en voeg geselecteerde besturingselementen toe	Kong, lichtgewicht beveiligingsproxies
Aggregator	Combineer meerdere MCP-servers achter één endpoint	MCPJungle
Metarouter	Verberg grote downstream-toolcatalogi achter een kleinere interface	MetaMCP
Transportbrug	Converteer stdio, SSE, Streamable HTTP of andere transporten	Supergateway
Agentgateway	Beheer MCP plus model- en agent-naar-agentverkeer	agentgateway, ContextForge

Een project kan meerdere van deze taken tegelijk uitvoeren. De nuttige vraag is niet hoe de repository zichzelf noemt, maar welk besturingsprobleem het daadwerkelijk oplost.

Een lokale MCP-gatewayarchitectuur bouwen

Een praktische lokale configuratie hoeft niet te beginnen met een gigantisch platform.

Begin met vier lagen:

AI-clients
Claude Code / Codex / OpenClaw
             |
             v
        MCP-gateway
             |
    +--------+--------+
    |        |        |
 Bestanden     GitHub   Automatisering
 MCP       MCP       MCP
    |
Lokale opslag / NAS

Houd de gateway dicht bij de tools

Als de meeste MCP-servers lokale bestanden, Docker, Home Assistant, databases, Git-repositories of privé-API's benaderen, hoort de gateway doorgaans op hetzelfde vertrouwde servernetwerk te staan, in plaats van op elke laptop van ontwikkelaars.

Dit weerspiegelt de architectuur in een privé-AI-agentwerkruimte: de client kan verplaatsen, maar de privéopslag, runtime, logboeken en automatiseringsservices blijven op een host die altijd aanstaat.

Scheid modelhosting van MCP-hosting

De MCP-gateway hoeft niet op dezelfde machine als de LLM te draaien.

Agenthost             GPU-server
    |                       |
MCP-gateway              Ollama
    |                     vLLM
Lokale tools
    |
Bestanden / DB / API's

Dit is belangrijk omdat MCP-verkeer doorgaans licht is in vergelijking met inferentie. Een bescheiden server die altijd aanstaat, kan gateway- en toolservices hosten, terwijl een werkstation of GPU-node het model uitvoert.

Gebruik samengestelde toolsets in plaats van alles beschikbaar te stellen

Een codeeragent heeft waarschijnlijk geen smart-homebediening nodig. Een onderzoeksagent heeft waarschijnlijk geen Docker-beheer nodig. Een persoonlijke kennisassistent zou niet automatisch toegang tot productiedatabases moeten krijgen.

Bouw afzonderlijke profielen of toolgroepen:

codering
  - github
  - filesystem-dev
  - documenten

onderzoek
  - browser
  - papers
  - lokale-kennis

home-ops
  - monitoring
  - home-assistant
  - docker-alleen-lezen

Dit sluit natuurlijk aan bij lokale AI-workflows: de MCP-laag bepaalt welke mogelijkheden bestaan, terwijl skills en agentinstructies bepalen hoe en wanneer die mogelijkheden moeten worden gebruikt.

Waarom toolfiltering belangrijk is voor lokale modellen

Beveiliging is slechts één reden om het aantal tools te beperken.

Context is nog een ander aspect.

Elke tool kan een naam, beschrijving, argumenten, JSON-schema en andere metadata bijdragen aan het tooloppervlak dat voor het model beschikbaar is.

Met een handvol tools is dit triviaal.

Bij honderden tools kan dit onderdeel worden van het promptbudget:

5 MCP-servers
x 20 tools
= 100 toolschema's

20 MCP-servers
x 20 tools
= 400 toolschema's

Daardoor kan er minder context beschikbaar zijn voor gesprekken, repositorycode, opgehaalde documenten, redeneringen en uitvoer.

Dit kan toolselectie ook moeilijker maken. Als een agent meerdere vergelijkbaar genoemde zoek-, query-, ophaal-, lees- of uitvoertools ziet, wordt het kiezen van de juiste tool een extra redeneertaak.

Er zijn drie hoofdoplossingen:

Toolfiltering: stel alleen de tools beschikbaar die relevant zijn voor een specifieke agent.
Toolgroepen of profielen: bied verschillende catalogi aan verschillende clients.
Meta-routering: bied een kleine interface voor ontdekking en aanroepen en lokaliseer downstreamtools vervolgens op aanvraag.

Docker MCP Gateway en ToolHive leggen de nadruk op filtering en zorgvuldig samengestelde beschikbaarstelling. MCPJungle biedt Tool Groups. MetaMCP gaat het verst door veel onderliggende tools om te zetten in een klein, stabiel oppervlak met metatools.

Dit is nog belangrijker wanneer MCP verbinding maakt met een lokale kennisbank, omdat toolschema's nu met documenten en opgehaalde context concurreren om hetzelfde modelvenster.

Beveiligingschecklist voor een MCP-gateway voor lokale AI

Een gateway is niet nuttig alleen omdat al het verkeer erdoorheen gaat. De waarde zit in wat de gateway daadwerkelijk afdwingt.

Verifieer de client

De gateway moet weten of de aanroeper Codex op een ontwikkelmachine, een altijd actieve agent, een CI-proces of een andere service is.

Beschouw “binnen mijn LAN” niet als identiteit.

Autoriseer servers en tools afzonderlijk

Toegang tot de GitHub-MCP-server betekent niet noodzakelijkerwijs toegang tot elke GitHub-tool.

Een nuttig beleid kan het volgende toestaan:

read_issue
list_pull_requests
search_code

terwijl het volgende wordt geweigerd:

merge_pull_request
delete_repository
change_branch_protection

Houd credentials uit configuratiebestanden van agents

Een van de grootste voordelen van een gateway is dat API-sleutels en servicecredentials worden weggehaald uit de configuratie van elke afzonderlijke AI-client.

De ideale flow is:

Agent
  |
Toolverzoek
  |
Gateway
  |
Injecteer een beperkt toegangsreferentie
  |
MCP-server

Het model hoeft het onderliggende token niet te zien.

Niet-vertrouwde MCP-servers isoleren

Een MCP-server is uitvoerbare software.

Als een server uit een repository van derden wordt geïnstalleerd, behandel hem dan zoals elke andere softwareafhankelijkheid. Controleer het pakket, leg waar mogelijk versies vast, beperk de netwerk- en bestandssysteemtoegang en gebruik containers of andere isolatie waar dat passend is.

Toolaanroepen loggen, niet alleen HTTP-fouten

Wanneer een agent een bestand wijzigt of een extern systeem bijwerkt, heb je voldoende informatie nodig om het volgende te reconstrueren:

welke client het verzoek heeft gedaan;
welke tool is geselecteerd;
welke argumenten zijn goedgekeurd;
welk resultaat is geretourneerd;
of het neveneffect daadwerkelijk is voltooid.

Daarom is observeerbaarheid een belangrijke beoordelingsfactor en geen extra functie die alleen voor ondernemingen bedoeld is.

Omzeilingspaden verwijderen

Een zorgvuldig geconfigureerde MCP-gateway bepaalt niet de werkelijke beveiligingsgrens als dezelfde agent ook beschikt over:

een onbeperkte shell op de host;
een schrijfbare Docker-socket;
beheerdersreferenties;
directe roottoegang tot de database;
nog een onbeperkte MCP-verbinding.

De vertrouwensgrens voor tooluitvoering is alleen betekenisvol wanneer bevoorrechte acties er daadwerkelijk doorheen gaan.

Heb je echt een MCP-gateway nodig?

Waarschijnlijk niet als je configuratie er zo uitziet:

Eén AI-client
   |
Twee MCP-servers

Door een gateway toe te voegen, ontstaat er een extra service die moet worden geïnstalleerd, bijgewerkt, beveiligd, gemonitord en gedebugd.

Een gateway begint zinvol te worden zodra meerdere van deze punten van toepassing zijn:

je gebruikt meerdere AI-clients;
je hebt meerdere MCP-servers;
dezelfde MCP-servers worden herhaaldelijk geconfigureerd;
inloggegevens worden gedupliceerd op clientmachines;
verschillende agents moeten verschillende tools kunnen zien;
externe apparaten hebben toegang nodig tot private MCP-diensten;
je hebt auditlogs nodig;
sommige MCP-servers moeten geïsoleerd draaien;
toolschema's nemen te veel modelcontext in beslag;
je moet stdio- en netwerktransports met elkaar verbinden;
de implementatie wordt gedeelde infrastructuur.

Een nuttige vuistregel is:

1 client + 2 servers
        ↓
Directe MCP is prima

Meerdere clients + meerdere servers
        ↓
Gateway begint te helpen

Teams + inloggegevens + beleid + audit
        ↓
Gateway wordt infrastructuur

Waar past Soth MCP Proxy?

Soth MCP Proxy is ook de moeite waard om in de gaten te houden, vooral als je prioriteit ligt bij het plaatsen van een beveiligingsbeleidslaag vóór een bestaande MCP-implementatie.

Het huidige ontwerp omvat beleidsafdwinging met OPA/Rego, permanente auditlogging, sessiebeheer, Prometheus-metrieken, health-endpoints en TLS.

Dat is een nuttige architectuur:

Agent
  |
Soth-beleidsproxy
  |
Bestaande MCP-server

We hebben het niet opgenomen in de primaire Top 10, omdat het nog een veel eerder project is dan de meeste bovenstaande gateways en verschillende transport- en beheermogelijkheden nog op de roadmap staan.

Beschouw het voorlopig als een veelbelovende lichtgewicht beveiligingsproxy en niet als een volwassen MCP-beheerplatform.

De verschuiving van 2026: de MCP-gateway wordt agentinfrastructuur

De oorspronkelijke MCP-vraag was:

Hoe verbind ik mijn AI-assistent met deze tool?

De nieuwere vraag is:

Hoe beheer ik elke tool die door elke agent wordt gebruikt?

Dat verandert de architectuur.

2025

Agent
  |
MCP-server
  |
Tool


2026

Agents
  |
Agent-/MCP-gateway
  |
Identiteit
Beleid
Routering
Inloggegevens
Tooldetectie
Observability
Protocolvertaling
  |
Veel MCP-servers
  |
API's / Bestanden / Databases / Diensten

Daarom beperken projecten zoals agentgateway en ContextForge zich niet langer tot MCP. Ze breiden zich ook uit richting modelroutering en agent-tot-agentprotocollen.

De gateway wordt de verbindings- en governancelaag tussen probabilistische AI-redenering en de systemen die daadwerkelijk werk kunnen uitvoeren.

Voor gebruikers die al experimenteren met AI-CLI-tools en codeeragents, zal dit waarschijnlijk steeds belangrijker worden. Een codeeragent met vijf tools is een applicatie. Tien agents die vijftig tools delen, vormen infrastructuur.

Eindoordeel

Kies Docker MCP Gateway als je lokale AI-stack al op Docker draait en je een praktische combinatie wilt van levenscyclusbeheer van MCP-servers, containerisolatie, inloggegevens, filtering en gecentraliseerde toegang.

Kies ToolHive als MCP gedeelde teaminfrastructuur wordt en je een register, runtime, gateway, beleidslaag en observabilitylaag nodig hebt in plaats van één proxy.

Kies agentgateway als je verwacht dat MCP-verkeer, modelverkeer en communicatie tussen agents samenkomen achter één AI-native gateway.

Kies MCPJungle als je de eenvoudigste weg wilt van verspreide MCP-clientconfiguraties naar één zelfgehost eindpunt.

Kies IBM ContextForge als je omgeving bestaande REST- of gRPC-API's bevat die naast MCP- en agentservices bruikbaar moeten worden.

Kies Microsoft MCP Gateway als je MCP-servervloot al in Kubernetes thuishoort en sessiebewuste routering en levenscyclusbeheer nodig heeft.

Kies OpenZiti MCP Gateway als agents op afstand toegang nodig hebben tot private MCP-tools zonder die services op openbare poorten beschikbaar te maken.

Kies MetaMCP als je grootste probleem niet de connectiviteit is, maar het aantal toolschema's dat context verbruikt en lokale modellen in verwarring brengt.

Kies Kong AI Gateway wanneer MCP een andere beheerde verkeersklasse moet worden binnen een bestaand op Kong gebaseerd API- en AI-platform.

Kies Supergateway wanneer je eenvoudig een overzichtelijke brug nodig hebt tussen stdio- en netwerktransports voor MCP.

De beste MCP-gateway is daarom niet per se degene met de langste lijst functies. Het is de kleinst mogelijke beheerlaag die het probleem oplost dat je agentstack daadwerkelijk heeft bereikt.

Veelgestelde vragen

Wat is een MCP-gateway?

Een MCP-gateway bevindt zich tussen AI-clients en MCP-servers. De gateway kan meerdere servers achter één eindpunt samenvoegen en mogelijkheden toevoegen zoals routering, authenticatie, toegangsbeheer, beheer van inloggegevens, filtering van tools, logging, observability, isolatie of transportconversie.

Heb ik een MCP-gateway nodig voor lokale AI?

Niet altijd. Een enkele AI-client die met één of twee MCP-servers is verbonden, werkt meestal prima zonder gateway. Gateways worden nuttiger wanneer meerdere clients meerdere MCP-servers delen en er behoefte is aan inloggegevens, beleidsregels, externe toegang of auditvereisten.

Wat is de beste MCP-gateway voor een homeserver?

Docker MCP Gateway en MCPJungle zijn twee van de beste startpunten. Docker MCP Gateway is geschikt voor gebruikers die al Docker draaien en biedt containerisolatie en levenscyclusbeheer. MCPJungle is aantrekkelijk wanneer het belangrijkste doel is om meerdere MCP-servers achter één overzichtelijk eindpunt te plaatsen.

Wat is het verschil tussen een MCP-gateway en een MCP-proxy?

Een proxy stuurt voornamelijk verkeer door en kan geselecteerde controles toevoegen. Een gateway fungeert doorgaans als een breder controleplatform met routering, identiteitsbeheer, beleid, aggregatie, referentiebeheer, discovery, observability of lifecyclemanagement. In de praktijk gebruiken projecten de termen vaak door elkaar.

Kan één MCP-gateway verbinding maken met meerdere AI-clients?

Ja. Een van de belangrijkste voordelen van een gateway is dat Claude, Codex, Cursor, Cline, OpenClaw of aangepaste agents een gedeelde MCP-infrastructuur kunnen hergebruiken, in plaats van elke MCP-server afzonderlijk in elke client te configureren.

Kan een MCP-gateway het tokengebruik verminderen?

Ja, als de gateway toolschema's filtert of abstraheert voordat ze het model bereiken. Docker MCP Gateway en ToolHive kunnen gecureerde toolsets beschikbaar maken, MCPJungle ondersteunt Tool Groups en MetaMCP reduceert een grote downstream-toolcatalogus tot een kleine set metatools.

Wat is de beste MCP-gateway voor lokale modellen?

Voor algemene lokale AI zijn Docker MCP Gateway en MCPJungle praktische opties. MetaMCP is vooral interessant wanneer kleinere lokale modellen moeite hebben met grote toolcatalogi, terwijl agentgateway relevant is wanneer self-hosted inferentieroutering en MCP-governance in dezelfde infrastructuurlaag moeten worden ondergebracht.

Kan ik een stdio-MCP-server via HTTP beschikbaar maken?

Ja. Supergateway kan stdio-MCP-servers omzetten naar Streamable HTTP-, SSE- of WebSocket-transporten. Andere gateways kunnen lokale stdio-servers ook overbruggen of proxy'en naar via het netwerk toegankelijke MCP-eindpunten.

Hoe krijg ik veilig toegang tot een MCP-server buiten mijn thuisnetwerk?

Gebruik een geauthenticeerd privénetwerk of een gateway die is ontworpen voor externe toegang, in plaats van simpelweg een openbare poort door te sturen. OpenZiti MCP Gateway is specifiek ontworpen om private MCP-services op afstand toegankelijk te maken via een zero-trust-overlay, zonder de server rechtstreeks op een openbaar IP-adres bloot te stellen.

Is een MCP-gateway een beveiligingsgrens?

Het kan er deel van uitmaken, maar alleen als bevoorrechte tooltoegang er daadwerkelijk doorheen loopt. Als dezelfde AI-agent ook onbeperkte shelltoegang, beheerdersreferenties, een schrijfbare Docker-socket of directe verbindingen heeft die de gateway omzeilen, bepaalt de gateway niet de werkelijke uitvoeringsgrens.

Moeten MCP-servers in Docker draaien?

Containers zijn nuttig voor het isoleren van afhankelijkheden van MCP-servers, bestandssysteemtoegang, netwerktoegang en resourcegebruik. Docker MCP Gateway en ToolHive maken containergebaseerde MCP-uitvoering tot een centraal onderdeel van hun aanpak, maar containers vervangen geen authenticatie, autorisatie, toolfiltering of audit.

Wat is het verschil tussen MetaMCP en een normale MCP-gateway?

Een conventionele gateway verzamelt en beheert doorgaans MCP-servers en stelt hun tools beschikbaar. MetaMCP gaat verder door grote downstream-toolcatalogi te verbergen achter een zeer kleine set metatools, waardoor de schemakosten in de modelcontext afnemen.