Wat is MCP (Model Context Protocol) en waarom verandert het agents?

MCP, voluit Model Context Protocol, is een open protocol waarmee AI-applicaties op een gestandaardiseerde manier verbinding kunnen maken met externe databronnen, software en tools. In plaats van voor iedere database, CRM, documentomgeving of bedrijfsapplicatie een aparte koppeling voor een AI-agent te bouwen, kan die functionaliteit via een MCP-server beschikbaar worden gesteld. De agent kan vervolgens ontdekken welke mogelijkheden beschikbaar zijn en deze gebruiken wanneer dat nodig is.

Dat klinkt op het eerste gezicht als een technische verbetering, maar voor AI-agents is de impact groter. Een taalmodel wordt pas echt een agent wanneer het niet alleen tekst genereert, maar ook informatie kan ophalen, beslissingen kan nemen en acties kan uitvoeren. MCP standaardiseert precies de laag tussen het AI-systeem en de buitenwereld. Daardoor worden tools minder sterk gekoppeld aan één model, één applicatie of één AI-leverancier.

Van chatbot naar agent

Een traditioneel taalmodel werkt in essentie met de informatie die het tijdens training heeft geleerd en de context die op dat moment in de prompt wordt meegegeven. Daarmee kun je uitstekende teksten genereren, vragen beantwoorden en redeneren, maar het model weet bijvoorbeeld niet automatisch:

• welke facturen vandaag openstaan;
• wat er in het interne CRM over een klant staat;
• welke documenten op de fileserver staan;
• of een bepaalde voorraad nog beschikbaar is;
• welke tickets in het supportsysteem wachten;
• of het een actie in een bedrijfsapplicatie mag uitvoeren.

Voor dergelijke taken heeft een AI-systeem toegang nodig tot externe systemen. Dat was vóór MCP uiteraard ook mogelijk: ontwikkelaars konden API-koppelingen bouwen, function calling gebruiken of maatwerkcode schrijven waarmee een taalmodel een database, zoekmachine of applicatie kon benaderen. Het probleem is vooral dat iedere koppeling opnieuw moet worden ontworpen, geïmplementeerd en onderhouden. MCP introduceert hiervoor een gemeenschappelijke interface.

Hoe werkt MCP?

MCP werkt volgens een architectuur waarin een MCP-host, MCP-client en één of meer MCP-servers samenwerken. De host is de AI-applicatie waarin de gebruiker werkt. De MCP-client verzorgt vanuit die omgeving de communicatie met een MCP-server. De server stelt vervolgens specifieke informatie of functionaliteit beschikbaar. MCP gebruikt hiervoor gestandaardiseerde berichtstructuren en is gebaseerd op JSON-RPC.

Een MCP-server kan onder andere drie belangrijke soorten functionaliteit beschikbaar stellen:

• Tools zijn acties die een model kan uitvoeren. Denk aan een databasequery, het aanmaken van een ticket, het opvragen van een orderstatus of het uitvoeren van een berekening. Iedere tool heeft een naam en een gestructureerd schema voor de invoer.
• Resources stellen gegevens of content beschikbaar die de AI-applicatie kan lezen — bijvoorbeeld documenten, configuraties, records of andere databronnen.
• Prompts zijn herbruikbare prompttemplates die een MCP-server beschikbaar kan stellen aan een client.

De precieze mogelijkheden van MCP blijven zich ontwikkelen. De actuele specificatie van 28 juli 2026 bevat onder meer verdere standaardisering rond protocolgedrag, caching, autorisatie en uitbreidingen.

Een praktisch voorbeeld

Stel dat een mkb-bedrijf een interne AI-agent bouwt voor de klantenservice. De agent moet kunnen:

• zoeken in productdocumentatie;
• klantgegevens uit het CRM ophalen;
• openstaande bestellingen bekijken;
• supporttickets aanmaken;
• een medewerker om goedkeuring vragen voordat bepaalde acties worden uitgevoerd.

Zonder een standaard zoals MCP kan voor iedere functie een afzonderlijke integratielaag worden gebouwd. Het AI-framework moet dan bijvoorbeeld weten hoe de CRM-API werkt, hoe de documentdatabase wordt aangesproken en welke parameters de ticketsoftware verwacht.

Met MCP kan het bedrijf deze functionaliteiten als MCP-tools en resources aanbieden. De agent ziet dan bijvoorbeeld conceptueel functies zoals zoek_documentatie, haal_klant_op, controleer_bestelling en maak_supportticket. De agent hoeft niet te weten hoe het CRM intern is opgebouwd. Hij hoeft alleen te begrijpen welke tool beschikbaar is, waarvoor die bedoeld is en welke invoer ervoor nodig is. Dat is een belangrijk verschil: de integratielogica wordt losgekoppeld van de intelligentielaag.

Waarom verandert MCP AI-agents?

Het belangrijkste gevolg is modulariteit. Een agent bestaat grofweg uit drie onderdelen: een model dat redeneert, een orchestratie- of agentlaag die bepaalt hoe taken worden uitgevoerd, en verbindingen met systemen waarop de agent kan handelen. Vooral die laatste laag was lang sterk afhankelijk van maatwerk.

MCP maakt het mogelijk om capabilities onafhankelijker aan te bieden. Een goed ontworpen MCP-server kan in beginsel door verschillende MCP-compatibele clients worden gebruikt. Dat betekent dat een organisatie haar bedrijfsintegraties niet noodzakelijk opnieuw hoeft te ontwerpen wanneer zij van model of agentplatform verandert.

Dat wordt steeds relevanter doordat MCP inmiddels niet meer alleen binnen het ecosysteem van de oorspronkelijke initiatiefnemer Anthropic wordt gebruikt. Anthropic introduceerde MCP in november 2024 en droeg het protocol eind 2025 over aan de Agentic AI Foundation onder de Linux Foundation. OpenAI ondersteunt inmiddels eveneens MCP in onder andere zijn API- en agenttooling en in Codex. Daarmee ontstaat iets wat in de eerste generatie agents grotendeels ontbrak: een gedeelde aansluitstandaard voor tools en context.

MCP is niet hetzelfde als een API

MCP en API's worden regelmatig tegenover elkaar gezet, maar dat is niet de juiste vergelijking. Een API bepaalt hoe software met een specifieke dienst communiceert. Een CRM kan bijvoorbeeld een REST-API aanbieden waarmee klantgegevens worden opgevraagd. MCP hoeft die API niet te vervangen: een MCP-server kan juist boven op bestaande API's worden gebouwd. De MCP-server vertaalt dan gestandaardiseerde MCP-verzoeken naar de specifieke API-aanroepen van het achterliggende systeem.

Het verschil zit dus vooral in de laag waarop de standaardisatie plaatsvindt. Voor normale software-integraties blijft een API bijzonder nuttig. MCP biedt daarboven een interface die specifiek geschikt is om tools en context aan AI-applicaties beschikbaar te stellen.

MCP versus function calling

Ook function calling en MCP zijn niet hetzelfde. Bij function calling definieert een ontwikkelaar functies die een model tijdens een gesprek kan aanroepen. De applicatie ontvangt de functieaanroep, voert de bijbehorende code uit en geeft het resultaat terug aan het model. MCP standaardiseert hoe dergelijke tools extern kunnen worden aangeboden en ontdekt.

Vereenvoudigd: function calling beantwoordt de vraag "hoe laat ik dit model een functie aanroepen?", MCP beantwoordt de vraag "hoe bied ik tools en context op een gestandaardiseerde manier aan AI-clients aan?" De technologieën kunnen daarom prima naast elkaar bestaan.

MCP versus RAG

Ook MCP maakt RAG niet overbodig. Retrieval-Augmented Generation, of RAG, draait om het ophalen van relevante informatie en het toevoegen daarvan aan de context van een taalmodel, bijvoorbeeld door documenten als embeddings in een vectordatabase op te slaan en relevante passages te zoeken. MCP beschrijft niet hoe die zoektechniek intern moet werken.

Een MCP-server kan juist een RAG-systeem toegankelijk maken als tool. De agent vraagt bijvoorbeeld zoek_kennisbank("retourvoorwaarden zakelijke klanten"). De MCP-server stuurt die zoekopdracht door naar de interne zoek- of vectorinfrastructuur en retourneert de relevante resultaten. RAG is in dat scenario de retrievaltechniek. MCP is de interface waarmee de agent de retrievalfunctie gebruikt.

Waarom MCP interessant is voor on-prem AI

Voor organisaties die bedrijfsdata niet zomaar naar allerlei externe AI-diensten willen sturen, is MCP vooral interessant omdat de integratielaag zelf onder eigen controle kan blijven. Een MCP-server kan lokaal, binnen een privénetwerk of in een eigen infrastructuur draaien. MCP-servers kunnen zowel lokale processen als remote services zijn — de architectuur schrijft dus niet voor dat bedrijfsdata publiek of bij één specifieke leverancier moet worden opgeslagen.

Een organisatie kan bijvoorbeeld een lokaal taalmodel combineren met lokale MCP-servers en interne databases. Maar het is ook mogelijk een cloudmodel te gebruiken terwijl de achterliggende MCP-server binnen de eigen infrastructuur draait. Moderne platformen bieden hiervoor steeds meer mechanismen; OpenAI documenteert bijvoorbeeld een Secure MCP Tunnel waarmee private of on-premises MCP-servers bereikbaar kunnen worden gemaakt zonder een inkomende publieke verbinding naar die server te openen.

Voor een AVG-bewuste architectuur is dat relevant, maar MCP maakt een oplossing niet automatisch AVG-compliant. Waar data wordt verwerkt, welke persoonsgegevens aan een model worden doorgegeven, welke leveranciers betrokken zijn en welke toegangsrechten gelden, blijven afzonderlijke architectuur- en governancevragen.

MCP maakt beveiliging juist belangrijker

Een agent die alleen tekst kan genereren heeft een relatief beperkte operationele impact. Een agent die bestanden kan lezen, databases kan benaderen en acties in bedrijfssoftware kan uitvoeren, heeft veel meer macht. Daarom moet een MCP-implementatie niet worden gezien als simpelweg: "we sluiten alle systemen aan en laten het model kiezen."

De officiële MCP-documentatie besteedt uitgebreid aandacht aan autorisatie, tokenbeveiliging en aanvalsscenario's. Voor remote MCP-servers ondersteunt het protocol gestandaardiseerde autorisatieflows die aansluiten op OAuth-conventies. In een bedrijfsomgeving zijn onder andere de volgende principes belangrijk:

• geef een agent alleen toegang tot tools die hij werkelijk nodig heeft;
• scheid leesrechten en schrijfrechten;
• gebruik afzonderlijke gebruikers- of service-identiteiten waar mogelijk;
• log relevante toolcalls;
• vereis menselijke goedkeuring voor risicovolle acties;
• valideer invoer en uitvoer;
• behandel content uit externe systemen als potentieel onbetrouwbaar;
• voorkom dat credentials of tokens onnodig in de modelcontext terechtkomen.

Dat laatste punt is extra belangrijk omdat prompt injection niet alleen via een gebruiker kan binnenkomen. Kwaadaardige instructies kunnen ook verborgen zitten in documenten, websites of andere data die een agent ophaalt. OpenAI waarschuwt bij het gebruik van MCP-tools en connectors eveneens expliciet voor prompt-injectionrisico's wanneer een model toegang krijgt tot gevoelige informatie of acties.

Van tientallen losse integraties naar een capability-laag

Voor bedrijven zit de interessantste verandering daarom misschien niet eens in MCP zelf, maar in de architectuur die het mogelijk maakt. Stel dat een bedrijf meerdere agents heeft: een salesagent, een klantenserviceagent, een interne kennisagent, een finance-agent en een software-agent. Alle vijf hebben mogelijk toegang nodig tot hetzelfde CRM, documentmanagementsysteem of ERP.

Je kunt daarvoor vijf aparte integraties bouwen. Maar je kunt ook één gecontroleerde integratielaag ontwerpen waarin bedrijfsfuncties als goed afgebakende MCP-capabilities worden aangeboden, bijvoorbeeld zoek_klant, lees_contract, controleer_factuurstatus, zoek_interne_documentatie en maak_concept_ticket. Vervolgens bepaal je per agent welke capabilities beschikbaar zijn. Dat is architectonisch veel interessanter dan agents rechtstreeks onbeperkte database- of API-toegang geven.

MCP maakt agents vervangbaarder — en infrastructuur waardevoller

Een ander belangrijk gevolg is dat organisaties minder afhankelijk kunnen worden van één specifiek taalmodel. Vandaag kan een agent op een model van leverancier A draaien. Volgend jaar blijkt model B beter te presteren voor dezelfde taak. Wanneer alle bedrijfsintegraties diep in het framework van leverancier A zijn ingebouwd, kan migreren kostbaar zijn. Een gestandaardiseerde tool- en contextlaag vermindert die koppeling.

MCP garandeert geen volledige modelonafhankelijkheid — agentframeworks, prompts, modelgedrag en ondersteunde features verschillen nog steeds — maar het verplaatst een belangrijk deel van de integratielogica naar een neutralere laag. Voor bedrijven betekent dit dat de waarde steeds minder uitsluitend in "welk model gebruiken we?" hoeft te zitten. De interessantere asset wordt de AI-infrastructuur rondom het model: de bedrijfskennis, permissions, tools, workflows, logging en integraties waarmee een generiek taalmodel daadwerkelijk nuttig werk kan uitvoeren.

Is MCP daarmee de toekomst van AI-agents?

MCP lost niet ieder probleem rond agents op. Het bepaalt niet welk model een organisatie moet gebruiken, het maakt een slechte workflow niet automatisch goed en het voorkomt geen hallucinaties of verkeerde beslissingen.

Het lost wel een fundamenteel infrastructuurprobleem op: hoe laat je AI-systemen op een consistente manier communiceren met de tools en informatie die zij nodig hebben? Dat is vergelijkbaar met wat andere standaarden eerder voor software-infrastructuur hebben gedaan. Zodra meerdere applicaties dezelfde interface begrijpen, hoeft niet iedere combinatie van applicatie en databron opnieuw als maatwerkintegratie te worden gebouwd.

Daarom is MCP meer dan een handige developerfeature. Voor de volgende generatie AI-agents kan het de standaard aansluitlaag worden tussen het redeneervermogen van een model en de daadwerkelijke bedrijfsomgeving waarin dat model moet functioneren. En juist daar verandert een taalmodel in iets veel bruikbaarders: een agent die niet alleen weet wat hij moet zeggen, maar binnen gecontroleerde grenzen ook weet welke systemen hij kan gebruiken om daadwerkelijk iets te doen.

Veelgestelde vragen over MCP

Is MCP hetzelfde als een API? Nee. Een API beschrijft hoe software met een specifieke applicatie of dienst communiceert. MCP biedt een gestandaardiseerde interface waarmee AI-applicaties tools, resources en andere capabilities kunnen ontdekken en gebruiken. Een MCP-server kan daarvoor gewoon bestaande REST-, GraphQL- of andere API's achter de schermen gebruiken.

Werkt MCP alleen met Claude? Nee. Anthropic introduceerde MCP oorspronkelijk in 2024, maar het protocol is open en is inmiddels ondergebracht bij de Agentic AI Foundation van de Linux Foundation. Ook andere AI-platformen ondersteunen MCP; OpenAI ondersteunt bijvoorbeeld MCP binnen zijn API- en agentecosysteem en Codex.

Is MCP geschikt voor gevoelige bedrijfsdata en on-prem AI? Ja, mits de architectuur en beveiliging daarop zijn ingericht. MCP-servers kunnen binnen een eigen infrastructuur worden uitgevoerd en toegang kan per tool en gebruiker worden beperkt. MCP zelf garandeert echter geen privacy of AVG-compliance. Autorisatie, dataminimalisatie, logging, modelkeuze, netwerkarchitectuur en menselijke goedkeuring voor gevoelige acties moeten expliciet worden ontworpen.