Wat is MCP? Zo koppel je AI veilig aan tools, data en bedrijfssoftware

Een taalmodel kan analyseren, schrijven en programmeren, maar zonder toegang tot je systemen blijft het een slimme gesprekspartner die niets kan nakijken of uitvoeren. Het Model Context Protocol (MCP) is de standaard waarmee AI-applicaties die toegang krijgen: tot bestanden, databases, API's en bedrijfssoftware. Dat maakt koppelen eenvoudiger. Het maakt koppelen niet automatisch veilig, en daar gaat het in de praktijk meestal mis.

Wat is het Model Context Protocol?

MCP is een open protocol waarmee AI-applicaties op een vaste manier kunnen ontdekken welke data en functies een extern systeem aanbiedt, en die vervolgens gebruiken. Het is geen AI-model en geen vervanging voor een API. Het is een gestandaardiseerde laag tussen een AI-applicatie en de systemen die context of acties leveren.

Anthropic introduceerde MCP op 25 november 2024. Op 9 december 2025 bracht Anthropic het onder bij de Agentic AI Foundation, een fonds binnen de Linux Foundation dat het samen met Block en OpenAI oprichtte. Het protocol is daarmee niet langer van één AI-leverancier. Anthropic meldde toen ruim tienduizend actieve publieke MCP-servers en meer dan 97 miljoen SDK-downloads per maand, en noemde onder meer ChatGPT, Cursor, Gemini, Microsoft Copilot en Visual Studio Code als gebruikers.

Welk probleem lost MCP op?

Zonder MCP bouw je elke koppeling apart. Een AI-assistent verbinden met GitHub, Google Drive, Slack en een interne database betekent vier integraties, elk met eigen authenticatie, endpoints, datastructuren en foutmeldingen. En die integraties werken alleen in de ene AI-applicatie waarvoor je ze bouwde.

Daar komt een AI-specifiek probleem bij. Gewone software weet vooraf welk endpoint hij aanroept. Een taalmodel moet eerst bepalen welk gereedschap relevant is, welke argumenten nodig zijn en of het resultaat genoeg is om verder te gaan. MCP standaardiseert precies dat deel: een server beschrijft welke data en acties hij aanbiedt en welke parameters een actie verwacht. Elke MCP-compatibele applicatie kan die server daarna gebruiken.

MCP wordt vaak vergeleken met een USB-C-poort voor AI: één aansluiting voor veel apparaten. Dat klopt voor de stekker. Maar een USB-stick die je insteekt kan geen e-mail versturen namens jou. Bij MCP moet je naast de verbinding ook regelen wie wat mag, welke acties goedkeuring vragen en hoe je invoer controleert. Het protocol maakt de verbinding uniform; het bepaalt niet welke acties veilig of wenselijk zijn.

Host, client en server

Volgens de MCP-specificatie heeft een implementatie drie rollen.

• De host is de applicatie waarin de gebruiker met AI werkt: een desktopassistent, code-editor of eigen agentplatform. De host beheert de interface, het taalmodel, de toestemmingen en de verbindingen.
• De client zit in de host en onderhoudt de verbinding met één MCP-server. Werkt een host met drie servers, dan zijn er drie clients.
• De server stelt data of functies beschikbaar: lokaal (bijvoorbeeld bestanden lezen) of op afstand (een CRM, repository of SaaS-platform). Vaak is een server een gecontroleerde schil rond een bestaande REST-, GraphQL- of database-interface.

De berichten zijn JSON-RPC 2.0: een vaste structuur voor verzoeken, antwoorden, notificaties en fouten.

Wat veranderde er in de specificatie van juli 2026?

Op 28 juli 2026 verscheen de specificatie 2026-07-28, de grootste herziening sinds de lancering. Het belangrijkste verschil: MCP is nu stateless. Vroeger begon elke verbinding met een initialisatie-handshake waarin client en server de protocolversie en ondersteunde functies afspraken, en een HTTP-server hield een sessie bij. Die handshake en de sessies zijn weg. Elk verzoek draagt nu zelf de protocolversie en de mogelijkheden van de client mee, en servers bieden een server/discover-aanroep waarmee een client vooraf kan opvragen wat de server ondersteunt.

Waarom dat ertoe doet: elk verzoek kan nu op elke serverinstantie terechtkomen, dus een MCP-server schaalt achter een gewone load balancer zoals een normale webdienst. Heeft een server toch toestand nodig over meerdere aanroepen heen, zoals een winkelmandje, dan geeft hij een eigen kenmerk terug dat de client als gewoon argument meestuurt.

Daarnaast zijn Roots, Sampling en Logging als verouderd gemarkeerd. Ze blijven minstens twaalf maanden werken, maar nieuwe implementaties horen ze niet meer te gebruiken. Bestaande servers breken dus niet van de ene op de andere dag, maar wie nu een server bouwt, bouwt op de nieuwe versie.

Lokaal of op afstand: stdio en Streamable HTTP

MCP kent twee standaardtransporten.

stdio: de client start de server als lokaal subproces en communiceert via standaardinvoer en -uitvoer. Dit is de vorm voor lokale developer-tools, zoals een server die een projectmap mag lezen. Let op: een lokale MCP-server is gewoon code die op jouw computer draait, met jouw rechten. Installeer er geen zonder de broncode, de uitgever en de gevraagde rechten te bekijken.

Streamable HTTP: elk bericht is een HTTP POST naar één endpoint van een zelfstandig draaiende server; het antwoord komt terug als JSON of als stream (Server-Sent Events) die bij dat ene verzoek hoort. Dit is de vorm voor centrale bedrijfsintegraties en SaaS-diensten, zoals een server in een afgeschermde cloudomgeving die toegang geeft tot een CRM.

Tools, resources en prompts

Een MCP-server biedt drie soorten bouwstenen aan, elk met een andere partij aan het stuur.

Tools: acties die het model kan aanvragen

Een tool is een uitvoerbare handeling: kandidaten zoeken in een recruitmentdatabase, een GitHub-issue aanmaken, een query uitvoeren, een afspraak inplannen. Een tool heeft een naam, een beschrijving en een invoerschema, zodat het model kan bepalen wanneer hij relevant is en welke argumenten nodig zijn.

Tools zijn volgens de specificatie model-controlled: het model stelt voor een tool aan te roepen. Dat betekent niet dat elke voorgestelde actie ook wordt uitgevoerd. De specificatie zegt dat hosts expliciete toestemming van de gebruiker moeten vragen voordat een tool wordt aangeroepen.

Resources: context uit andere systemen

Resources leveren data die als context dient: een bestand, databaseschema, logbestand of document, elk aangeduid met een URI. Resources zijn application-controlled: de host bepaalt hoe en wanneer die informatie aan het model wordt gegeven. Het verschil met een tool: een resource levert informatie, een tool voert iets uit.

Prompts: herbruikbare sjablonen

Prompts zijn sjablonen of workflows die de gebruiker zelf kiest, bijvoorbeeld als slash-commando. Ze zijn user-controlled. Een Git-server kan zo een prompt aanbieden voor het beoordelen van recente wijzigingen, met een branchnaam als argument.

Hoe ontdekt een client wat een server kan?

Een client kan een server vragen welke tools, resources en prompts hij aanbiedt. Een toolbeschrijving ziet er bijvoorbeeld zo uit:

{
  "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 dus niet vooraf op een bepaald endpoint geprogrammeerd te zijn. Het krijgt een beschrijving in gewone taal en een invoerschema. Onderhoudsvrij is het niet: wijzig je een tool, dan moeten beschrijving, schema, tests en autorisatieregels mee.

MCP of een gewone API?

MCP vervangt API's niet; de meeste MCP-servers gebruiken er juist een. Een API is gemaakt voor software die precies weet welk endpoint hij nodig heeft. Een MCP-server vertaalt de relevante functies van die API naar tools en resources die een AI-applicatie zelf kan ontdekken. De host bepaalt welke daarvan het model te zien krijgt, het model kiest een passende actie en de host bewaakt toestemming, uitvoering en resultaat.

Voor één eenvoudige, vaste koppeling in één applicatie is directe function calling of een eigen API-wrapper vaak praktischer. MCP loont als meerdere AI-applicaties dezelfde systemen moeten gebruiken, als je een integratie leverancier-onafhankelijk wilt aanbieden, of als tools dynamisch ontdekt moeten worden.

Twee voorbeelden uit de praktijk

Een assistent voor softwareonderhoud

Stel dat je drie MCP-servers koppelt: een voor de Git-repository, een voor het issue-systeem en een voor technische documentatie. Je vraagt:

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

Het model leest het issue, zoekt de relevante code en haalt documentatie op. Het resultaat is een analyse en een patchvoorstel. Bestanden aanpassen of een pull request openen zet je achter een goedkeuringsmoment, zodat schrijfacties bij de developer blijven.

Recruitmentdata combineren

Stel dat een recruitmentorganisatie een CRM, een mailbox en een kandidatenplatform via MCP ontsluit. Een recruiter vraagt:

Geef mij de actieve Java-vacatures in Gelderland en zoek kandidaten met wie we de afgelopen zes maanden contact hebben gehad.

De agent haalt de vacatures uit het CRM, zoekt in het kandidatenplatform op vaardigheden en regio, en controleert via een aparte koppeling wanneer het laatste contact was. MCP maakt de koppelingen uniform, maar de vragen die ertoe doen blijven bij de organisatie: mag het model alleen lezen? Mag het conceptmails maken? Mag het zelf kandidaten benaderen? Elke actie hoort een expliciete regel te hebben, zeker met persoonsgegevens in het spel.

MCP, agents en A2A

Een agent vertaalt een doel naar stappen, kiest tools, beoordeelt resultaten en bepaalt de volgende stap. MCP levert daarvoor de verbinding met tools en data, maar niet de agentlogica zelf: planning, geheugen, evaluatie, herhaalpogingen en goedkeuringsflows regelt de host of het agentframework. De agents-documentatie van OpenAI noemt bijvoorbeeld ondersteuning voor MCP-servers.

MCP is iets anders dan Agent2Agent (A2A), het protocol dat Google in april 2025 aankondigde en in juni 2025 bij de Linux Foundation onderbracht. MCP verbindt een AI-applicatie met tools en databronnen; A2A regelt communicatie en taakoverdracht tussen agents. Een reisagent kan MCP gebruiken om een vluchtendatabase te raadplegen en A2A om een aparte hotelagent een taak te geven.

Beveiliging: toegang is nog geen veiligheid

Zodra een AI bij mailboxen, databases of productieomgevingen kan, weegt beveiliging zwaarder dan gebruiksgemak. De specificatie zegt dat zelf: MCP kan deze principes niet op protocolniveau afdwingen, dus het is aan wie het implementeert. De officiële beveiligingsrichtlijnen beschrijven de aanvallen concreet. Wat daaruit volgt:

Minimale rechten. Geef elke server en gebruiker alleen wat nodig is. Een analyse-assistent heeft meestal genoeg aan leestoegang. De richtlijnen raden aan te beginnen met een kleine set scopes en pas meer rechten te vragen als een actie dat nodig heeft; één brede token die gestolen wordt, opent anders alles.

Goedkeuring voor risicovolle acties. Zoeken in documentatie heeft een ander risico dan een e-mail versturen of productiedata wijzigen. Vraag expliciete bevestiging voor externe communicatie, financiële handelingen, verwijderacties en wijzigingen in kritieke systemen.

Tokens alleen voor de juiste ontvanger. Voor verbindingen via HTTP gebruikt MCP autorisatie op basis van OAuth 2.1. Een MCP-server mag geen token accepteren dat niet voor hem is uitgegeven, en mag een token van de client ook niet ongecontroleerd doorsturen naar een achterliggende API. Die "token passthrough" is in de specificatie expliciet verboden.

Secrets buiten de code. API-sleutels en tokens horen niet in broncode of configuratiebestanden die in versiebeheer belanden. Gebruik een secret manager, afgeschermde omgevingsvariabelen en kortlevende tokens.

Tooloutput is onbetrouwbare invoer. Data uit een extern document kan instructies bevatten die het model misleiden: indirecte promptinjectie. Behandel toolresultaten als onbetrouwbaar en zorg dat tekst uit een document nooit extra rechten oplevert. De specificatie gaat nog een stap verder: ook de beschrijvingen van tools zelf gelden als onbetrouwbaar, tenzij ze van een vertrouwde server komen.

De verborgen kosten: tokens, wachttijd en foute keuzes

Elke aangeboden tool kost tokens, omdat naam, beschrijving en invoerschema aan het model worden meegegeven. Veel vergelijkbare tools vergroten bovendien de kans dat het model de verkeerde kiest. Remote servers voegen netwerkverkeer toe, dus een workflow met tien toolaanroepen voel je in de wachttijd.

• Bied alleen tools aan die voor de taak relevant zijn.
• Schrijf korte, ondubbelzinnige beschrijvingen en vermijd tools die bijna hetzelfde doen.
• Meet tokengebruik en responstijden.
• Log toolaanroepen, maar niet meer gevoelige data dan nodig.
• Test ook time-outs en foutscenario's, niet alleen de acties die slagen.

Begin met één workflow, niet met tien servers

De waarde van MCP zit niet in AI die zonder toezicht door je systemen gaat. Ze zit in gecontroleerde koppelingen: één protocol, duidelijke schema's, beperkte rechten en zichtbare goedkeuringsmomenten. Een goede implementatie begint daarom niet met de vraag hoeveel tools je kunt aansluiten, maar met de vraag welke gegevens en acties een AI voor één concrete workflow nodig heeft. Maak die set klein, meet wat hij kost en zet elke schrijfactie achter een goedkeuring. Werk je met Claude Code, dan koppel je zo'n server met claude mcp add; hoe je daar verder effectief mee werkt, lees je in een apart artikel.