MCP AI veilig met tools, data en bedrijfssoftware

Een taalmodel kan uitstekend analyseren, schrijven en programmeren, maar zonder toegang tot externe systemen blijft het vooral een slimme gesprekspartner. Het Model Context Protocol verandert dat door AI-applicaties op een gestandaardiseerde manier te verbinden met bestanden, databases, API’s en zakelijke tools. In dit artikel lees je hoe MCP technisch werkt, wat het oplost en waar je bij implementatie scherp op moet letten.

Wat is het Model Context Protocol?

Het Model Context Protocol, meestal afgekort tot MCP, is een open protocol waarmee AI-applicaties informatie en functionaliteit van externe systemen kunnen ontdekken en gebruiken.

Anthropic introduceerde MCP op 25 november 2024. Het oorspronkelijke doel was om AI-assistenten eenvoudiger te verbinden met systemen waarin relevante data staat, zoals repositories, ontwikkelomgevingen, documenten en bedrijfsapplicaties.

In december 2025 werd MCP ondergebracht bij de Agentic AI Foundation van de Linux Foundation. Daarmee wordt het protocol niet uitsluitend door één AI-leverancier beheerd, maar verder ontwikkeld als een open en leverancier-onafhankelijk project.

MCP is geen AI-model en ook geen vervanging voor een bestaande API. Het is een gestandaardiseerde integratielaag tussen een AI-applicatie en systemen die context of acties beschikbaar stellen.

Waarom MCP nodig is

Zonder MCP moet een ontwikkelaar iedere koppeling afzonderlijk bouwen. Wil je een AI-assistent verbinden met GitHub, Google Drive, Slack en een interne database, dan heb je meestal vier verschillende integraties nodig. Iedere dienst heeft eigen authenticatie, endpoints, datastructuren, foutmeldingen en documentatie.

Daar komt nog een AI-specifiek probleem bij. Een traditionele applicatie weet vooraf welk endpoint zij moet aanroepen. Een taalmodel moet vaak eerst bepalen welk gereedschap relevant is, welke argumenten nodig zijn en of het resultaat voldoende is om verder te gaan.

MCP standaardiseert precies dat gedeelte. Een server kan beschrijven:

• welke gegevens beschikbaar zijn;
• welke acties uitgevoerd kunnen worden;
• welke parameters een actie verwacht;
• welke aanvullende mogelijkheden de server ondersteunt;
• hoe de client en server tijdens een sessie communiceren.

Daardoor hoeft een AI-host niet voor iedere integratie een volledig nieuw communicatiepatroon te implementeren.

De USB-C-metafoor: nuttig, maar niet volledig

MCP wordt vaak omschreven als een USB-C-poort voor AI. Die vergelijking helpt om het basisidee te begrijpen. Een USB-C-poort biedt één gestandaardiseerde aansluiting voor verschillende apparaten. MCP biedt één gestandaardiseerd protocol voor verschillende databronnen en tools.

De vergelijking heeft wel een grens. Een fysiek apparaat dat je aansluit, kan meestal direct gebruikt worden. Bij MCP zijn daarnaast beveiliging, autorisatie, toolselectie, validatie en gebruikersgoedkeuring nodig. Het protocol maakt de verbinding consistent, maar bepaalt niet automatisch welke acties veilig of wenselijk zijn.

De architectuur: host, client en server

Volgens de officiële MCP-architectuur bestaat een implementatie uit drie belangrijke onderdelen.

De MCP-host

De host is de applicatie waarin de gebruiker met AI werkt. Dit kan een desktopassistent, code-editor, bedrijfsapplicatie of eigen agentplatform zijn. De host beheert doorgaans de gebruikersinterface, het taalmodel, toestemmingen en de verbindingen met MCP-servers.

De MCP-client

De client bevindt zich binnen de host en onderhoudt een verbinding met één MCP-server. Wanneer een host met meerdere servers werkt, gebruikt hij normaal gesproken meerdere clientverbindingen.

De client voert onder andere de initialisatie uit, onderhandelt over ondersteunde mogelijkheden en verstuurt protocolberichten.

De MCP-server

Een MCP-server stelt functionaliteit of data beschikbaar. Dat kan een lokale server zijn die bestanden leest, maar ook een remote server die een CRM, repository, database of SaaS-platform ontsluit.

De server hoeft de onderliggende functionaliteit niet zelf te implementeren. Vaak is hij een gecontroleerde wrapper rond een bestaande REST-, GraphQL- of database-interface.

Hoe communiceren MCP-componenten?

MCP gebruikt JSON-RPC 2.0 als basis voor berichten tussen clients en servers. JSON-RPC definieert een herkenbare structuur voor requests, responses, notificaties, parameters en fouten.

MCP voegt daar afspraken aan toe voor onder meer:

• initialisatie en protocolversies;
• capability negotiation;
• tools, resources en prompts;
• logging en notificaties;
• annulering van aanvragen;
• autorisatie voor remote verbindingen;
• interactie waarbij aanvullende gebruikersinput nodig is.

De officiële specificatie is versiegebonden. Een client en server onderhandelen daarom bij het opzetten van de verbinding over de protocolversie en de functies die zij ondersteunen.

Lokale en remote verbindingen

MCP ondersteunt verschillende transportmechanismen. De twee belangrijkste zijn stdio en Streamable HTTP.

Stdio voor lokale processen

Bij stdio start de client de MCP-server als een lokaal subprocess. De client stuurt berichten via standard input en ontvangt antwoorden via standard output.

Deze vorm is geschikt voor lokale developer-tools. Een code-assistent kan bijvoorbeeld een server starten die gecontroleerd toegang heeft tot een projectdirectory of lokale ontwikkeltool.

Een belangrijk beveiligingspunt is dat een lokale MCP-server code op de computer van de gebruiker uitvoert. Installeer daarom geen willekeurige serverpackages zonder de broncode, uitgever en gevraagde rechten te controleren.

Streamable HTTP voor remote servers

Bij Streamable HTTP communiceert de client via HTTP met een zelfstandig draaiende server. De server kan streaming en server-to-clientberichten ondersteunen, onder andere via Server-Sent Events.

Dit transport is geschikt voor centrale bedrijfsintegraties en SaaS-diensten. Denk aan een MCP-server die in een beveiligde cloudomgeving draait en toegang geeft tot een CRM of documentmanagementsysteem.

Tools, resources en prompts

MCP-servers kunnen verschillende soorten mogelijkheden aanbieden. De bekendste zijn tools, resources en prompts.

Tools: acties die een model kan aanvragen

Een tool vertegenwoordigt een uitvoerbare handeling. Voorbeelden zijn:

• zoeken naar kandidaten in een recruitmentdatabase;
• een GitHub-issue aanmaken;
• een query uitvoeren;
• een conceptbericht opslaan;
• een afspraak inplannen.

Een tool bevat een naam, beschrijving en invoerschema. Hierdoor kan het taalmodel bepalen wanneer de tool relevant is en welke argumenten het moet aanleveren.

Tools zijn volgens de MCP-specificatie model-controlled: het model kan voorstellen om een tool aan te roepen op basis van de opdracht en de beschikbare context. Dat betekent niet dat iedere voorgestelde actie zonder controle uitgevoerd moet worden. De host kan goedkeuring, validatie en beleidsregels afdwingen.

Resources: context uit externe systemen

Resources stellen data beschikbaar die een applicatie als context kan gebruiken. Een resource kan bijvoorbeeld een bestand, databaseschema, logbestand of document zijn.

Resources worden via een URI geïdentificeerd. De host bepaalt hoe en wanneer de informatie aan het model wordt aangeboden. Daarmee verschillen resources van tools: een resource levert primair informatie, terwijl een tool een bewerking uitvoert.

Prompts: herbruikbare interacties

Een server kan ook prompts aanbieden. Dit zijn herbruikbare sjablonen of workflows die een gebruiker of host kan selecteren.

Een Git-server zou bijvoorbeeld een prompt kunnen aanbieden voor het beoordelen van recente wijzigingen. De prompt kan vaste instructies combineren met argumenten, zoals een branchnaam of commitreeks.

Dynamic discovery: de client ontdekt wat beschikbaar is

Een belangrijk voordeel van MCP is capability discovery. Na het initialiseren van een sessie kan een client opvragen welke tools, resources en prompts de server aanbiedt.

Een server kan bijvoorbeeld via een toolbeschrijving aangeven dat hij de volgende actie ondersteunt:

{
  "name": "search_candidates",
  "description": "Zoek kandidaten op functie, regio en vaardigheden",
  "inputSchema": {
    "type": "object",
    "properties": {
      "role": { "type": "string" },
      "region": { "type": "string" },
      "skills": {
        "type": "array",
        "items": { "type": "string" }
      }
    },
    "required": ["role"]
  }
}

Het model hoeft daardoor niet vooraf geprogrammeerd te zijn met een specifiek endpoint. Het krijgt een semantische beschrijving en een gestructureerd invoerschema.

Dat maakt integraties flexibeler, maar niet volledig onderhoudsvrij. Wanneer een server tools wijzigt, moeten beschrijvingen, schema’s, tests en autorisatieregels nog steeds correct worden bijgehouden.

MCP versus traditionele API’s

MCP vervangt API’s niet. In veel implementaties gebruikt een MCP-server juist bestaande API’s.

Een traditionele API is meestal ontworpen voor software die exact weet welk endpoint nodig is. De ontwikkelaar leest de documentatie en schrijft code voor een concrete request.

Een MCP-interface is ingericht op ontdekking en toolgebruik door AI-applicaties. De server beschrijft zijn mogelijkheden op een manier die een host en taalmodel kunnen interpreteren.

Het verschil zit dus vooral in de integratielaag:

• een API biedt applicatiefuncties en data;
• een MCP-server vertaalt relevante functies naar gestandaardiseerde AI-tools en resources;
• de MCP-host bepaalt welke mogelijkheden aan het model worden getoond;
• het model selecteert op basis van de opdracht een passende actie;
• de host bewaakt toestemming, uitvoering en resultaat.

Praktijkvoorbeeld 1: een AI-assistent voor softwareontwikkeling

Stel dat je een AI-assistent gebruikt bij het onderhouden van een applicatie. Je koppelt drie MCP-servers:

1. een server voor de Git-repository;
2. een server voor het issue-trackingsysteem;
3. een server voor technische documentatie.

Je vraagt:

Onderzoek waarom issue 184 nog niet is opgelost, controleer de relevante code en maak een voorstel voor een patch.

De host kan het model vervolgens gecontroleerd verschillende acties laten uitvoeren. Het leest eerst het issue, zoekt daarna relevante code en haalt vervolgens documentatie op. Het resultaat kan een probleemanalyse en patchvoorstel zijn.

Het daadwerkelijk aanpassen van bestanden of openen van een pull request kan achter een goedkeuringsmoment worden geplaatst. Zo behoudt de developer controle over schrijfacties.

Praktijkvoorbeeld 2: recruitmentdata combineren

Een recruitmentorganisatie kan MCP gebruiken om informatie uit verschillende systemen samen te brengen. Denk aan een CRM, mailbox en kandidatenplatform.

Een recruiter vraagt:

Geef mij de actieve Java-vacatures in Gelderland en zoek kandidaten waarmee de afgelopen zes maanden contact is geweest.

De agent kan eerst vacatures ophalen uit het CRM. Daarna zoekt hij in het kandidatenplatform op vaardigheden en regio. Vervolgens controleert hij via een aparte integratie wanneer het laatste contact plaatsvond.

MCP maakt de interfaces uniform, maar de organisatie moet nog steeds duidelijke regels instellen. Mag het model alleen gegevens lezen? Mag het conceptmails maken? Mag het zelfstandig kandidaten benaderen? Voor iedere actie hoort een expliciet autorisatiebeleid te gelden.

MCP en AI-agenten

MCP wordt vaak in één adem genoemd met AI-agenten. Een agent is een systeem dat een doel vertaalt naar meerdere stappen, tools selecteert, resultaten beoordeelt en eventueel vervolgstappen uitvoert.

MCP levert hiervoor de verbinding met externe tools en context. Het protocol implementeert echter niet automatisch de volledige agentlogica. Planning, geheugen, evaluatie, retries, guardrails en goedkeuringsflows worden door de host of het agentframework geregeld.

Platforms zoals de OpenAI Agents SDK en Responses API kunnen remote MCP-servers gebruiken binnen agentworkflows. Ook andere AI-platforms en developer-tools ondersteunen MCP-integraties.

MCP en Agent2Agent zijn verschillende protocollen

MCP moet niet worden verward met Agent2Agent, oftewel A2A. Deze protocollen lossen verschillende integratieproblemen op.

MCP richt zich hoofdzakelijk op de verbinding tussen een AI-applicatie en tools of databronnen. A2A richt zich op communicatie en taakoverdracht tussen afzonderlijke agenten.

Een reisagent kan MCP gebruiken om een vluchtendatabase te raadplegen. Dezelfde agent kan A2A gebruiken om een gespecialiseerde hotelagent een afzonderlijke taak te geven. De protocollen kunnen elkaar dus aanvullen, maar een agent communiceert niet automatisch met andere agenten via MCP.

Beveiliging: MCP maakt toegang mogelijk, niet automatisch veilig

Zodra een AI toegang krijgt tot mailboxen, databases of productieomgevingen, wordt beveiliging belangrijker dan gebruiksgemak. De officiële MCP-beveiligingsrichtlijnen beschrijven verschillende aanvalsvectoren en maatregelen.

Werk met minimale rechten

Geef iedere server en gebruiker uitsluitend de rechten die nodig zijn. Een analyse-assistent heeft vaak voldoende aan leestoegang. Geef geen verwijder- of beheerdersrechten wanneer die niet noodzakelijk zijn.

Plaats goedkeuring voor risicovolle acties

Een actie zoals zoeken in documentatie heeft een ander risicoprofiel dan een e-mail versturen of productiegegevens wijzigen. Gebruik expliciete bevestiging voor externe communicatie, financiële transacties, verwijderacties en wijzigingen in kritieke systemen.

Bescherm tokens en secrets

Sla API-keys en toegangstokens niet op in broncode of configuratiebestanden die in versiebeheer terechtkomen. Gebruik secret managers, beveiligde omgevingsvariabelen en kortlevende tokens.

Gebruik gestandaardiseerde autorisatie

Voor HTTP-gebaseerde implementaties definieert MCP een autorisatiemodel op basis van OAuth 2.1. Daarbij moeten clients en servers onder andere tokens correct valideren en veilig opslaan.

Vertrouw tooloutput niet blind

Data uit externe bronnen kan schadelijke of misleidende instructies bevatten. Dit wordt indirecte promptinjectie genoemd. Behandel toolresultaten daarom als onbetrouwbare input, valideer uitvoer en voorkom dat tekst uit een document automatisch extra privileges krijgt.

De verborgen kosten: tokens, latency en complexiteit

Een grote verzameling tools kan extra tokens verbruiken doordat namen, beschrijvingen en invoerschema’s aan het model beschikbaar worden gesteld. Veel vergelijkbare tools vergroten bovendien de kans dat het model de verkeerde actie kiest.

Remote MCP-servers voegen ook netwerkaanvragen toe. Een workflow met meerdere toolcalls kan daardoor merkbare latency veroorzaken.

Beperk daarom de actieve gereedschapsset:

• bied alleen tools aan die relevant zijn voor de taak;
• schrijf korte maar ondubbelzinnige beschrijvingen;
• vermijd meerdere tools met bijna dezelfde functie;
• meet tokengebruik en responstijden;
• log toolcalls zonder gevoelige data onnodig vast te leggen;
• test niet alleen succesvolle acties, maar ook time-outs en foutscenario’s.

Wanneer is MCP een goede keuze?

MCP is vooral interessant wanneer meerdere AI-clients dezelfde systemen moeten kunnen gebruiken, wanneer je integraties leverancier-onafhankelijk wilt aanbieden of wanneer tools dynamisch ontdekt moeten worden.

Voor één eenvoudige, vaste integratie kan directe function calling of een reguliere API-wrapper praktischer zijn. MCP levert vooral waarde wanneer standaardisatie, hergebruik en interoperabiliteit belangrijk worden.

Conclusie

Het Model Context Protocol geeft AI-applicaties een gestandaardiseerde manier om tools en data te ontdekken en te gebruiken. Daarmee vermindert het de hoeveelheid maatwerk die nodig is om modellen met repositories, documenten, databases en bedrijfssoftware te verbinden.

De grootste winst zit niet in volledig autonome AI die zonder toezicht handelt. De werkelijke waarde zit in gecontroleerde interoperabiliteit: één protocol, duidelijke schemas, beperkte rechten en zichtbare goedkeuringsmomenten.

Een goede MCP-implementatie begint daarom niet met de vraag hoeveel tools je kunt aansluiten. Begin met de vraag welke gegevens en acties een AI voor één concrete workflow nodig heeft. Maak die gereedschapsset klein, meetbaar en veilig. Dan wordt MCP geen experimentele gimmick, maar een bruikbare infrastructuurlaag voor moderne AI-applicaties.