Streamable HTTP, Drie Tijdperken en het Huidige Wire-Contract

Het remote HTTP-transport van MCP heeft in ongeveer twee jaar tijd drie verschillende wire-tijdperkontwerpen doorlopen. Het HTTP+SSE-transport van 2024-11-05 gebruikte twee eindpunten en een langdurige stream; het is sinds 2025-03-26 verouderd (deprecated) en komt in aanmerking voor toekomstige verwijdering. Streamable HTTP verving het op 2025-03-26 door een enkel eindpunt — maar die eerste vorm bevatte nog steeds sessies op protocolniveau, een zelfstandige GET-stream, door de server geïnitieerde verzoeken op SSE en hervatbare streams. De revisie van 2026-07-28 heeft die mechanismen verwijderd. Wat overblijft is ongebruikelijk zuiver: elk JSON-RPC-bericht van de client wordt verzonden als een eigen POST, verzoekantwoorden zijn óf één JSON-object óf een SSE-stream afgestemd op dat specifieke verzoek, en geselecteerde verzoekmetadata wordt gespiegeld in headers, zodat tussenliggende systemen (intermediaries) het verkeer kunnen routen en inspecteren zonder de body te hoeven parseen. Die laatste ontwerpbeslissing is er een die nauwkeurige bestudering waard is.

Een load balancer routeert op basis van een header terwijl de server uitvoert op basis van de body, en die twee komen niet overeen. Dat is geen hypothetisch scenario in deze specificatie — het is de expliciet genoemde reden waarom er een volledige validatieregel bestaat. Het transport van 2026-07-28 houdt expliciet rekening met tussenliggende systemen tussen client en server, en een groot deel van het nieuwe headercontract wordt pas logisch als u het op die manier leest.

1. Drie Tijdperken

2024-11-05 — HTTP+SSE. Twee eindpunten. De client stuurde een GET om een SSE-stream te openen, waarvan het eerste event een endpoint-event was dat de client vertelde waar de POST naartoe gestuurd moest worden. Alles wat door de server werd geïnitieerd, kwam binnen via de langdurige stream. Verouderd (deprecated) sinds 2025-03-26 onder het beleid voor de levenscyclus van functies, waarbij nieuwe implementaties wordt afgeraden dit over te nemen.

2025-03-26 tot en met 2025-11-25 — Streamable HTTP, eerste vorm. Één enkel MCP-eindpunt, wat de eerdere belangrijke vereenvoudiging was. Maar vier mechanismen hielden het stateful: servers konden een sessie toewijzen via een Mcp-Session-Id-header, beëindigd met een HTTP DELETE; clients konden een zelfstandige SSE-stream openen met GET om door de server geïnitieerde berichten te ontvangen; servers konden JSON-RPC-verzoeken sturen op SSE-streams; en streams waren hervatbaar via Last-Event-ID.

2026-07-28 — de huidige vorm. Geen van die vier mechanismen is overgebleven. De revisienotities vermelden de verwijderingen duidelijk: het GET-streameindpunt en sessies op protocolniveau zijn verdwenen, en de onderstaande secties voegen eraan toe dat streams niet hervatbaar zijn en dat servers geen onafhankelijke verzoeken op een stream mogen sturen.

Een server die alleen de huidige revisie implementeert, verwerkt ouder verkeer met gespecificeerd gedrag: GET of DELETE naar het MCP-eindpunt krijgt 405 Method Not Allowed; een Mcp-Session-Id-header wordt genegeerd en er wordt geen sessie-id gegenereerd of geretourneerd; een Last-Event-ID-header wordt genegeerd.

2. Het Wire-Protocol

De server stelt één HTTP-eindpuntpad beschikbaar — het MCP-eindpunt — dat POST ondersteunt. De beveiligingsbasislijn van het transport is van belang vóór enige wire-optimalisatie: servers moeten de Origin-header op binnenkomende verbindingen valideren en 403 retourneren bij een aanwezige maar ongeldige origin; lokaal draaiende servers moeten binden aan localhost in plaats van alle interfaces; en servers moeten verbindingen authenticeren. Die vereisten bestaan om de risico's van DNS-rebinding en onbevoegde toegang te verkleinen.

Verzenden. Elk JSON-RPC-bericht van de client is een op zichzelf staande POST. De client moet een Accept-header opnemen waarin zowel application/json als text/event-stream worden vermeld, en de body moet een enkel JSON-RPC-verzoek of notificatie zijn. Clients mogen geen JSON-RPC-antwoorden sturen. Eén subtiliteit is belangrijk voor implementeerders: hoewel het transport definieert hoe een notificatie-POST zich gedraagt, definieert het kernprotocol van 2026-07-28 geen client-naar-server notificaties over Streamable HTTP en definieert het geen metadata-headervereisten voor notificatie-POST's.

Notificaties. Als de server er een accepteert, retourneert deze 202 Accepted zonder body; als dat niet kan, een HTTP-foutstatus, optioneel voorzien van een JSON-RPC-foutantwoord zonder id.

Verzoeken. De server retourneert óf Content-Type: application/json met een enkel JSON-object, óf Content-Type: text/event-stream met een SSE-stream afgestemd op dat specifieke verzoek. De client moet beide ondersteunen — een server kiest per verzoek, dus een client die slechts één van beide afhandelt, zal onvoorspelbaar vastlopen.

Wat er over een responsestream reist. De server kan notificaties sturen die betrekking hebben op het oorspronkelijke verzoek — voortgangs- en logberichten — voordat het definitieve antwoord wordt gegeven, en het definitieve antwoord moet de stream beëindigen. De server mag er geen onafhankelijke JSON-RPC-verzoeken op sturen. Dit is de expliciete breuk met eerdere revisies.

Annulering. Het sluiten van de SSE-responsestream moet door de server worden behandeld als een annulering van dat verzoek, en omdat elk verzoek zijn eigen stream heeft, is de verbreking ondubbelzinnig. De annuleringsnotificatie van het kernprotocol wordt alleen gebruikt op stdio; op dit transport is er geen annuleringsbericht en wordt er ook geen verwacht.

3. Waar Door de Server Geïnitieerd Werk Naartoe is Verplaatst

Twee zaken vereisten voorheen een kanaal van server naar client, en deze zijn gesplitst in verschillende mechanismen.

De client om iets vragen — sampling, elicitation, roots — is nu ingebed in resultaten als invoerverzoeken onder het Multi Round-Trip Requests-patroon. De server retourneert een InputRequiredResult met daarin inputRequests; de client verzamelt wat er gevraagd is en voert de oorspronkelijke aanroep opnieuw uit met overeenkomende inputResponses. Het is een tweede POST, geen push.

Langdurige wijzigingsnotificaties — wijzigingen in de toollijst, bronupdates — worden verkregen door een subscriptions/listen-verzoek te sturen waarvan de respons zelf een SSE-stream is die open blijft en alleen de notificatietypes levert waarvoor de client heeft gekozen. Verzoekspecifieke notificaties zoals voortgang verschijnen daar niet; die stromen alleen op de stream van het verzoek waartoe ze behoren.

Die scheiding is strakker dan het klinkt. De gestandaardiseerde langdurige notificatiestream bestaat omdat de client erom heeft gevraagd, en de inhoud ervan wordt gefilterd door de eigen subscriptie van de client. Werk over meerdere round-trips kan stateless blijven op de MCP-transportlaag, omdat de server de benodigde context kan coderen in requestState en de client die opake waarde bij een herhaalde poging opnieuw meestuurt.

4. Twee Details Die Problemeerbaar Zijn Achter een Proxy

De specificatie bevat twee operationele opmerkingen die bestaan omdat SSE en reverse proxies een moeilijke relatie hebben.

Buffering. Bij het initialiseren van een SSE-stream moeten servers X-Accel-Buffering: no opnemen. Dit instrueert reverse proxies zoals nginx om responsbuffering uit te schakelen. Zonder dit kan een proxy berichten verzamelen voordat ze worden doorgestuurd — wat latentie introduceert en het doel van streaming tenietdoet. Als gestreamde voortgangsupdates aan het einde in één klomp binnenkomen, is responsbuffering een van de eerste gedragingen van tussenliggende systemen die moet worden gecontroleerd.

Keep-alives. Voor langdurige streams, met name de subscriptions/listen-respons, worden servers aangemoedigd om periodiek een SSE-commentaarregel uit te zenden — een regel die begint met een dubbele punt — als keep-alive, zodat tussenliggende systemen en idle timeouts een stille verbinding niet sluiten. Volgens de SSE-specificatie bevat een commentaarregel geen eventdata, en moeten clients dergelijke regels negeren in plaats van ze als ongeldig te behandelen.

5. Het Headercontract

Dit is het gedeelte dat het transport echt anders maakt dan een conventie voor JSON-RPC-over-HTTP, en de specificatie vermeldt het doel ervan rechtstreeks: het transport spiegelt geselecteerde JSON-RPC-bodyvelden naar HTTP-headers, zodat tussenliggende systemen — load balancers, gateways, observability-tools — verzoeken kunnen routen en inspecteren zonder de body te parseen.

MCP-Protocol-Version — verplicht bij elke POST, en de waarde moet overeenkomen met de protocolversie die in de _meta van de body staat. Een mismatch wordt geweigerd met 400 Bad Request en een HeaderMismatch-fout. Een versie die de server niet heeft geïmplementeerd krijgt 400 met een foutmelding waarin de versies worden vermeld die wel worden ondersteund. Een niet-geïmplementeerde methode krijgt 404 met JSON-RPC -32601, wat het onderscheidt van de 404 van een legacy server.

Mcp-Method — spiegelt method. Verplicht bij alle JSON-RPC-verzoeken.

Mcp-Name — spiegelt params.name of params.uri. Verplicht voor tools/call, resources/read en prompts/get.

Voor JSON-RPC-verzoeken zijn die standaard verzoekheaders verplicht voor naleving binnen de bovenstaande scopes. Notificatie-POST's zijn een apart grensgeval: deze revisie definieert de transportmechanica ervan, maar niet de vereisten voor metadata-headers. Een minimaal conform tools/call-verzoek ziet er op de wire als volgt uit:

Servers kunnen verder gaan en specifieke toolparameters aanwijzen die moeten worden gespiegeld, met behulp van een x-mcp-header-extensie in het schema van de parameter, wat leidt tot headers met de naam Mcp-Param-{Name}. Een server die een region-parameter annoteert, krijgt Mcp-Param-Region: us-west1 naast de body — wat exact de vorm is die een router nodig heeft om een query naar de juiste regionale backend te sturen zonder de payload te lezen.

De beperkingen op die extensie zijn streng en goed om te weten voordat u eromheen ontwerpt. Waarden mogen niet leeg zijn, moeten overeenkomen met de HTTP-tokensyntaxis, mogen geen besturingstekens bevatten en moeten hoofdletterongevoelig uniek zijn binnen het schema. Alleen primitieve types zijn toegestaan — string, boolean en integer, waarbij number expliciet is uitgesloten. En de geannoteerde eigenschap moet statisch bereikbaar zijn vanaf de schemaroot via een keten die uitsluitend bestaat uit properties-sleutels: niet via array-sleutelwoorden, niet via oneOf, anyOf, allOf of not, niet via voorwaarden, en niet via $ref. Nesting van objecten is prima, zolang elke stap een properties-sleutel is. Een annotatie op een andere plek maakt de tooldefinitie ongeldig, en een conforme client moet die tool uitsluiten van tools/list terwijl er een waarschuwing wordt gelogd — zodat één verkeerd gevormde definitie de rest niet uitschakelt.

Waarden die niet veilig als ASCII kunnen worden weergegeven, worden met Base64 gecodeerd binnen een sentinel, =?base64?...?=, en dezelfde codering geldt voor Mcp-Name. Een net detail: een gewone ASCII-waarde die toevallig op de sentinel lijkt, moet ook worden gecodeerd om dubbelzinnigheid te voorkomen.

6. Waarom een Mismatch een Fout is

Servers die de verzoek-body verwerken, moeten verzoeken weigeren waarbij de headerwaarden niet overeenkomen met de bijbehorende bodywaarden, onder retournering van 400 met JSON-RPC-fout -32020. De specificatie geeft de reden expliciet aan, en het is een beveiligingsargument in plaats van een cosmetische keuze: dit voorkomt kwetsbaarheden wanneer verschillende componenten in het netwerk op verschillende bronnen van de waarheid vertrouwen — een load balancer die routeert op de headerwaarde terwijl de MCP-server uitvoert op basis van de bodywaarde.

Lees dat als een dreigingsmodel. Als een tussenliggend systeem een beslissing neemt op basis van een header en de server handelt op basis van een body die iets anders zegt, dan kan een client die deze anders instelt een gesplitste bron-van-waarheid-conditie veroorzaken — bijvoorbeeld routing of beleid geëvalueerd tegen de ene waarde terwijl de uitvoering een andere gebruikt. Verplichte validatie aan de serverzijde sluit deze klasse van mismatches uit voor de huidige revisie, en gecodeerde waarden moeten vóór vergelijking worden gedecodeerd.

7. Wat Dit Betekent voor een Gateway

Het komt zelden voor dat een protocol specificeert wat het tussenliggende onderdeel moet doen. Omdat dit protocol dat wel doet, is de koppeling ongebruikelijk direct.

Routen zonder te parseen. Mcp-Method en Mcp-Name betekenen dat een proxy alleen aan de headers kan zien of het om een tool-call of een resource-read gaat, en om welke tool het gaat. Dat is het verschil tussen een MCP-bewuste laag en een laag die elke payload moet deserialiseren om een beslissing te nemen (MCP-overzicht).

Tool-identiteit tonen aan een autorisatielaag zonder body te parseen. Een conform tools/call-verzoek bevat de toolnaam in Mcp-Name. Dat geeft een MCP-bewust tussenliggend systeem een door het protocol gedefinieerde invoer die het kan gebruiken bij het toepassen van beleid per tool; authenticatie en autorisatie moeten nog steeds worden afgedwongen door de gateway/server in plaats van te worden afgeleid uit de header zelf (MCP-documentatie over authenticatie en beveiliging).

Rate-limiten per tool of tenant. De specificatie noemt rate-limiting per tenant als een beoogd gebruik van gespiegelde headers door tussenliggende systemen, met de controle van de versie als veiligheidsvoorwaarde (rate-limiting).

Observeerbaarheid met nuttige dimensies. Methode- en toolnaam beschikbaar hebben zonder de body te parseen is precies wat telemetrie per tool nodig heeft, en het sluit aan bij de tool-call-conventies die ontstaan in de telemetriestandaarden (documentatie over analytics en tracing).

MCP-sessie-affiniteit verwijderen uit de transportlaag. Nu sessies op protocolniveau zijn verwijderd en responsestreams zijn afgestemd op individuele verzoeken, vereist het MCP-transport geen sticky routing of een gedeelde MCP-sessie-store meer. Applicaties kunnen nog steeds duurzame status behouden achter expliciete handles of gedeelde stores, dus "stateless transport" mag niet worden gelezen als "stateless applicatie." Voor achtergrondinformatie over de eerdere transportvorm van 2025, zie onze vergelijking tussen stdio en Streamable HTTP; algemene gateway-distributiepatronen worden besproken in failover en load balancing.

Één verplichting werkt de andere kant op, en geldt voor alles wat zich in het pad bevindt. Een tussenliggend systeem dat een Mcp-Param-{Name}-header niet herkent, moet deze doorsturen en anders negeren. Het verwijderen van onbekende headers — een gebruikelijke standaardinstelling in geharde proxies — zal conforme servers die deze verwachten, verstoren.

Waar een agent harness past. Het transport heeft nog steeds een aanroeper nodig die beslist wanneer een tool moet worden aangeroepen. TrueForge, het open-source agent harness van TrueFoundry, voert die uitvoeringslus uit over modelaanroepen, remote MCP-tools, skills, sandboxing, goedkeuringen, contextbeheer en sessiestatus. De MCP-connector daarvan ondersteunt remote servers met header-authenticatie of OAuth, inclusief een autorisatiepauze in de chat wanneer een gebruiker nog geen server heeft verbonden. Dat maakt de scheiding helder: TrueForge orchestreert de agent-stap; Streamable HTTP definieert het wire-contract tussen client en server; en een TrueFoundry MCP Gateway kan toolverkeer beheren dat bewust via de gateway wordt gerouteerd. Geen van die lagen vervangt de andere.

8. Een Inzetbare Houding

Als u MCP-servers beheert, valideer dan Origin, authenticeer verbindingen en bind lokale servers behoudend voordat u zich zorgen maakt over de afwerking van de streaming. Verzend vervolgens X-Accel-Buffering: no op SSE-responsen en keep-alive-commentaren op langdurige streams; buffering en idle timeouts kunnen zich voordoen als applicatielatentie of streaming-fouten. Valideer de overeenstemming tussen header en body in plaats van op een van beide afzonderlijk te vertrouwen, en decodeer sentinel-gecodeerde waarden vóór de vergelijking. Retourneer voor verkeer van eerdere Streamable HTTP-revisies het gespecificeerde compatibiliteitsgedrag — 405 op GET en DELETE, en negeer sessie- en event-id-headers — zodat oudere clients voorspelbaar mislukken of zich aanpassen.

Als u een tussenliggend systeem in het pad beheert, stuur dan onbekende Mcp-Param-*-headers door, controleer de protocolversie voordat u gespiegelde headers als gezaghebbend beschouwt, en maak gebruik van hetgeen waarvoor het spiegelen is gebouwd: routing, beleidsinvoer, rate-limiting en telemetrie gekoppeld aan methode- en toolnaam zonder elke payload te hoeven deserialiseren. De header biedt metadata; uw identiteits- en autorisatielaag bepaalt nog steeds of de aanroeper de actie mag uitvoeren.

Als u een client schrijft, ondersteun dan beide respons-content-types, behandel SSE-commentaarregels als negeerbaar, en volg de fallback-sequentie — probeer een modern verzoek, en inspecteer bij een 400 de body voordat u conclusies trekt, aangezien moderne servers ook 400 retourneren voor niet-ondersteunde versies en header-validatiefouten. Een herkende moderne fout betekent opnieuw proberen in plaats van terugvallen op een oudere methode.

9. Wat het Protocol Wel—en Niet—Oplost

Het transport van 2026-07-28 vereenvoudigt het wire-contract; het bepaalt niet de bedrijfslogica van de agent. Het verwijdert MCP-sessie-affiniteit, definieert hoe verzoekspecifieke streaming en retries werken, en geeft tussenliggende systemen gevalideerde metadata die ze kunnen gebruiken voor routing en beleidsinvoer. Het kiest niet welke tool een agent moet aanroepen, verleent de aanroeper geen toestemming om die tool te gebruiken, definieert geen goedkeuringsbeleid, slaat geen applicatiegeheugen op en bewijst niet dat een stroomafwaarts neveneffect geautoriseerd was door het systeem van overdracht.

Die verantwoordelijkheden behoren toe aan aangrenzende lagen. Een agent runtime zoals TrueForge beheert de uitvoeringslus en kan MCP-connectors, goedkeuringen, context en sessiestatus beheren. Een TrueFoundry MCP Gateway kan authenticatie, autorisatie, tooltoegang en observeerbaarheid centraliseren voor verkeer dat erdoorheen wordt gerouteerd. De MCP-server en de stroomafwaartse applicatie blijven eigenaar van hun eigen zakelijke autorisatie en effecten. Het expliciet houden van die grenzen is nuttiger dan het behandelen van een schoner transport als een compleet agent-beveiligingsmodel.

Ten slotte beschrijft dit artikel één revisie van een snel veranderende specificatie. Vereistenniveaus hier zijn afkomstig uit de tekst van 2026-07-28, echte clients en servers kunnen achterlopen op revisies, en de specificatie blijft gezaghebbend boven elke samenvatting. Dit artikel beweert evenmin dat een specifieke geïmplementeerde TrueFoundry Gateway-release intern elke gespiegelde header van 2026-07-28 gebruikt.

Referenties

• Model Context Protocol — Streamable HTTP transport-specificatie (2026-07-28), de bron voor transportmechanica, beveiligingsbasislijn, verzoekmetadata, validatie en compatibiliteitsregels die hier worden beschreven.
• Model Context Protocol — 2026-07-28 changelog, en de 2025-11-25 transportrevisie voor de eerdere vorm.
• Model Context Protocol — Multi Round-Trip Requests en subscriptions.
• TrueFoundry — stdio vs. Streamable HTTP — eerdere transportcontext; MCP-authenticatie en -beveiliging; rate limiting; analytics.
• TrueForge — open-source agent harness en MCP-serverinstelling, met documentatie over remote MCP-connectors met header-auth of OAuth, in-chat autorisatie, goedkeuringen, contextbeheer en permanente sessies.

Werking, vereisteniveaus, headernamen, foutcodes, compatibiliteitsregels en MRTR-statusbeveiligingsvereisten zijn geparafraseerd uit de gekoppelde specificatietekst van 2026-07-28; het voorbeeldverzoek is aangepast uit de illustratie van de specificatie zelf. Het remote HTTP wire-ontwerp van MCP is ingrijpend veranderd over drie tijdperken, en de specificatie is leidend boven deze samenvatting. TrueFoundry-productclaims zijn beperkt tot functionaliteiten die zijn gedocumenteerd op de gekoppelde huidige pagina's; dit bericht beweert niet dat een specifieke geïmplementeerde gateway-versie intern elke gespiegelde header van 2026-07-28 gebruikt.

‍