Hoe werkt MCP? Architectuur, tools en transports uitgelegd

Op de pagina "Wat is MCP?" lees je waarom het protocol bestaat: het vervangt maatwerkintegraties per app-per-tool door één standaard. Hier gaan we een laag dieper: hoe de architectuur in elkaar zit, welke bouwstenen een MCP server aanbiedt, hoe de verbinding technisch loopt en welke spec-versies er zijn. Technisch genoeg voor je developers, leesbaar genoeg voor een IT-manager die moet beoordelen wat er in het netwerk gebeurt.

Hoe zit de MCP-architectuur in elkaar?

MCP kent drie rollen die je uit elkaar moet houden. De host is de AI-applicatie zelf: Claude Desktop, VS Code, ChatGPT of je eigen agent. De host is de coördinator en de beveiligingslaag: hij beheert verbindingen, dwingt gebruikerstoestemming af en beslist wat er naar het taalmodel gaat. Binnen die host draait per aangesloten server één client — een protocolverbinding met een strikte 1:1-relatie naar precies één server. De MCP server is ten slotte het (lokale of remote) programma dat de daadwerkelijke functionaliteit levert: bestanden lezen, een CRM bevragen, een boeking aanmaken.

Rol	Wat is het?	Verantwoordelijk voor
Host	De AI-applicatie (Claude Desktop, VS Code, ChatGPT)	Beveiliging, toestemming, LLM-integratie, samenvoegen van context
Client	Protocolverbinding ín de host, 1:1 met één server	Capability-onderhandeling, berichtenverkeer, scheiding tussen servers
Server	Programma dat mogelijkheden aanbiedt	Tools, resources en prompts leveren

Schematisch, met twee aangesloten servers:

Host (bijv. Claude Desktop)
 ├── Client 1  ──stdio──────────▶  MCP server A (lokaal, bijv. bestanden)
 └── Client 2  ──Streamable HTTP─▶  MCP server B (remote, bijv. CRM)

Voor beslissers is één ontwerpprincipe uit de officiële architectuurspecificatie het belangrijkst: de volledige conversatiegeschiedenis blijft bij de host. Een MCP server ziet nooit het hele gesprek, krijgt alleen de context die voor zijn eigen aanroep nodig is, en kan niet in andere aangesloten servers kijken. Elke client vormt zo een beveiligingsgrens. Dat maakt de blootstelling per server beperkt en beoordeelbaar — al blijven er reële risico's zoals prompt injection via tool-resultaten, waarover meer op onze veiligheidspagina. Een tweede principe: servers horen extreem eenvoudig te bouwen te zijn, omdat de host de orkestratiecomplexiteit draagt. Dat verklaart waarom een werkende server in een tiental regels Python past, zoals we laten zien in onze bouwgids.

Welke bouwstenen biedt een MCP server aan?

Een server biedt zijn mogelijkheden aan via drie primitieven, elk met een andere "eigenaar":

Primitief	Wie bepaalt het gebruik?	Wat is het?
Tools	Het model	Uitvoerbare functies met een JSON Schema voor in- en uitvoer, bijv. "maak GitHub-issue aan" of "bevraag database". Sinds spec 2025-06-18 met gestructureerde output die tegen een outputSchema wordt gevalideerd.
Resources	De applicatie (host)	Read-only data met een URI: bestanden, databaserecords, documenten die de host aan de modelcontext kan toevoegen. Ondersteunt notificaties bij wijzigingen.
Prompts	De gebruiker	Voorgedefinieerde prompt-sjablonen die de gebruiker expliciet start — in clients als Claude Code en Gemini CLI zichtbaar als slash commands.

Het onderscheid is niet cosmetisch. Dat tools model-controlled zijn, betekent dat het taalmodel zelf besluit een functie aan te roepen (met goedkeuring van de gebruiker) — precies daarom stelt de host per tool toestemmingsregels in. Resources zijn juist passief: de host bepaalt welke data als context meegaat, het model kan er niet zelfstandig in grasduinen. En prompts liggen volledig bij de gebruiker. Wie een MCP server beoordeelt op risico, kijkt dus vooral naar de tools: dat is waar een AI-model daadwerkelijk acties kan uitvoeren.

Naast deze drie server-primitieven bestaat er verkeer de andere kant op. Het belangrijkste actieve client-primitief is elicitation (sinds spec 2025-06-18): een server kan halverwege een operatie extra invoer aan de gebruiker vragen via een schema-gebaseerd formulier, en sinds 2025-11-25 zelfs via een URL — handig voor een betaal- of loginflow. Drie oudere mechanismen — sampling (server vraagt het model van de client om een completion), roots (client geeft bestandsgrenzen door) en logging — worden per spec-revisie 2026-07-28 formeel gedeprecieerd, met directe LLM-API's, tool-parameters/configuratie en stderr/OpenTelemetry als aanbevolen vervangers. Je komt ze nog tegen in oudere tutorials en servers, maar bouw er geen nieuwe implementaties meer op.

Hoe verloopt de verbinding: stdio of Streamable HTTP?

De specificatie (revisie 2025-11-25) definieert twee standaardtransports; alle berichten zijn UTF-8 JSON-RPC.

stdio is het transport voor lokaal gebruik. De client start de server als subprocess op dezelfde machine en de communicatie loopt via stdin en stdout, regel voor regel. Er komt geen netwerk aan te pas — relevant voor compliance: bij een stdio-server verlaat er via het protocol zelf niets de laptop of server waarop hij draait. De spec zegt dat clients stdio should support whenever possible; het is het dominante model voor desktopgebruik zoals bestandstoegang en git. Eén klassieke valkuil voor bouwers: stdout is exclusief voor protocolberichten, dus een verdwaalde print() naar stdout breekt de server. Logregels horen op stderr.

Streamable HTTP is het transport voor remote servers, geïntroduceerd in spec-revisie 2025-03-26. De server biedt één endpoint aan (bijvoorbeeld https://example.com/mcp). De client POST elk JSON-RPC-bericht naar dat endpoint; de server antwoordt met een gewone JSON-response óf opent een text/event-stream om meerdere berichten te streamen. Verbindingen zijn hervatbaar: events dragen ID's, en een client die de verbinding verliest, herverbindt met Last-Event-ID waarna de server gemiste berichten opnieuw aflevert. De spec stelt bovendien beveiligingseisen: Origin-validatie tegen DNS-rebinding (403 bij ongeldige origin), localhost-servers binden aan 127.0.0.1, en verbindingen authenticeren. Vuistregel: stdio voor lokaal en persoonlijk gebruik, Streamable HTTP zodra iets remote, gedeeld of gehost moet zijn.

Is SSE nu deprecated of niet?

In de praktijk zie je de overgang terug bij leveranciers: Atlassian houdt zijn oude /v1/sse-endpoint bijvoorbeeld slechts tot 30 juni 2026 in de lucht. En de trend zet door: in de spec-revisie 2026-07-28 verdwijnt zelfs de noodzaak van langlopende SSE-streams voor server-naar-client-verzoeken; die verlopen dan via een request/retry-patroon (InputRequiredResult), waarmee het protocol verder opschuift naar gewoon stateless HTTP. Voor wie infrastructuur beheert is dat goed nieuws: geen sticky sessions of gedeelde sessie-stores meer achter de load balancer.

Hoe werkt authenticatie bij remote servers?

Remote MCP servers gebruiken OAuth 2.1, waarbij de MCP server optreedt als resource server en de MCP client als OAuth-client. De verplichte flow is Authorization Code met PKCE. De server publiceert via Protected Resource Metadata (RFC 9728) welke authorization servers hij vertrouwt, en clients moeten Resource Indicators (RFC 8707) gebruiken: het token is daarmee gebonden aan de specifieke server waarvoor het is uitgegeven, zodat een kwaadaardige server het niet elders kan hergebruiken. De revisie 2025-11-25 voegde discovery via OpenID Connect en Client ID Metadata Documents toe als aanbevolen registratiemechanisme; 2026-07-28 scherpt dit verder aan met onder meer RFC 9207-issuervalidatie. Het goede nieuws voor bouwers: frameworks en gateways nemen dit steeds vaker uit handen. Hoe je dit als organisatie inricht, lees je in de bouwgids en op de veiligheidspagina.

Welke spec-versies zijn er?

MCP-specversies zijn datums, geen versienummers. Dit is de stand per juli 2026, volgens de officiële changelogs op modelcontextprotocol.io:

Revisie	Status	Belangrijkste wijzigingen
2024-11-05	Vervangen	Eerste release: tools/resources/prompts, stdio en het oude HTTP+SSE-transport
2025-03-26	Vervangen	Streamable HTTP vervangt HTTP+SSE; OAuth 2.1-autorisatieframework; tool-annotaties
2025-06-18	Breed uitgerold	Structured tool output, elicitation, MCP servers als OAuth resource servers, RFC 8707 verplicht
2025-11-25	Huidig stabiel	OIDC-discovery, Client ID Metadata Documents, tasks (experimenteel), URL-elicitation, iconen
2026-07-28	Release candidate	Grootste revisie ooit: stateless core, extensions-framework (o.a. MCP Apps), auth-hardening, formeel deprecatiebeleid; definitief eind juli 2026

Nieuw sinds de 2026-cyclus is een formeel deprecatiebeleid: een feature doorloopt de stadia Active → Deprecated → Removed, met minimaal 12 maanden tussen deprecatie en verwijdering. Voor bedrijven betekent dit planbaarheid: als je vandaag een server draait op de stabiele revisie 2025-11-25, weet je dat gedeprecieerde onderdelen (zoals sampling, roots en logging) minstens een jaar blijven werken nadat de deprecatie formeel is. Welke versie een client en server samen gebruiken, wordt bij het opzetten van de verbinding onderhandeld via capability negotiation — zo evolueert het protocol zonder oudere implementaties te breken. Hoe wet- en regelgeving hierop aansluit, behandelen we op MCP en wetgeving.

Verder lezen

Veelgestelde vragen

Wat is het verschil tussen een MCP host, client en server?

De host is de AI-applicatie zelf (zoals Claude Desktop of VS Code), de client is de protocolverbinding binnen die host met een strikte 1:1-relatie naar één server, en de server is het programma dat tools, resources en prompts aanbiedt. De host bewaakt de beveiliging en houdt de volledige conversatie bij zich — servers zien die nooit.

Wat zijn tools, resources en prompts in MCP?

Tools zijn uitvoerbare functies die het AI-model zelf kan aanroepen, resources zijn read-only databronnen die de applicatie aan de context toevoegt, en prompts zijn kant-en-klare sjablonen die de gebruiker expliciet start, bijvoorbeeld als slash command.

Welke transports ondersteunt MCP?

Twee: stdio voor lokale servers (de client start de server als subprocess) en Streamable HTTP voor remote servers (één HTTP-endpoint, met optionele streaming via SSE). Het oude aparte HTTP+SSE-transport is sinds maart 2025 deprecated.

Is SSE deprecated in MCP?

Alleen het oude losstaande HTTP+SSE-transport uit 2024 is deprecated. SSE als techniek bestaat nog gewoon: Streamable HTTP gebruikt server-sent events intern als optioneel streamingmechanisme.

Hoe werkt authenticatie bij remote MCP servers?

Via OAuth 2.1 met de verplichte Authorization Code + PKCE-flow. De MCP server treedt op als resource server en clients moeten Resource Indicators (RFC 8707) gebruiken, zodat een token alleen geldig is voor de server waarvoor het is uitgegeven.

Welke versies van de MCP-specificatie zijn er?

Spec-versies zijn datums, geen versienummers: 2024-11-05 (eerste release), 2025-03-26 (Streamable HTTP, OAuth), 2025-06-18 (elicitation, structured output), 2025-11-25 (huidige stabiele versie) en 2026-07-28 (release candidate, definitief eind juli 2026).

Waarom worden sampling, roots en logging gedeprecieerd?

De spec-revisie 2026-07-28 markeert deze drie client-primitieven als Deprecated, met minimaal 12 maanden overgangstijd. De aanbevolen vervangers zijn directe LLM-provider-API's (voor sampling), tool-parameters of configuratie (voor roots) en stderr of OpenTelemetry (voor logging). Bouw er dus geen nieuwe servers meer op.

Kan een MCP server mijn hele conversatie meelezen?

Nee. Volgens de officiële architectuurspecificatie blijft de volledige conversatiegeschiedenis bij de host. Servers krijgen alleen de context die voor hun aanroep nodig is en kunnen ook niet in andere aangesloten servers kijken.

Laatst bijgewerkt: 2026-07-05