Stdio vs Streamable HTTP voor MCP: Wat er verandert wanneer je overstapt van lokale ontwikkeling naar enterprise-deployment

Stdio is prima voor de laptop van de ontwikkelaar. Streamable HTTP is wat enterprise-deployments daadwerkelijk nodig hebben. We lopen door beide transports — wire format, verbindingslifecycle, auth, audit en benchmarks — en laten zien wat er verandert wanneer een MCP-omgeving opschaalt voorbij één gebruiker.

Een vrijdagmiddag bij Northwind. Zes maanden na de uitrol van Cargo Copilot stelt de security lead van Northwind het engineeringteam een routineuze auditvraag: welke ontwikkelaars hebben de afgelopen 30 dagen de interne klantdata-MCP-tool aangeroepen, en tegen welke klant-ID's? Het team heeft elk JSON-RPC-bericht dat ooit door die tools is verzonden — in de stderr-logs van het lokale Cursor-proces van elke ontwikkelaar. Verspreid over vijftig laptops. Zonder gedeelde tijdstempelbron, zonder schema en zonder manier om deze te correleren. Het kost een week om de vraag te beantwoorden, en het antwoord is onvolledig. De oorzaak is geen nalatigheid. Het is de transportkeuze die ze zes maanden geleden hebben gemaakt.

Northwind begon waar de meeste teams beginnen: stdio MCP-servers, één per machine van de ontwikkelaar. Dat is de juiste standaard voor lokale experimenten — en de verkeerde standaard voor al het andere. Dit artikel legt uit waarom, met de details van de wire formats, de deployment-modellen en het migratiepad.

1. Stdio Transport: Hoe JSON-RPC 2.0 werkt over stdin/stdout

De MCP-transportspecificatie definieert stdio in één alinea: de client start de server als een subproces; de server leest JSON-RPC 2.0-berichten van stdin en schrijft antwoorden naar stdout. Elk bericht is één regel UTF-8-tekst, afgesloten met een newline. De server mag logs naar stderr schrijven; hij MAG NIETS naar stdout schrijven dat geen geldig MCP-bericht is.

Een enkele tool call van agent naar server is één regel JSON:

De framing-regels zijn eenvoudig maar onvermurwbaar. De MCP-specificatie vereist dat berichten op een enkele regel staan, dus conforme servers escapen alle interne newline-tekens als \n tijdens JSON-serialisatie. Wat de framing in productie daadwerkelijk breekt, is niet-JSON-vervuiling van stdout: een verdwaald print()-statement, een niet-opgevangen exception traceback, een debug-log die per ongeluk naar stdout is geleid in plaats van stderr, of een server die vergeet om stdout na elk bericht te flushen. In al deze gevallen ziet de client een ongeldig bericht of wacht hij voor altijd op een antwoord dat technisch gezien al geschreven is. Elke MCP SDK wordt geleverd met een stdio-transportimplementatie, precies om deze randgevallen het probleem van iemand anders te maken.

Wat stdio je geeft in ruil voor die beperkingen is procesisolatie. De agent beheert de lifecycle van de server: wanneer de agent afsluit, eist het besturingssysteem het proces weer op. Er is geen netwerk, geen auth-handshake, geen firewall-vraagstuk. Voor lokale ontwikkeling is dit precies wat je wilt.

2. Streamable HTTP Transport: Request-Response en SSE-modi

Streamable HTTP, geïntroduceerd in MCP-spec 2025-03-26 en behouden in de revisie van november 2025, vervangt het oudere HTTP+SSE-transport door een ontwerp met één endpoint. De server exposeert één URL (bijv. /mcp) die zowel POST als GET accepteert. Clients POSTEN JSON-RPC-berichten; servers reageren met een enkele JSON-body of upgraden naar een Server-Sent Events-stream voor langdurige calls. Er is geen afzonderlijk "events"-endpoint.

De client geeft aan wat hij kan accepteren; de server kiest de responsmodus. Hier is een tool call in HTTP-vorm:

Drie details zijn operationeel van belang. De Mcp-Session-Id-header bindt requests aan een sessie en wordt bij de initialisatie door de server toegewezen — deze blijft alleen behouden over pod-restarts heen als de server de sessiestatus externaliseert. De Accept-header is verplicht: volgens de spec MOETEN clients zowel application/json als text/event-stream vermelden, en een conforme server kan een ontbrekende of onvolledige Accept weigeren met HTTP 406 Not Acceptable (volgens HTTP-semantiek; 415 Unsupported Media Type geldt voor incompatibele Content-Type, niet voor Accept). En volgens de beveiligingssectie van de spec MOETEN servers de Origin-header bij elke verbinding valideren om DNS rebinding-aanvallen op lokaal gebonden servers te voorkomen — een normatieve vereiste, geen aanbeveling, met HTTP 403 Forbidden als voorgeschreven reactie op een ongeldige Origin.

3. Verbindingslifecycle: Proces-per-gebruiker vs Stateless HTTP

De twee transports modelleren verbindingen compleet anders, en dit is waar de operationele kloof ontstaat.

Voor een enkele ontwikkelaar die lokaal werkt, is het proces-per-verbinding-model van stdio een feature, geen bug — procesisolatie is gratis, en de koude start vindt eenmalig plaats wanneer de IDE opent. Het moment dat meer dan één gebruiker de server nodig heeft, wordt dat model de beperkende factor.

4. Multi-Tenancy: Waarom Stdio op schaal tegen de lamp loopt

De stdio-beperking die op enterprise-schaal breekpunten veroorzaakt, is eerder rekenkundig dan ingenieurstechnisch: typische stdio MCP-deployments draaien één proces per (gebruiker, server)-tuple, zonder ingebouwde deling tussen gebruikers. Sommige implementaties multiplexen meerdere tool-definities binnen één subproces, en een paar poolen subprocessen, maar het algemene deployment-patroon in de praktijk — en degene die in de officiële SDK's zit — is één proces per gebruiker per server.

Bij Northwind draaien 50 ontwikkelaars elk een IDE met acht gekoppelde MCP-servers. Dat zijn 400 stdio-processen tijdens piekuren, verdeeld over 50 laptops. Elk proces neemt geheugen in beslag (een Python MCP-server met een paar dependencies zit rond de 60–120 MB residentieel geheugen; een Node-server is vergelijkbaar), houdt file descriptors open en onderhoudt een actieve runtime die geblokkeerd is op stdin. De totale resource footprint is niet catastrofaal — 400 kleine processen vallen ruim binnen het budget van moderne hardware — maar de werkelijke kosten zijn operationeel in plaats van computationeel: het aantal processen fragmenteert de control plane.

Het moeilijkere probleem zijn servers met een gedeelde status. Stel je voor dat de interne Logistics API MCP-server bij het opstarten een customer-graph van 200 MB in het geheugen cached. Bij stdio laadt de machine van elke ontwikkelaar zijn eigen kopie. Bij Streamable HTTP houden twee pod-replica's de graph vast voor het hele bedrijf. Zelfde data, twee grootte-ordes minder geheugen in totaal, plus de cache is warm voor alle gebruikers omdat deze gedeeld wordt.

Het is de moeite waard om de andere kant van de medaille te benoemen. Het gedecentraliseerde model van stdio heeft reële voordelen die een ervaren infrastructure-team terecht zal aanhalen: sterke foutisolatie (de gecrashte server van de ene ontwikkelaar beïnvloedt niemand anders), geen afhankelijkheid van een gedeelde ingress, geen centrale auth-uitval die de hele omgeving platlegt, en minimale infrastructuur om te beheren. Voor kleine teams, zeer vertrouwde lokale workflows of air-gapped omgevingen kunnen die eigenschappen echt opwegen tegen de operationele voordelen van een centrale HTTP-laag. Het argument in dit artikel is niet dat stdio slecht is; het is dat de foutmodi die het afwentelt op de organisatie — gefreagmenteerde audit, gedistribueerde credentials, geen centrale rate limiting — precies de kop opsteken wanneer een omgeving groeit van "een paar power users" naar "gedeelde infrastructuur met compliance-verplichtingen."

Dit is de beperking die de documentatie van de TrueFoundry MCP Gateway expliciet maakt:

Een gateway heeft een HTTP-endpoint nodig dat hij kan onderscheppen. In de praktijk vereisen centrale gateway-deployments een HTTP-gerichte transportlaag, wat de reden is waarom stdio-servers typisch worden gewrapped met mcp-proxy (meer hierover in §8). De architecturale beslissing "welk transport leveren we mee" is daarom ook de beslissing "kunnen we hier een gateway voor zetten."

5. Auth Injection: Waar elk transport tekortschiet

Stdio heeft geen auth op transportlaagniveau. De MCP-specificatie is expliciet: stdio-implementaties moeten credentials uit de omgeving halen, niet uit een OAuth-flow. In de praktijk betekent dit dat de machine van elke ontwikkelaar API-keys bevat in shell-omgevingsvariabelen, in editor-instellingen of in een configuratiebestand dat op Slack wordt gedeeld wanneer iemand bij het team komt. De credentials bevinden zich waar het proces draait.

Streamable HTTP heeft de Authorization-header. Een gateway kan de inkomende credential valideren voordat het request de server bereikt, deze omwisselen voor een downstream-credential volgens het geconfigureerde uitgaande auth-model, en calls weigeren die niet aan het beleid voldoen — dit alles zonder de applicatiecode aan te raken. Het op headers gebaseerde model is wat centrale identiteit, RBAC en OAuth-token-brokering überhaupt mogelijk maakt.

De praktische impact is het meest zichtbaar tijdens het roteren van credentials. Bij stdio vereist een gelekt GitHub-token dat elke machine van een ontwikkelaar wordt opgespoord die het token gecached heeft — via editor-instellingen, dotfiles, wachtwoordbeheerders en de onvermijdelijke kopieën die ontwikkelaars maakten om elkaar te helpen. Bij HTTP is dezelfde rotatie één update bij de gateway, en elk volgend request gebruikt de nieuwe credential. De transportkeuze is niet de enige reden waarom centrale auth werkt, maar het is wel de keuze die het mogelijk maakt.

6. Audit Trails: Wat de Gateway wel en niet kan zien

Stdio mist een natuurlijk centraal onderscheppingspunt. Er is geen socket om af te tappen, geen proxy om tussen te plaatsen, geen header om te loggen — dus moet een gestructureerde audit out-of-band worden gereconstrueerd via lokale forwarders, stderr-collectors, eBPF-tracing of proces-supervisors die zijn gedeployed op elke host waar een server draait. Dat is te bouwen, maar het is een operationeel programma op zich, los van de applicatie. Het enige eersterangs verslag van wat er binnen een stdio MCP-sessie is gebeurd, is wat de server zelf naar stderr verkoos te schrijven — ongestructureerde, per-proces, onbetrouwbare tijdstempels, geen correlatie-ID, geen identiteit van de aanroeper. Voor een enkele ontwikkelaar die lokaal debugt, is dat genoeg. Voor een securityteam dat een incident over vijftig laptops heen moet reconstrueren, is dat het niet.

Streamable HTTP exposeert elke tool call op de HTTP-laag, waar een gateway deze structureel kan onderscheppen. Een minimaal audit-record van de TrueFoundry gateway ziet er ongeveer zo uit:

Het audit-record is geen logregel die de server verkoos uit te sturen. Het is metadata die de gateway op basis van de structuur genereert. Hetzelfde record bestaat voor elke tool call over alle MCP-servers in de omgeving heen, met een consistent schema, monotone tijdstempels en een identiteit die is gekoppeld aan de inkomende credential. Dat is de eigenschap waarmee het securityteam van Northwind de vraag op vrijdagmiddag in één query kan beantwoorden in plaats van in een week.

7. Latency Benchmarks: Sequentiële vs parallelle tool calls op beide transports

Op de laptop van de ontwikkelaar is stdio sneller per call. over een netwerk met een realistische belasting wint Streamable HTTP op de metrieken die meeschalen. Hier is de opbouw.

‍

De korte versie: stdio wint op latency bij een enkele call in het beste geval (warme start, dezelfde machine) en houdt het foutdomein klein. Wat HTTP inlevert op ruwe latency bij een enkele call, wint het terug in de operationele beheersing die enterprises op schaal meestal nodig hebben — replicatie, parallellisme via gelijktijdige handlers, centrale rate-limiting en observeerbaarheid op de gatewaylaag. En omdat de LLM-call die elke tool-aanroep omgeeft typisch honderden milliseconden duurt, is een HTTP-overhead van 5–10 ms zelden de dominante kostenpost in verhouding tot het werk dat wordt uitgevoerd.

8. Migratiegids: Een Stdio-server converteren naar Streamable HTTP

Migratie is een wissel op de transportlaag. De tools zelf — hun invoerschema's, hun handlers, hun afhankelijkheden — blijven ongewijzigd. Er zijn twee paden, afhankelijk van de vraag of je de broncode van de server beheert.

Pad A: wijzig het transport in je eigen server

Als je de MCP-server zelf hebt geschreven, is de wijziging ongeveer vijf regels. Met fastmcp is het verschil tussen transportmodi een enkel run()-argument:

Pad B: wrap een stdio-server met mcp-proxy

Veel open-source MCP-servers worden uitsluitend voor stdio geleverd — de officiële GitHub-, Slack- en filesystem-servers, plus de meeste community-opties. Voor deze servers raadt TrueFoundry aan ze te wrappen met mcp-proxy en ze te deployen als een reguliere service. De wrapper handelt HTTP af, start het stdio-kindproces en sluisst JSON-RPC tussen beide heen en weer. Vanuit het perspectief van de gateway is de geewrappte server niet te onderscheiden van een native HTTP-server.

De exacte flags hangen af van welke mcp-proxy-implementatie wordt gebruikt — de TypeScript-variant (punkpeye/mcp-proxy) accepteert --server stream zoals hier getoond; de Python-variant (sparfenyuk/mcp-proxy) gebruikt --transport streamablehttp met het gewrapte commando als een positioneel argument. Controleer in ieder geval de huidige upstream README voordat je een runbook oplevert, aangezien CLI-flags tussen releases kunnen wijzigen.

Eenmaal gewrapt, wordt de server op dezelfde manier geregistreerd bij de gateway als elke HTTP MCP-server — zie ons eerdere artikel over OAuth op de MCP-laag voor het configuratiemodel. Migratie is zelden een codeproject; het is een deployment-en-registratieproject.

9. Veelgestelde vragen

Is stdio verouderd (deprecated)?

Nee. Stdio is het juiste transport voor lokale ontwikkeling en voor elke configuratie waarbij de client en server dezelfde machine en één enkele gebruiker delen. De MCP-spec definieert beide transports als eersterangs. Wat verouderd is, is het oudere HTTP+SSE-transport (gescheiden endpoints voor POST en GET-SSE), dat is vervangen door Streamable HTTP.

Kan ik beide transports op dezelfde server draaien?

Ja. Met de meeste MCP SDK's kan een enkele server aan meerdere transports worden gebonden. Een veelvoorkomend patroon is stdio voor lokale dev en Streamable HTTP voor productie, geschakeld via een omgevingsvariabele of command-line flag. Tool-logica wordt gedeeld; alleen de transportinitialisatie verschilt.

Hoe zit het met Server-Sent Events (SSE) als een losstaand transport?

Het oudere HTTP+SSE-transport uit de spec van 2024-11-05 gebruikte twee endpoints — één voor POST-berichten, één voor de SSE-stream. Dit is officieel verouderd sinds de spec van 2025-03-26, hoewel servers het actief kunnen houden voor backwards compatibility met oudere clients. Nieuwe implementaties moeten zich richten op Streamable HTTP.

Voegt de gateway latency toe aan elke tool call?

Ja, maar de kosten zijn klein. Een gezonde gateway voegt een paar milliseconden toe op het cache-hit path (token-lookup + RBAC + JWT-verificatie). Vergeleken met de omliggende LLM-call (typisch honderden milliseconden tot seconden) en de downstream MCP-server, is de overhead zelden de dominante kostenpost. Zie ons eerdere artikel over OAuth op de MCP-laag voor de volledige latency-opbouw.

Hoe zit het met WebSockets?

Maakt geen deel uit van de huidige MCP-transportspecificatie. Streamable HTTP met SSE dekt de streaming-usecase af zonder dat er WebSocket-infrastructuur nodig is, wat moeilijker te loadbalancen en te beveiligen is dan gewone HTTP. De MCP-auteurs hebben bewust gekozen voor HTTP-semantiek.

Waar past TrueFoundry in dit plaatje?

De TrueFoundry MCP Gateway is een ingress uitsluitend voor Streamable HTTP gericht op MCP-servers binnen je enterprise. Stdio-servers bereiken de gateway via mcp-proxy-wrappers (zie §8). Eenmaal geregistreerd krijgt elke server een uniforme identiteit, RBAC, audit en OAuth-broker-laag op de gateway-tier, ongeacht hoe de upstream server oorspronkelijk is geïmplementeerd.

Neem de volgende stap

Als je MCP op een niet-triviale schaal draait, is de meest waardevolle oefening het inventariseren van elke MCP-server die actief in gebruik is, deze te markeren als uitsluitend stdio of HTTP-geschikt, en te beslissen welke het eerst worden overgezet. Stdio-only servers achter mcp-proxy plaatsen is een routinematig patroon; de migratie past meestal in een enkele sprint.

Begin hier: TrueFoundry MCP Gateway SDK usage docs. Of boek een enterprise-architectuurreview met ons team.

Verdere literatuur

Bronvermeldingen zijn overal inline gelinkt. De onderstaande lijst verzamelt alle URL's voor printbaarheid en ter bescherming tegen dode links.

• MCP Transports-specificatie (2025-11-25). https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
• MCP Transports-specificatie (2025-03-26, introduceerde Streamable HTTP). https://modelcontextprotocol.io/specification/2025-03-26/basic/transports
• TrueFoundry MCP Gateway overzicht. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-overview
• TrueFoundry MCP Gateway authenticatie en beveiliging. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-gateway-auth-security
• TrueFoundry MCP Gateway SDK-gebruik (streamable-http vereiste). https://docs.truefoundry.com/gateway/mcp-gateway-sdk-usage
• TrueFoundry: Binnenin de MCP-architectuur (mcp-proxy wrapper-richtlijnen). https://www.truefoundry.com/blog/inside-the-model-context-protocol-mcp-architecture-motivation-internal-usage
• JSON-RPC 2.0-specificatie. https://www.jsonrpc.org/specification
• AWS Lambda cold start benchmarks (Python/Node 200–400 ms). https://edgedelta.com/company/knowledge-center/aws-lambda-cold-start-cost
• mcp-proxy: stdio ↔ HTTP bridge (open source). https://github.com/sparfenyuk/mcp-proxy

Opmerking: Northwind Logistics is een fictief bedrijf dat is gebruikt om het ontwerp te verankeren in een concrete implementatie. Latency-cijfers in §7 zijn technische schattingen op basis van gepubliceerde component-benchmarks, geen gemeten TrueFoundry-productietelemetrie.

‍