Wat is MCP en waarom maakt het uit voor jouw organisatie

AI-agenten worden dit jaar serieus ingezet voor het werk van kenniswerkers. Niet als experiment, maar in productie. Wat die agenten nodig hebben om te functioneren is verbinding met de systemen die jouw organisatie al gebruikt: je CRM, je gedeelde schijf, je projecttool, je interne database. Het protocol dat die verbinding standaardiseert heet MCP, het Model Context Protocol. In anderhalf jaar is het uitgegroeid tot de infrastructuurlaag waarop vrijwel alle serieuze agent-ontwikkeling nu gebouwd wordt. Dit artikel legt uit wat het is, waarom het relevant is voor jouw organisatie, en wat je nu al moet weten.

Wat MCP is, in gewone taal

Een AI-agent is pas nuttig als hij dingen kan doen: een afspraak inplannen, een klantdossier opzoeken, een document opslaan. Daarvoor moet hij verbinding kunnen maken met de systemen waar die informatie in zit. Tot voor kort was elke verbinding maatwerk: voor elk systeem een aparte koppeling bouwen, onderhouden en beveiligen. Dat schaalt niet.

MCP lost dat op door één gemeenschappelijke taal te definiëren. Een systeem dat MCP spreekt, kan door elke agent worden aangesproken die MCP spreekt. Vergelijkbaar met hoe USB werkt: je hoeft niet voor elke muis een aparte driver te schrijven, want allebei spreken ze dezelfde standaard.

Het protocol is open source, ontwikkeld door Anthropic en inmiddels beheerd als een open standaard. OpenAI, Google, Microsoft en honderden andere partijen bouwen er op. In anderhalf jaar tijd zijn er meer dan 110 miljoen SDK-downloads per maand. Ter vergelijking: React, een van de meest succesvolle open source projecten van het laatste decennium, had daar dubbel de tijd voor nodig.

De co-maker van MCP, David Soria Parra van Anthropic, presenteerde onlangs zijn kijk op de volgende fase van het protocol tijdens AI Engineer Europe. Zijn boodschap was helder: MCP is geen hype meer, het is infrastructuur. Maar de meeste organisaties die er nu mee werken, bouwen het nog niet goed.

Waarom dit jaar het kantelpunt is

2024 was het jaar van de demo's. 2025 was het jaar van de coding agents, agenten die programmeerwerk deden in een gecontroleerde omgeving met een ontwikkelaar die kon ingrijpen als er iets fout ging. 2026 is het jaar dat agenten breder ingezet worden: voor het werk van een financieel analist, een marketeer, een operationeel manager.

Dat vraagt om iets wat coding agents niet nodig hadden. Geen lokale omgeving, maar verbinding met vijf SaaS-applicaties tegelijk. Geen compiler als vangnet, maar autorisatiebeleid, audit trails en governance. De stap van proeftuin naar productie vraagt om andere keuzes dan de stap van idee naar prototype.

MCP is de infrastructuur die die stap mogelijk maakt. Maar het protocol regelt alleen de verbinding. Alles eromheen, wat agenten mogen aanroepen, wie dat beheert, hoe je omgaat met fouten, dat is iets wat de organisatie zelf moet inrichten.

Wat dit vraagt van jouw organisatie

De vraag is niet of MCP relevant is voor jouw organisatie. Als je serieus werkt met AI-agenten, of dat overweegt, is de vraag alleen wanneer en hoe je ermee te maken krijgt. Een paar concrete vragen om nu al over na te denken:

Welke systemen mogen agenten aanroepen? MCP maakt het technisch eenvoudig om een agent toegang te geven tot je CRM, je inbox, je interne wiki. Maar technisch mogelijk is niet hetzelfde als organisatorisch verantwoord. Zorg dat je een lijst hebt van systemen die in scope zijn voor agent-toegang, en een proces om die lijst te beheren.

Wie beheert de MCP-servers in jouw organisatie? Een MCP-server is het onderdeel dat een systeem bereikbaar maakt voor agenten. Wie bouwt die servers, wie reviewt ze, wie houdt bij welke agent toegang heeft tot welk systeem? Bij organisaties als Uber en Amazon hebben teams hiervoor een centrale registry gebouwd, met geautomatiseerde toolbeschrijvingen die alsnog door mensen worden gereviewed voordat ze live gaan.

Hoe ga je om met fouten? Een agent die halverwege een taak vastloopt, laat iets na. Misschien een half-ingevuld formulier, een niet-verzonden bericht, een actie die deels is uitgevoerd. MCP regelt de verbinding, niet het herstel. Dat moet je organisatorisch en technisch inrichten.

Wie die vragen nog niet gesteld heeft, bouwt risico's in die pas later zichtbaar worden.

Voor de IT-verantwoordelijke: wat er technisch nog hapert

Dit gedeelte gaat de technische diepte in. Relevant voor wie MCP-implementaties beoordeelt of begeleidt.

Soria Parra was in zijn keynote openhartig over de twee grootste valkuilen in huidige MCP-implementaties.

De eerste is context bloat. De meeste agent-harnesses laden alle beschikbare tools meteen in het contextvenster van het model. Bij tientallen MCP-servers kan dat meer dan 20 procent van de beschikbare context opslokken voordat de agent één stap heeft gezet. Het gevolg: slechtere toolselectie, lagere outputkwaliteit. De oplossing heet progressive discovery: de agent krijgt een zoektool waarmee hij tools opzoekt op het moment dat hij ze nodig heeft, in plaats van alles vooraf te laden. Claude Code heeft dit inmiddels geïmplementeerd en laat een significante reductie in contextgebruik zien. Maar de meeste implementaties doen dit nog niet.

De tweede is wat Soria Parra programmatic tool calling noemt. De standaard aanpak is dat een agent tools één voor één aanroept: roep tool A aan, verwerk het resultaat, roep tool B aan. Elke stap kost inferentie, dus latency en tokens. Efficiënter is om de agent code te laten schrijven die meerdere tools in één uitvoering samenvoegt. MCP ondersteunt dit via structured output, maar het wordt zelden toegepast.

Wat er verder op de roadmap staat: in juni landt een stateless transportprotocol dat MCP-servers behandelt als gewone stateless REST-servers, waardoor deployment op Kubernetes of Cloud Run veel eenvoudiger wordt. Daarnaast werkt Anthropic aan cross-app access, waarbij een eenmalige inlog bij de identity provider van je organisatie volstaat voor toegang tot alle MCP-servers. En server discovery, waarbij een agent automatisch kan detecteren of een website of systeem een MCP-endpoint aanbiedt.

Eén ding dat Soria Parra nadrukkelijk afraadt: een REST API één-op-één omzetten naar een MCP-server. Het resultaat is technisch werkend maar agent-onvriendelijk. Ontwerp in plaats daarvan vanuit hoe een agent de taak uitvoert, niet vanuit hoe de API is gebouwd.

De technische infrastructuur is er, de organisatorische nog niet

MCP lost het verbindingsprobleem op. Wat het niet oplost is de vraag wie er regie over voert. Vertrouwen en governance zijn het volgende protocol dat gebouwd moet worden, en dat is geen softwareprobleem.

Organisaties die nu nadenken over welke systemen ze openstellen voor agenten, wie dat beheert en hoe ze omgaan met fouten, bouwen een voorsprong op die later moeilijk in te halen is. Niet omdat de technologie zo complex is, maar omdat de organisatorische gewoonten tijd kosten om te vormen.

Wil je weten hoe je die governance concreet inricht voor jouw organisatie? Plan een kennismaking in.