MCP Gateway vs MCP-servers rechtstreeks uitvoeren

Elk team dat het Model Context Protocol adopteert, begint op dezelfde manier. Een ontwikkelaar voegt een bestandssysteem-server en een GitHub-server toe aan Claude Desktop, bewerkt een JSON-configuratiebestand, plakt er een token in, en het werkt. Dit is de juiste manier om te starten. Het is snel, het heeft geen bewegende onderdelen en het leert het team wat MCP daadwerkelijk doet voordat iemand zich verbindt aan infrastructuur.

De vraag is niet of u daar moet beginnen. Het is wanneer u moet stoppen. Het directe model heeft een foutcurve die op kleine schaal onzichtbaar is en op middelgrote schaal meedogenloos, en de meeste teams bereiken de knik in die curve zonder het te merken, meestal rond het punt waar het tweede team dezelfde server wil gebruiken en niemand kan zeggen wie de credentials ervoor heeft. Deze post gaat over waar die knik zit, hoe u deze ziet aankomen en wat er daadwerkelijk verandert als u er een gateway tussen plaatst. Als u eerst de basissdefinitie wilt, behandelt wat een MCP gateway is de vorm van het geheel; hier richten we ons op de beslissing.

Groeit u uit uw directe MCP-verbindingen? Zie wat één gateway vervangt. Boek een demo.

De twee architecturen, concreet

"Direct" betekent dat elke client is geconfigureerd om te praten met elke server die hij nodig heeft. In Claude Desktop, Cursor, VS Code of een aangepaste agent is dat een configuratiebestand per client waarin elke server, het transport en de credentials staan vermeld. De client behoudt de verbinding en het geheim. Er is geen gedeelde laag. Als tien clients dezelfde server gebruiken, staan het adres en het token van die server op tien plaatsen.

Een gateway betekent dat elke client één keer is geconfigureerd, om met de gateway te praten. De gateway beheert het register van welke servers bestaan, beeindigt de verbinding met elke backend-server en beslist per verzoek of deze aanroeper deze tool mag bereiken. Clients beheren nooit backend-credentials; ze authenticeren bij de gateway, en de gateway authenticeert bij de servers. De topologie verandert van een mesh-netwerk in een ster.

Die afbeelding is het hele argument in één illustratie, maar de afbeelding zwakt het af, omdat de lijnen niet zomaar netwerkverbindingen zijn. Elke lijn in de mesh is ook een credential om te provisioneren, een configuratie-item om te onderhouden en een pad zonder audit. De ster vermindert niet alleen lijnen; het verandert wie eigenaar is van elk belang.

Waar de twee modellen verschillen, dimensie voor dimensie

De verschillen zijn niet gelijkmatig verdeeld. Sommige doen er op elke schaal toe; sommige steken pas boven een bepaalde drempel de kop op. Hier is de eerlijke weergave.

Lees de rijen "een server toevoegen" en "schalen" samen en de dynamiek wordt duidelijk. In het directe model vermenigvuldigt elke eenheid van groei het werk. In het gatewaymodel is groei optellend en blijven de kosten per item gelijk. Dat is het verschil tussen een model dat schaalt en een model dat louter functioneert.

Het uitgewerkte voorbeeld: 30 ontwikkelaars, 6 servers

Cijfers maken dit concreet. Neem een middelgroot platformteam: 30 ontwikkelaars, die elk een mix van clients gebruiken (sommige Claude Desktop, sommige Cursor, sommige een eigen agent), en 6 MCP-servers waarvan de organisatie wil dat iedereen ze kan gebruiken. Een GitHub-server, een Jira-server, een interne documentatieserver, een database-lees-server, een observability-server en een deployment-server.

Direct. Elke ontwikkelaar configureert elk van de 6 servers in elke client. Negeer de complicatie van meerdere clients en neem aan dat er één client per persoon is: dat zijn 30 × 6 = 180 configuratie-items, verspreid over 30 machines, handmatig onderhouden. Belangrijker nog: de drie servers die echte credentials nodig hebben (de database-lees-server, de deployment-server en de GitHub-server) hebben hun tokens nu elk op 30 laptops staan. Dat zijn 90 actieve credential-kopieën voor drie gevoelige systemen, die in platte-tekst-configuratiebestanden staan, zonder centraal overzicht van welke kopie waar staat.

Voer nu de werkzaamheden uit die daadwerkelijk plaatsvinden. Het token van de databaseserver wordt geroteerd: 30 ontwikkelaars moeten elk een bestand bewerken, en totdat de laatste dat doet, zijn sommige gebroken en gebruiken sommige een verouderd geheim. Een ontwikkelaar verlaat het bedrijf: iemand moet weten dat hun laptop kopieën van drie gevoelige tokens bevatte en ze elk intrekken, behalve dat er geen overzicht is dat dat zegt, dus in de praktijk doet niemand het, en lopen er drie credentials de deur uit. Een zevende server wordt toegevoegd: nog eens 30 configuratie-aanpassingen. Een security review vraagt "wie heeft afgelopen dinsdag de deployment-server aangeroepen": er is geen antwoord, omdat niets het centraal heeft gelogd.

Gateway. Elke ontwikkelaar configureert één endpoint: de gateway. Dat zijn 30 configuratie-items, en die veranderen bijna nooit, omdat hetgeen waar ze naar wijzen niet verplaatst. De 6 servers worden één keer geregistreerd, in het register van de gateway. De gevoelige credentials staan in de gateway, op nul laptops van ontwikkelaars. Tokenrotatie is één wijziging op één plek. De vertrekkende ontwikkelaar wordt verwijderd uit het toegangsbeheer van de gateway, en elk pad dat deze had wordt in één actie gesloten, met een audit-record van wat er was geopend. De zevende server is één registeritem, en verschijnt in de catalogus voor iedereen die er recht op heeft via dynamische discovery.

Het aantal configuraties daalt van 180 naar 30, maar dat is nog een onderschatting. Het getal dat er toe doet is het aantal credential-kopieën, dat daalt van 90 naar 0, en het aantal plaatsen waar een wijziging moet worden doorgevoerd, dat daalt van "elke getroffen laptop" naar "één". Het directe model faalde niet omdat 180 een groot getal is. Het faalde omdat elke operationele gebeurtenis (rotatie, offboarding, groei, audit) meeschaalde met de mesh.

Wanneer direct echt prima is

Hier is het deel dat de meeste gateway-leveranciers overslaan. Voor een grote en legitieme reeks situaties moet u geen gateway draaien, en zou het installeren ervan pure overhead zijn.

Draai servers rechtstreeks wanneer aan al het volgende wordt voldaan. Één ontwikkelaar, of een paar die geen servers delen. Één of twee servers. Lokale servers, die op dezelfde machine draaien als de client via stdio, geen remote servers die via het netwerk worden bereikt. Geen gedeelde credentials, omdat iedereen zijn eigen credentials gebruikt. Geen compliance- of auditvereiste, omdat het om experimenten of persoonlijke tooling gaat. Dit is de laptop-situatie, en voor de laptop-situatie voegt een gateway een hop, een afhankelijkheid en een te beheren onderdeel toe, in ruil voor het oplossen van problemen die u niet hebt.

De duidelijkste aanwijzing is het transport. Een server die lokaal draait via stdio, in het bezit van de ene persoon die hem gebruikt, is een proces op uw machine; dit inpakken in een gateway is als het plaatsen van een load balancer voor een script. Het moment dat een server remote is, bereikt via Streamable HTTP door meer dan één client, kantelt de berekening, omdat er nu een credential is dat reist, een verbinding die veel clients delen, en de vraag wie deze mag gebruiken; wat precies de reeks problemen is waarvoor een gateway bestaat. De MCP server hosting discussie gaat dieper in op het onderscheid tussen lokaal en remote en waarom het de echte architecturale waterscheiding is.

De beslisboom

Als u een enkele procedure wilt, is dit hem. Doorloop de vragen in volgorde; stop bij het eerste sterke signaal.

De boom bevat een eenvoudig idee: de gateway verdient zijn plek zodra een belang gedeeld wordt. Gedeeld over clients, gedeeld over mensen, gedeeld over het netwerk, of gedeeld met een auditor. Zolang alles privé is voor één ontwikkelaar op één machine, wint direct. Op het moment dat er iets wordt gedeeld, moet hetgeen dat het delen, auth, toegang, discovery en audit beheert, ergens staan, en dat "ergens" is de gateway.

Hier is dezelfde logica als een checklist die u kunt scoren. Tel uw "ja"-antwoorden.

Nul of één keer "ja" en u bevindt zich comfortabel in de zone van directe verbindingen; geniet van de eenvoud. Twee of drie en u bent bij de knik van de curve, waar een gateway zichzelf snel terugbetaalt. Vier of meer en u betaalt al de prijs van het niet hebben van een gateway, in de vorm van wildgroei van credentials en onbeantwoordbare auditvragen, of het nu op een dashboard zichtbaar is of niet.

Zie hoe TrueFoundry N-bij-M MCP-verbindingen terugbrengt tot één beheerd endpoint. Boek een demo.

Wat de gateway daadwerkelijk centraliseert

Het is de moeite waard om precies te zijn over wat er naar het centrum verhuist, omdat "een gateway" kan klinken als een vage proxy. Vier concrete zaken verhuizen.

Identiteit en auth. De gateway beeindigt OAuth naar de backend-servers, en verwerkt zowel two-legged (service-to-service) als three-legged (namens een gebruiker) flows, zodat clients één credential tonen aan de gateway en nooit backend-geheimen bevatten. De werking van deze flows wordt behandeld in MCP authentication; het punt hier is dat ze één keer plaatsvinden, bij het centrale controlepunt, in plaats van per client opnieuw te worden geïmplementeerd of gekopieerd.

Het register. In plaats van dat elke client een lijst met servers hardcodeert, beheert de gateway een gecureerd register van welke servers bestaan, en ontdekken clients tools dynamisch daaruit. Een server toevoegen of uitfaseren is een registeroperatie, geen wijziging in de hele vloot. Als het registerconcept nieuw voor u is, legt wat een MCP registry is het model uit.

Toegangsbeheer en guardrails. RBAC bepaalt welke gebruikers of teams welke servers en tools mogen bereiken, en guardrails voor zaken als PII en prompt-injectie worden uniform toegepast, omdat elk verzoek via één plek gaat. In het directe model dwingt elke server af wat hij toevallig afdwingt, op inconsistente wijze; in het gatewaymodel wordt beleid één keer geschreven. Het bredere controlemodel is uiteengezet in enterprise MCP governance.

Observability en audit. Elke call genereert een logbestand: wie, welke server, welke tool, wanneer, met welke latency en welk resultaat. Dat is het meest voorkomende ding waarvan teams ontdekken dat ze het niet kunnen doen in het directe model, en het lastigste om achteraf in te bouwen, omdat u geen calls kunt loggen die nooit via een gemeenschappelijk punt zijn gegaan.

Waar teams de mist in gaan

Ze installeren een gateway voor een opzet met één ontwikkelaar en één server. Overhead zonder rendement. Als u zich onder de eerste drempel bevindt, lost een gateway niets op en voegt het een afhankelijkheid toe. Begin direct, en stap over wanneer een signaal afgaat.

Ze blijven direct werken totdat er een credential lekt. De meest voorkomende en duurste fout. Het directe model heeft geen proces voor offboarding, dus wanneer iemand vertrekt met tokens op de laptop, of een configuratiebestand in een repository wordt gecommitted, is het incident het eerste moment dat iemand de wildgroei opmerkt. De 90 credential-kopieën waren al die tijd een risico; ze werden pas zichtbaar toen een ervan misbruikt werd.

Ze gaan er vanuit dat "we observability hebben" omdat elke server logt. Logs per server geven geen antwoord op overkoepelende vragen. "Welke gebruiker heeft deze week de dure tool op alle servers intensief gebruikt" is onbeantwoordbaar wanneer de logs op zes plaatsen staan met zes schema's en geen gedeelde identiteit. Gecentraliseerde observability is iets heel anders dan zes lokale logs.

Ze voegen de gateway toe maar laten een direct pad open. Als clients servers nog steeds rechtstreeks kunnen bereiken, zijn het toegangsbeheer en de audit van de gateway adviserend, niet afgedwongen. Een centraal controlepunt beheert alleen wat er verplicht doorheen wordt gestuurd. Het sluiten van het directe pad is wat de gateway verandert van een gemaksvoorziening in een beheersmaatregel.

Ze halen "stateless transport" en "geen infrastructuur nodig" door elkaar. Dat Streamable HTTP stateless is maakt het schalen van servers eenvoudig, maar het beheert geen credentials, discovery of audit. Dat zijn precies de zaken die de gateway bezit, en die verdwijnen niet omdat de kabel eenvoudiger is geworden.

Conclusie

De keuze tussen een gateway en directe verbindingen is niet ideologisch, en het is niet "gateways zijn voor enterprise, direct is voor hobbyisten". Het is een kwestie van delen. Zolang een server privé is voor één persoon op één machine, is een directe koppeling de eenvoudigere, betere oplossing, en is het grijpen naar een gateway voorbarig. Het moment dat een server wordt gedeeld, over clients, over mensen, of over het netwerk, moeten de kwesties die delen met zich meebrengt (auth, toegang, discovery en audit) ergens centraal staan, en die centrale plek is een gateway.

De valkuil is dat het directe model niet aankondigt wanneer het is opgehouden te werken. Het blijft functioneren terwijl de credential-kopieën zich opstapelen en het auditgat groter wordt, totdat een rotatie de helft van het team platlegt of iemand vertrekt met tokens die niemand heeft bijgehouden. De vier vragen (meer dan één client, gedeelde servers, remote servers, enige compliance-behoefte) zijn de manier om de knik te zien voordat u hem raakt. Tel uw ja's, en stap over wanneer de telling dat zegt, niet pas na het incident.

Stap over van verspreide MCP-servers naar één controlepunt. Boek een demo.