Build vs Buy: Moet je je eigen MCP Gateway bouwen?

"We zouden dit gewoon zelf kunnen bouwen" is de duurste zin in platform engineering, en een MCP gateway nodigt daartoe uit, omdat de eerste versie echt eenvoudig is. Een reverse proxy die MCP-verkeer doorstuurt naar een backendserver is een middagje werk. Het werkt in de demo. Het stuurt de calls door. En het is ongeveer 10% van een gateway, wat meteen het probleem is, want de demo maakt de overige 90% onzichtbaar totdat je er gecommitteerd aan bent.

Dit artikel is de eerlijke build-versus-buy-analyse. Niet "kopen is altijd juist"—dat is niet waar, en er zijn echte gevallen waarin zelf bouwen correct is. Het doel is om de volledige omvang van "bouwen" zichtbaar te maken voordat je je eraan verbindt, de onderhoudstax te benoemen die de bouw overleeft, en je de criteria te geven om te bepalen aan welke kant van de lijn jouw situatie valt. Als je nog niet hebt besloten of je een open-source gateway zelf wilt hosten of een beheerde wilt kopen, is dat een gerelateerde afsplitsing; dit stuk gaat specifiek over bouwen vanaf nul versus kopen, en een overzicht van wat er beschikbaar is vind je in best MCP gateways vergeleken.

Ontdek wat het kopen van een MCP gateway je bespaart voordat je er een gaat bouwen. Boek een demo.

De ijsberg: wat "een proxy" verbergt

De reden waarom "we zouden dit kunnen bouwen" zo verleidelijk is, is dat het zichtbare deel echt eenvoudig is en het ondergedompelde deel echt groot is.

Boven de waterlijn bevindt zich de proxy: accepteer een verbinding van een client, stuur het MCP-verzoek door naar de juiste backendserver en retourneer de respons. Dat is het deel dat je in een middag kunt bouwen en in een demo kunt laten zien. Onder de waterlijn bevindt zich alles wat het een gateway maakt in plaats van een forwarder, en elk item onder de lijn is een project, geen functie.

OAuth, zowel two-legged (service-to-service) als three-legged (namens een gebruiker), per backendserver, met token management, refresh en de issuer-validation hardening die de huidige specificatie vereist. Een registry van welke servers bestaan, met levenscyclus: toevoegen, versiebeheer, uitfaseren. Access control die bepaalt welke gebruikers en teams welke servers en tools mogen bereiken, gekoppeld aan je identity provider. Tool discovery, zodat clients dynamisch kunnen opmaken wat beschikbaar is in plaats van het hard te codereen. Observability die kosten, tokens, latency en gebruik per verzoek vastlegt, getagd per aanroeper. Een audit trail die antwoord kan geven op "wie riep wat aan, en wanneer" over elke call. Guardrails voor PII, prompt injection en het lekken van secrets. En onder dit alles de on-call-rotatie, want een gateway in het request path van elke agent is tier-one infrastructuur vanaf de dag dat deze live gaat.

Dat is de eerlijke omvang. De proxy was het eenvoudige tiende deel. De overige negen tiende is wat het woord "gateway" daadwerkelijk inhoudt.

De componenten die je zou bouwen, met inspanning

Uiteengezet als een tabel, omdat het totaalbeeld het punt is.

Tel de "weken" eerlijk op en je zit op één tot twee engineerskwartalen om pariteit te bereiken met wat een gekochte gateway je op dag één geeft, en dat is het optimistische pad waarin niets misgaat en het team dit eerder heeft gedaan. De laatste rij heeft met een reden geen einddatum, wat ons brengt bij het deel dat tijdens het plannen gemakkelijk over het hoofd wordt gezien: de bouw heeft een finishlijn en het onderhoud niet. De componenten zelf worden vanuit het perspectief van de gebruiker beschreven in wat een MCP gateway is en wat een MCP registry is; ze zelf bouwen betekent dat je eigenaar bent van de onderdelen die in die artikelen als features worden beschreven.

De onderhoudstax: een specificatie die niet stil staat

De kosten die de meeste bouwbeslissingen doen kelderen, zijn niet de bouw zelf. Het is dat het Model Context Protocol jong is en snel verandert, en wat je ook bouwt, je onderhoudt het tegen een doel dat beweegt.

Kijk naar de herziening van 2026-07-28 als concreet voorbeeld. Het verklaarde Dynamic Client Registration verouderd ten gunste van Client ID Metadata Documents, wat betekent dat een gateway die DCR had geïmplementeerd nu een migratie voor de boeg heeft en een server-side metadata-fetch moet bouwen, met de SSRF-afhandeling die dat met zich meebrengt. Het maakte Streamable HTTP stateless, waarbij de initialize-handshake en Mcp-Session-Id werden uitgefaseerd, wat verandert hoe een gateway transport beëindigt en in-flight verzoeken afhandelt. Het verplaatste routing naar Mcp-Method- en Mcp-Name-headers, met een regel dat headers en body overeen moeten komen en dat afwijkingen moeten worden geweigerd, wat nieuwe logica is in het request path. Dat is één herziening. Het protocol zal opnieuw worden herzien, en elke keer heeft je in-house gateway een engineer nodig om het changelog te lezen, de operationele implicaties te begrijpen, ze te implementeren en ze uit te rollen zonder de agents te breken die er van afhankelijk zijn. De mechanica van het auth-model waar je achteraan zou lopen, wordt behandeld in MCP authenticatie, en de beveiligingsimplicaties van het verkeerd uitvoeren van die wijzigingen in MCP beveiligingsrisico's en best practices.

Dit is het verschil tussen een gekochte gateway en een gebouwde gateway dat niet naar voren komt in de initiële schatting. Wanneer je koopt, is spec churn het probleem van de leverancier: de clients die op de gateway zijn gericht veranderen niet, de gateway verandert, en de leverancier doet het leeswerk, de implementatie en het testen. Wanneer je bouwt, is spec churn een permanente claim op de tijd van je team, voor onbepaalde tijd, voor een component die niet jouw product is. Het is de belasting die je betaalt voor de rest van de levensduur van de gateway, en het is de reden waarom "we hebben het in een kwartaal gebouwd" zo vaak verandert in "we hebben permanent anderhalve persoon toegewezen om het up-to-date te houden."

Security patching hoort hier ook bij. Een gateway bevindt zich op de vertrouwensgrens en verwerkt onbetrouwbare invoer, waaronder de categorie tool-poisoning-aanvallen die worden behandeld in MCP tool poisoning en gateway verdediging. Wanneer er een kwetsbaarheid aan het licht komt in een dependency of in de protocolafhandeling, heeft een gebouwde gateway een snelle patch nodig van het team dat hem heeft gebouwd, die ook de enige mensen zijn die hem begrijpen. Dat betekent on-call plus security response, voor altijd, voor plumbing.

Zie hoe TrueFoundry de gateway levert waar je anders engineersmaanden aan zou besteden om hem te bouwen. Boek een demo.

Wanneer zelf bouwen de juiste keuze is

Zelf bouwen is niet altijd verkeerd. Er is een reële marge waarin het correct is, en het is de moeite waard om deze precies te benoemen, zodat de beslissing op de juiste gronden wordt genomen.

Bouw zelf wanneer je vereisten echt uniek zijn, wat betekent dat geen enkel product eraan voldoet en het gat essentieel is voor hoe je opereert, niet een voorkeur die je zou kunnen aanpassen. Dit komt zeldzamer voor dan teams denken, omdat de meeste "unieke" vereisten standaardvereisten blijken te zijn die lokaal zijn geformuleerd, maar het komt voor, en wanneer dat zo is, is een product dat niet aan de vereiste kan voldoen geen optie, ongeacht de andere voordelen.

Bouw zelf wanneer je een infrastructuurbedrijf bent en dit de kern is van wat je doet. Als je product AI-infrastructuur is, kan een gateway iets zijn dat je end-to-end moet bezitten omdat het deel uitmaakt van je eigen differentiatie, en de onderhoudstax is dan geen belasting, maar je business. Dezelfde logica is van toepassing als je van plan bent de gateway zelf als product uit te brengen: dan is bouwen geen overhead, maar hetgeen je verkoopt.

Bouw zelf wanneer je bewust hebt besloten om deze capaciteit in eigen beheer te nemen en er personeel voor hebt vrijgemaakt, met open ogen voor de bouw van één tot twee kwartalen en het permanente onderhoud, omdat het in eigen beheer hebben een strategische waarde voor je heeft die de kosten overstijgt. Het sleutelwoord is bewust. De foutmodus is niet het kiezen om te bouwen; het is het afglijden naar bouwen omdat de proxy eenvoudig was, zonder ooit de ondergedompelde negen tiende of de permanente tax door te rekenen.

Wanneer kopen wint

Voor bijna al het andere wint kopen, en de test is één enkele vraag: is een MCP gateway je differentiator of je afhankelijkheid?

Als de taak van je team is om agents, interne copilots, klantgerichte AI-functies en automatisering op te leveren, dan is de gateway infrastructuur waarvan die agents afhankelijk zijn, niet hetgeen dat je probeert te bouwen. Elk engineerskwartaal dat wordt besteed aan het bouwen ervan en elke vaste fractie die wordt besteed aan het onderhoud ervan, is tijd die niet wordt besteed aan de agents, die het werkelijke product zijn. Kopen zet die tijd weer om in productwerk en verplaatst spec churn van jouw probleem naar dat van de leverancier.

Kopen wint ook op de features die duur zijn om goed te bouwen en gevaarlijk om slecht te bouwen: het beveiligings- en compliance-oppervlak. SSO, SCIM, een verdedigbare audit trail en guardrails zijn standaarden die een gekochte gateway direct meelevert en die een gebouwde gateway moet construeren en vervolgens audit-ready moet houden. De kwestie van flexibiliteit in implementatie, vaak de reden waarom teams denken dat ze zelf moeten bouwen, wordt opgelost zonder te bouwen: een gateway die beschikbaar is als beheerde SaaS plus in-VPC, on-prem en air-gapped houdt het data plane in je netwerk, terwijl het toch een product blijft dat iemand anders onderhoudt, dus "we hebben het nodig in onze omgeving" is geen reden om het zelf te bouwen. Dat implementatiemodel is precies wat TrueFoundry biedt, en de argumentatie over datacontrole erachter wordt behandeld in enterprise MCP governance.

De scorecard

Plaats de beslissing op twee assen en deze wordt snel duidelijk.

Hoog op de differentiatie-as betekent dat het beheren van de gateway je een concurrentievoordeel oplevert, je een infra-bedrijf bent of dat je het verkoopt. Laag betekent dat het plumbing is die je echte product ondersteunt. De horizontale as is wat bouwen je kost in tijd en doorlopend onderhoud versus kopen. De aanbevelingszone is helder: bouw alleen wanneer de differentiatie hoog genoeg is om de kosten te rechtvaardigen; koop in alle andere gevallen, wat het grootste deel van het vlak beslaat.

Als een scorecard die je kunt invullen:

Als de meeste van je vinkjes in de rechterkolom terechtkomen—en voor teams wier product agents zijn in plaats van infrastructuur zal dat zo zijn—is kopen het antwoord, en is het bouwinstinct de illusie van de eenvoudige proxy die spreekt. Als ze links terechtkomen, bouw dan bewust en zorg voor de juiste bezetting.

Waar teams dit verkeerd inschatten

Ze schatten de proxy in en noemen het de gateway. De forwarder waar een middag aan gebouwd is verandert in "dit kunnen we bouwen", en de één tot twee kwartalen van auth, registry, access control, discovery, observability, audit en guardrails worden nooit gecategoriseerd. De schatting is voor het tiende deel dat zichtbaar is.

Ze vergeten dat de specificatie verandert. De bouw krijgt een finishlijn in de planning; het onderhoud krijgt helemaal geen regel. Dan komt een herziening in de stijl van 2026-07-28 en ontdekt het team dat het up-to-date houden van de gateway een permanente taak is, geen eenmalige inspanning.

Ze bouwen om "het moet in onze omgeving draaien" op te lossen. Dit is de meest vermijdbare fout. Flexibiliteit in implementatie is een reden om een gateway te kiezen die in-VPC, on-prem of air-gapped draait, niet een reden om vanaf nul te bouwen. Teams bouwen een gateway om gegevens in hun netwerk te houden en komen er nooit achter dat een gekochte gateway hetzelfde had kunnen doen.

Ze bouwen de proxy goed en de beveiliging slecht. De zichtbare onderdelen krijgen aandacht; het ondergedompelde beveiligingsoppervlak, prompt-injection- en tool-poisoning-verdedigingen, secret-detectie en een echte audit trail krijgen wat er overblijft. Een gateway met een solide proxy en zwakke guardrails is een valse schijn van controle in het request path van elke agent.

Ze vragen zich nooit af of het hun differentiator is. De beslissing wordt genomen op basis van "kunnen we" in plaats van "moeten we". Het team kan het bouwen; de vraag die er toe doet is of het bouwen ervan het product vooruithelpt, en voor de meeste teams die agents opleveren, leidt het er actief van af.

Conclusie

Het bouwinstinct voor een MCP gateway komt voort uit een terechte waarneming—de proxy is eenvoudig—en een onjuiste conclusie—dus is de gateway eenvoudig. De gateway is de negen tiende onder de waterlijn: auth per server, een registry, access control, discovery, observability, audit en guardrails, gebouwd tot pariteit in een kwartaal of twee en vervolgens voor altijd onderhouden tegen een protocol dat niet stil blijft staan. De onderhoudstax, niet de bouw, is wat de schatting mist, en het zijn de kosten die lopen gedurende de gehele levensduur van het systeem.

Bouw zelf wanneer de gateway echt je differentiator is: unieke vereisten, een infrastructuurbedrijf of een product dat je wilt verkopen. Koop wanneer het je afhankelijkheid is, wat voor teams wier product agents zijn bijna altijd het geval is, omdat elk kwartaal dat aan plumbing wordt besteed, een kwartaal is dat niet wordt besteed aan hetgeen je daadwerkelijk differentieert. En als de reden dat je zelf wilt bouwen is dat de gateway in jouw omgeving moet draaien, is dat een implementatiekeuze waaraan een gekochte gateway in-VPC, on-prem of air-gapped kan voldoen, geen reden om de bouw en de tax op je te nemen. Neem het besluit bewust, op basis van differentiatie en totale kosten, niet op basis van hoe eenvoudig de proxy eruitzag.

Lever agents op, geen protocol-plumbing. Boek een demo.