MCP-architectuur: volledige technische uitleg met diagrammen

MCP-architectuur is de fundamentele set componenten en communicatieregels die MCP (Model Context Protocol) mogelijk maken. MCP is een opensourcestandaard en MCP-architectuur is de onderliggende infrastructuur waarop deze draait.

Elke MCP-architectuur bevat drie kerncomponenten en is daaromheen opgebouwd: een host, een client en een server. Het communicatieframework van MCP wordt vaak beschreven als bestaande uit een datalaag en een transportlaag. De datalaag is de set regels voor de opmaak van berichten (MCP-verzoeken worden verzonden in JSON-RPC 2.0). De transportlaag vervoert die berichten en gebruikt Streaming HTTP voor externe verbindingen.

MCP-architectuur is een serverframework dat het Model Context Protocol implementeert, een open standaard voor het verbinden van AI-modellen met tools, resources zoals databases, en prompts die de invoercontext uitbreiden. Deze worden samen “primitieven” genoemd. Uiteindelijk stelt MCP-architectuur LLM's in staat om te ontdekken welke tools beschikbaar zijn en workflows uit te voeren, zonder dat er regelmatig updates aan de clientzijde nodig zijn.

Diagram van MCP-architectuur: een AI-applicatie wisselt verzoeken uit met een MCP-server, die tools, resources en prompts levert.

Sinds de introductie door Anthropic wordt MCP-architectuur veel gebruikt in AI-workflows. Dat komt grotendeels doordat het onderhoudsintensievere systemen vervangt, zoals systemen die zijn opgebouwd rond meerdere API-verbindingen, zonder in te leveren op prestaties. Omdat alle beschikbare functionaliteit achter de MCP-server zit, is er maar één verbinding nodig en zijn updates en toevoegingen direct beschikbaar voor de clientapplicatie.

MCP biedt LLM's een manier om de tools, prompts en resources te ontdekken en aan te roepen die voor hen beschikbaar zijn, op het lokale systeem van de hostapplicatie of bij een externe provider.

Bij tools, die toegang bieden tot externe functionaliteit, houdt ontdekking in dat de host een tools/list-aanroep naar de MCP-server doet om te achterhalen welke tools beschikbaar zijn. De LLM (of in sommige gevallen de host) kan vervolgens de beschrijvingen van de beschikbare tools lezen en ze waar nodig aanvragen. Prompts en resources gebruiken een vergelijkbaar proces.

Diagram van de componenten van MCP-architectuur: een host met een LLM, een orchestrator en een client maakt in twee stappen verbinding met een MCP-server, eerst ontdekking en daarna verzoeken, en de MCP-server stelt tools, resources en prompts beschikbaar.

Dit staat in contrast met op maat gemaakte, API-gebaseerde architectuur, die lange tijd de norm was in softwareontwikkeling en waarbij functionaliteit buiten de app moest worden aangeroepen via speciale verbindingen met nauwkeurig opgemaakte verzoeken.

De hostapplicatie is het centrale orchestratieplatform en maakt verbinding met een LLM. Bekende tools zoals Perplexity en Claude Desktop kunnen fungeren als host binnen een MCP-systeem.

In een eenvoudige workflow stelt de gebruiker een vraag via de chatinterface. De orchestratorcomponent van de host voegt vervolgens context toe aan de vraag en vertelt de LLM welke MCP-primitieven beschikbaar zijn, samen met een beschrijving van hun mogelijkheden.

De client is een softwarecomponent in de AI-applicatie. MCP biedt een standaardinterface waarmee de client communiceert met interne en externe MCP-servers op basis van de instructies van de host of LLM. De taak van de client is om een verbinding tot stand te brengen, JSON-RPC-berichten op te maken, verzoeken te verzenden en antwoorden te ontvangen.

De termen “MCP-host” en “MCP-client” worden soms door elkaar gebruikt. Toch is het een nuttig onderscheid, omdat een host zoals Perplexity meerdere MCP-clients tegelijk kan orkestreren. Een complexe AI-workflow kan toegang vereisen tot tientallen of zelfs honderden afzonderlijke MCP-servers, en elke server gebruikt een eigen verbinding.

Diagram van een MCP-host, zoals Perplexity, die drie MCP-clients orkestreert, elk verbonden met een eigen MCP-server, zoals een database, bestanden of een externe API.

De server stelt alle tools beschikbaar die de AI-tool kan gebruiken. Vanuit architectuurperspectief interpreteert de MCP-server het binnenkomende verzoek en maakt deze waar nodig verbinding met de aangevraagde primitieven.

MCP-servers kunnen toegang bieden tot drie categorieën primitieven:

Tools: Dit zijn in wezen externe softwarefunctionaliteiten. Bij een traditionele, API-gebaseerde aanpak kan een webanalyseapplicatie bijvoorbeeld gegevens ophalen met een opgemaakt verzoek aan een externe server. In MCP-architectuur is alle functionaliteit van derden van een provider beschikbaar via één verbinding, en worden verzoeken opgesteld volgens standaard opmaakregels.
Resources: Resources zijn gegevensbronnen die alleen-lezen context bieden. Databaseschema's zijn een goed voorbeeld. De MCP-server stelt de verschillende informatiebronnen beschikbaar die voor de host toegankelijk zijn. Als de host de database bevraagt, bijvoorbeeld met een door een LLM gegenereerde SQL-zoekopdracht, geldt dat als een toolverzoek.
Prompts: Dit zijn herbruikbare promptsjablonen die LLM's helpen om specifieke taken uit te voeren. Een gebruiker of host roept een prompt aan in plaats van een tool omdat er kant-en-klare instructies nodig zijn om een taak te voltooien. Vooraf ingestelde taken in een hostapplicatie, zoals de optie “code reviewen” of “gegevens analyseren”, worden vaak opgeslagen als prompts die de gebruiker kan selecteren.

Het is ook goed om te weten dat MCP en API geen technologieën zijn die elkaar uitsluiten. De MCP-server kan API-aanroepen beschikbaar stellen als antwoord op een ontdekkingsverzoek. Het belangrijkste is dat de MCP-provider deze onderhoudt, niet de client.

De datalaag in MCP-architectuur is de set regels die bepaalt hoe verzoeken, antwoorden en meldingen worden opgemaakt. De standaardtaal voor berichten is JSON-RPC.

Alle MCP-architectuur volgt een basisproces van (1) initialisatie en ontdekking door de host, (2) een antwoord van de MCP-server en (3) een aanroep door de host (soms bepaald door de LLM), waarbij elke fase een afzonderlijk JSON-bericht is.

Diagram van de MCP-datalaag: een gebruiker stuurt een prompt naar de hostapplicatie, waar de LLM samenwerkt met de MCP-client; de client stuurt een verzoek naar de MCP-server (tools, resources, prompts) en ontvangt een resultaat, en de host stuurt een antwoord terug naar de gebruiker.

Laten we aan de hand van twee voorbeelden bekijken hoe het ontdekken van tools werkt (dit kan ook gelden voor resources of prompts):

Tools ontdekken vóór LLM-generatie: De host start de MCP-client, die een tools/list-verzoek verzendt (de lijst met beschikbare tools van de MCP-server). De LLM bekijkt deze tijdens het generatieproces en bepaalt of een bepaalde tool, resource of prompt nodig is.
De LLM de optie geven om een zoekopdracht uit te voeren: In een agentisch systeem voegt de host een ontdekkingsoptie, zoals search-tools, toe aan de contextinvoer, en kan de LLM indien nodig een zoekopdracht aanvragen.

Tools, die grotendeels bestaan uit functionaliteiten van externe applicaties, worden doorgaans geselecteerd door de LLM of host. Resources en prompts worden meestal aangevraagd op verzoek van de gebruiker of door de host.

Zo ziet een tools/list-verzoek aan een MCP-server eruit vanuit een denkbeeldige notitieapplicatie:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

In dit voorbeeld identificeert “id”:101 het verzoek met een ID, zodat de client antwoorden aan verzoeken kan koppelen, en bevat het veld “params” aanvullende informatie over de client, zoals de clientnaam (notes-app-client) en mogelijkheden.

Als antwoord retourneert de MCP-server tooldefinities, met de namen van de beschikbare tools en de bijbehorende details. De lijst kan bijvoorbeeld een add-task-tool bevatten waarmee de notitieapplicatie taken kan aanmaken in een gekoppelde taakbeheer- of agenda-applicatie, waarbij elke taak een titel en prioriteit krijgt.

Zo kan een verzoek eruitzien:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Het veld “method” vertelt de MCP-server dat het om een toolaanroep gaat, “name” geeft aan welke tool moet worden aangeroepen en “arguments” levert de vereiste invoer.

Als de datalaag het wat is van de verbinding tussen een client en een MCP-server, dan is de transportlaag het hoe. Deze bepaalt hoe berichten worden verzonden: het specifieke kanaal en de regels die bepalen hoe verzoeken en antwoorden worden afgeleverd.

MCP heeft twee transportpaden:

Standaardinvoer/-uitvoer: Dit wordt gebruikt wanneer de MCP-server in dezelfde lokale omgeving draait als de host-app. De client schrijft het JSON-verzoek naar de standaardinvoer van de server. De server leest het, voert de gevraagde bewerking uit en schrijft het antwoord naar standaarduitvoer.
Streamable HTTP: Wanneer de MCP-server extern ten opzichte van de hostapplicatie draait, stuurt de MCP-client verzoeken naar de server via HTTP POST. De server antwoordt met één JSON-bericht of met een Server-Sent Events (SSE)-stream, een permanent “luisterend” kanaal waarmee de server na verloop van tijd meerdere berichten kan terugsturen.

Multi-tenant MCP-architectuur is een type implementatie dat meerdere gebruikers (tenants) tegelijk kan bedienen.

Een tenant kan hier een individu, een groep individuen of een organisatie zijn. De implementatie kan bestaan uit het draaien van een afzonderlijke MCP-server voor elke tenant, het bieden van toegang tot één gedeelde server of het plaatsen van een reeks servers achter een centrale gateway. Wanneer een gateway wordt gebruikt, routeert die verzoeken naar de juiste endpoints op basis van de identiteit van de gebruiker of de aard van het verzoek.

Het werkt volgens hetzelfde basisprincipe als standaard MCP-architectuur, maar individuele gebruikersverzoeken worden in een eigen werkruimte verwerkt (ook als daarbij resources worden gedeeld) en afzonderlijk geauthenticeerd. Dit is gebruikelijk in zakelijke omgevingen, en gedeelde resources hebben vaak de voorkeur omdat het draaien van meerdere MCP-servers onnodig kostbaar zou zijn.

Hoe ziet een end-to-end MCP-verzoek er in de praktijk uit? Er zijn acht kernfasen, waarbij telkens een ander onderdeel van de architectuur betrokken is.

Stroomdiagram van een end-to-end MCP-verzoek in acht stappen: ontdekking van tools, gebruikersinvoer, modelverwerking, toolselectie, verzoek, tooluitvoering, resultaat en antwoordgeneratie.

Zo ziet een MCP-toolaanroep er in de praktijk uit, aan de hand van het eerdere voorbeeld van een notitieapplicatie die is gekoppeld aan een taakbeheerservice:

Ontdekking van tools: De notitieapplicatie (host) gebruikt haar MCP-client om de beschikbare tools van de server op te vragen via een tools/list-verzoek. De server retourneert hun namen, beschrijvingen en verwachte invoer, waaronder die voor de tool add-task. Dit kan gebeuren voordat je een prompt indient.
Gebruikersinvoer: Je dient via de chatbot in de app een verzoek in bij de op een LLM gebaseerde notitieapplicatie, bijvoorbeeld: “Maak in mijn agenda een taak aan om mijn nieuwe concept te reviewen, met gemiddelde prioriteit.”
Modelverwerking: De host stuurt je verzoek en de relevante tooldefinities naar de LLM.
Toolselectie: De LLM genereert een gestructureerd toolverzoek waarin de tool en de bijbehorende invoer worden gespecificeerd: add-task met title: Review the draft en priority: Medium. De host controleert of de actie is toegestaan en geeft het verzoek door aan de MCP-client, die een JSON-RPC-bericht verzendt.
Verzoek: De MCP-client stuurt een tools/call-verzoek naar zijn MCP-server.
Tooluitvoering: De MCP-server roept de API van de taakbeheerapplicatie aan om een nieuwe taak aan te maken met de opgegeven titel en prioriteit.
Resultaat retourneren: De server stuurt het resultaat terug naar de MCP-client, die het doorgeeft aan de host. De host voegt het toe aan de informatie die aan de LLM wordt verstrekt.
Antwoordgeneratie: De LLM gebruikt het resultaat om een antwoord voor de gebruiker te genereren, zoals “Ik heb een taak aangemaakt om het concept te reviewen, met gemiddelde prioriteit.”

MCP en traditionele API-architectuur worden vaak met elkaar verward, maar het zijn complementaire technologieën. MCP is speciaal ontworpen voor AI-gebaseerde applicaties. Het neemt de zware onderhoudslast weg van het implementeren en beheren van meerdere hardgecodeerde API-verbindingen.

Door een hostapplicatie één verbinding per functionaliteitsprovider of interne resource te bieden, helpt MCP het probleem op te lossen van overvolle contextinvoer (waarin alle API's worden vermeld) of beperkte, API-gebaseerde applicatiescripts.

In plaats daarvan kunnen MCP's API's (of beter gezegd: de functionaliteit die API's aanroept) beschikbaar stellen als onderdeel van hun toollijst. Wanneer een provider zijn app bijwerkt en er een nieuwe API is, of als de documentatie verandert, werkt de provider gewoon de MCP-server bij. Aan de kant van de host-app zijn geen codewijzigingen nodig.

Sinds de introductie is er veel discussie over de beveiliging van MCP. Hoewel het over het algemeen als een veilige technologie wordt beschouwd, zijn er verschillende beveiligingsrisico's, waarvan er veel sterker naar voren komen in complexe architectuurimplementaties.

MCP-architectuur kent de volgende mogelijke zwakke punten:

Promptinjectie: Een gebruiker voegt een kwaadaardige prompt in externe gegevens in, die het AI-model ten onrechte als instructie interpreteert.
Te ruime toegangsrechten: MCP-servers kunnen mogelijk een groot aantal tools blootstellen aan een AI-model, wat de kans op beveiligingsproblemen kan vergroten (de zogeheten blast radius).
Onbedoelde datalekken: Slecht geconfigureerde implementaties kunnen ertoe leiden dat gevoelige informatie, zoals API-sleutels of inloggegevens voor databases, wordt doorgegeven aan een LLM.
Manipulatie van het lokale systeem: Lokale MCP-servers zijn net zo kwetsbaar voor problemen met het lokale systeem, zoals kwaadaardige scripts, als andere applicaties, met als bijkomend probleem dat ze verderop in de keten schadelijke gevolgen kunnen hebben voor agentische AI-systemen.

Geen van deze problemen is onoverkomelijk. Vaak zijn beproefde maatregelen alles wat nodig is om de veiligheid van het systeem te waarborgen. Maatregelen zoals een mens in de loop houden, strikte controles op gevoelige gegevens afdwingen en beschermen tegen aanvallen op servers zijn allemaal gangbare praktijken.

MCP heeft zich bewezen als een nuttige en populaire open standaard voor ontwikkelaars. Het lost veel van de problemen op van hardgecodeerde API's in op LLM's gebaseerde applicaties en vermindert de programmeerlast voor ontwikkelaars aanzienlijk.

De onderliggende host- en serverarchitectuur van MCP blijft in de toekomst vrijwel zeker hetzelfde. Toekomstige innovaties zullen draaien om geavanceerde agentische mogelijkheden in workflows met meerdere stappen.

Daarnaast zijn sterkere beveiligingsmaatregelen nodig naarmate die agentische functionaliteiten worden geïmplementeerd, en is een schaalbare architectuur nodig, vooral in de transportlaag, naarmate AI-systemen omvangrijker en complexer worden.

Wat is MCP-architectuur?

Componenten van MCP-architectuur: hosts, clients en servers

Host

Client

Server

Wat is de datalaag in MCP-architectuur?

Wat is de transportlaag in de MCP-architectuur?

Wat is multi-tenant MCP-architectuur?

MCP-architectuurdiagram: stapsgewijze uitleg

Hoe verschilt MCP-architectuur van traditionele API-architectuur?

Is MCP-architectuur veilig?

Wat is de toekomst van MCP-architectuur?