Stel u een groothandel voor met vierhonderd orders per week. Iemand op de klantenservice krijgt twintig keer per dag de vraag of een order verzonden is. Het antwoord staat in het ERP. Opzoeken kost negentig seconden: systeem openen, order zoeken, status bekijken, antwoord typen. Negentig seconden, twintig keer per dag, is bijna een uur.
Een AI-assistent zou die vraag meteen kunnen beantwoorden, als hij het ERP kon zien. Dat kan hij niet. En het werk om hem dat wél te laten zien is waar dit artikel over gaat, want juist daar — niet bij het AI-deel — lopen bedrijfsprojecten stil.
Wat een koppeling is, en waarom het er zoveel worden
Als iemand zegt dat een assistent "gekoppeld" is aan een systeem, bedoelt hij dat er software tussen beide zit. Die ontvangt een verzoek van de assistent, vertaalt dat naar wat het systeem begrijpt, haalt een antwoord op en vertaalt dat terug naar iets wat de assistent kan lezen. Dat stuk software is een koppeling.
Zo'n koppeling schrijven is niet bijzonder moeilijk. Het probleem is dat u er van oudsher één nodig had per combinatie. Een koppeling geschreven voor de ene assistent sprak het dialect van díe assistent. Richt een andere assistent op hetzelfde ERP en u schreef hem opnieuw.
Terug naar de groothandel. Stel dat de ERP-koppeling gebouwd wordt en werkt. Dan gaat de financiële afdeling een andere assistent gebruiken, dus die heeft een eigen koppeling nodig. Dan wil iemand ook voorraadstanden uit het magazijnsysteem, in beide assistenten. Vier koppelingen inmiddels, voor twee systemen, en elk ervan gaat apart stuk als een leverancier zijn API wijzigt.
Dat is de vorm van het probleem. Twee assistenten en twee systemen zijn vier koppelingen. Drie assistenten en zes systemen zijn er achttien. Het aantal groeit met vermenigvuldiging; het team dat het onderhoudt niet.
Wat MCP werkelijk is
MCP staat voor Model Context Protocol. Het is een open standaard — een gepubliceerde afspraak over hoe berichten opgebouwd worden — die Anthropic in november 2024 introduceerde en later onderbracht bij een leveranciersneutrale stichting.
Het woord protocol verdient precisie, want daar zit het nut. Een protocol is geen product dat u koopt of een dienst waarop u zich abonneert. Het is een gedeelde set regels, zoals de afspraak waardoor elke waterkoker in elk stopcontact past. Niemand verkoopt u "de stopcontactstandaard". Iedereen bouwt ernaartoe, en het past.
MCP koppelt dus uit zichzelf niets. Wat het doet, is één dialect vastleggen. U schrijft een koppeling die MCP spreekt — dat heet een MCP-server — en elke assistent die ook MCP spreekt, kan hem gebruiken. Eén per systeem, in plaats van één per combinatie.
Voor de groothandel zijn dat twee servers in plaats van vier, en het blijven er twee als er een derde assistent bij komt.
De drie dingen die een server kan aanbieden
Een MCP-server biedt functionaliteit in precies drie vormen aan. Bijna al het andere in MCP is detail; dit onderscheid is het deel om vast te houden, want de rest van deze reeks komt er steeds op terug.
Tools — dingen die de assistent kan dóen
Een tool is een actie met een naam, een beschrijving en een vastgelegde set invoervelden. Zoiets als controleer_orderstatus, die een ordernummer aanneemt en een status teruggeeft. De assistent bepaalt wanneer hij hem gebruikt, op basis van wat iemand vraagt.
Tools zijn de krachtige én de riskante, want een tool doet iets. Een tool die een order opzoekt is ongevaarlijk. Een tool die er een annuleert niet, en dat verschil ontwerpt u liever dan dat u het ontdekt.
Resources — informatie die de applicatie aanreikt
Een resource is inhoud die uw applicatie voor de assistent neerlegt: een document, een record, het resultaat van een query. Het verschil met tools zit in wie kiest. Bij een tool besluit de assistent ernaar te grijpen. Bij een resource heeft uw applicatie al besloten dat de assistent dit moet zien.
Prompts — opgeslagen instructies die iemand kiest
Een prompt is een herbruikbare, goed geformuleerde taak die een gebruiker bewust selecteert, meestal uit een menu. "Stel een mail op over vertraagde levering voor deze order" is een prompt. Het is het opgeslagen rapport van de MCP-wereld: elke keer dezelfde formulering, in plaats van dat elke collega zijn eigen versie verzint en net andere uitkomsten krijgt.
Wat er werkelijk gebeurt als iemand iets vraagt
Het helpt om één verzoek helemaal te volgen, want die volgorde verklaart een paar dingen die anders willekeurig lijken.
Een collega typt: is order 44821 verzonden? De assistent — de applicatie die de persoon gebruikt, in MCP-termen de host — heeft al te horen gekregen welke servers beschikbaar zijn en welke tools elk daarvan aanbiedt.
Hij herkent dat de vraag past bij de beschrijving van controleer_orderstatus, en dat die tool een ordernummer nodig heeft, dat in het bericht staat. Hij stuurt een verzoek naar de ERP-server om die tool met dat nummer uit te voeren.
De server doet het oninteressante deel. Hij authenticeert bij het ERP, doet de query, krijgt een regel terug en geeft een klein, net resultaat terug: verzonden, 29 juli, track-en-tracenummer. Alleen dat resultaat gaat terug naar de assistent, die er een zin van maakt.
Twee details uit die volgorde tellen later. Ten eerste raakte de assistent het ERP nooit rechtstreeks aan; hij vroeg alleen iets aan de server. Ten tweede reisde alleen het antwoord terug, niet het hele klantrecord. Beide zijn keuzes die u maakt bij het bouwen van de server, en beide zijn waar de beveiligings- en kostenafwegingen verderop in deze reeks vandaan komen.
Waar de server draait
Een MCP-server is een klein programma, en dat moet ergens draaien. Er zijn twee gebruikelijke opstellingen, en de keuze is praktischer dan technisch.
Hij kan draaien op dezelfde computer als de persoon die hem gebruikt. Er staat niets open op het netwerk, de data verlaat de machine niet, en het opzetten is bijna triviaal. Dat past bij werk dat bij één specialist hoort, bijvoorbeeld een controller die cijfers afstemt. In MCP-termen is dit het stdio-transport, wat simpelweg betekent dat de twee programma's met elkaar praten via dezelfde leidingen die een opdrachtregelprogramma gebruikt om iets af te drukken.
Of hij draait als een gewone webdienst waar een heel team verbinding mee maakt. U krijgt één plek voor toegangsregels, één plek die vastlegt wat er gebeurde, en één kopie om bij te werken. Toegang loopt hier via OAuth: hetzelfde mechanisme achter "inloggen met"-knoppen, waarbij u een applicatie toestemming geeft zonder ooit uw wachtwoord af te staan.
Eén ding om meteen goed te hebben: de huidige specificatie is 2026-07-28, de revisie die MCP stateless maakte. In gewone taal: een gesprek zit niet langer vast aan één specifieke serverinstantie, waardoor een gedeelde server op gewone webhosting achter een gewone load balancer draait. Daarmee verdween de belangrijkste operationele reden waarom kleinere bedrijven de gedeelde variant meden, en het betekent dat alles wat u leest over een opstart-handshake en een sessie-identificatie van vóór die revisie dateert.
Drie dingen die MCP niet voor u doet
Het maakt een zwakke assistent niet bekwaam. Kan het model niet redeneren over uw proces, dan geeft een nette koppeling hem vooral sneller toegang tot dingen die hij nog steeds verkeerd begrijpt.
Het bepaalt niet wat iemand mag. Een server werkt met precies de toegang die u hem geeft, en gebruikt die volledig zodra het gevraagd wordt. Niets in het protocol houdt een slecht afgebakende server tegen om efficiënt schade aan te richten, en daarom gaat deel vier over rechten.
En het bedenkt uw proces niet voor u. Een tool die keur_factuur_goed heet, moet vastleggen wat goedkeuren in uw bedrijf werkelijk betekent — inclusief de uitzonderingen die in het hoofd van één persoon zitten en in geen enkel document staan. Dat denkwerk verdwijnt niet. MCP bepaalt alleen hoe het resultaat wordt aangeboden nadat u het gedaan heeft.
Wanneer het de moeite is, en wanneer niet
De eerlijke toets is of u van één van beide er meer dan één heeft. Eén assistent en één systeem: bouw de directe verbinding, dat is eenvoudiger. Zodra er twee assistenten zijn, of drie systemen, begint de rekensom in het voordeel van MCP te werken en dat blijft zo.
Het Nederlandse beeld maakt het scherper. Het CBS meldt dat 22,7% van de bedrijven met tien of meer medewerkers in 2024 AI gebruikte, en dat 57% gebrek aan eigen kennis en vaardigheden als grootste obstakel noemt. Dat tweede getal is de echte rem. Het is zelden animo of budget dat dit werk tegenhoudt; het is dat niemand de uren heeft om een stapel eenmalige koppelingen te bouwen en daarna in leven te houden.
Eén keer bouwen en hergebruiken is precies de soort oplossing die een klein team volhoudt. Het is saaie infrastructuur, en saaie infrastructuur is wat blijft bestaan.
Wat MCP niet redt, is de verkeerde procesbeslissing. Weet u nog niet welke klus u hiermee aanpakt, begin dan bij welk proces u als eerste automatiseert en kom terug voor de techniek zodra dat helder is.
Gaat onze data dan het pand uit?
Dit is de eerste vraag die de meeste mensen stellen, en het antwoord heeft twee helften die makkelijk door elkaar lopen.
MCP zelf stuurt niets ergens heen. Het is een set regels voor het opbouwen van berichten, geen dienst die ertussen zit. Een server kan volledig binnen uw eigen netwerk draaien en het publieke internet nooit raken.
Wat wél reist, is wat de assistent nodig heeft om te antwoorden, en dat hangt af van welk model de assistent gebruikt en wat uw tools teruggeven. Geeft uw tool een status van één regel terug, dan is die ene regel alles wat ergens heen gaat. Geeft hij het hele klantrecord terug, dan gaat het hele record.
Daarom herhaalt het ontwerpadvies in deze reeks zichzelf: geef het antwoord terug, niet het ruwe materiaal. Het is goedkoper, het is sneller, en het is het verschil tussen een kort gesprek met uw FG en een lang gesprek.
De korte versie
MCP is een gedeeld dialect waardoor één koppeling elke assistent bedient. Een server biedt tools die de assistent kan uitvoeren, resources die uw applicatie aanreikt, en prompts die een mens kiest. Hij draait op één machine of als gedeelde dienst, en sinds de revisie van juli 2026 is die gedeelde variant gewone webhosting.
Het bespaart u het steeds opnieuw schrijven van dezelfde integratie. Het neemt geen beslissingen over rechten, het begrijpt uw proces niet, en het maakt een middelmatige assistent niet goed.
Wat hierna komt
Deel 2 wordt praktisch: MCP koppelen aan de systemen die u al draait, inclusief welk systeem u als eerste verpakt en waarom de vorm van uw tools zwaarder weegt dan welke technische keuze dan ook.
Deel 3 voelen de meeste bedrijven meteen: spreadsheet- en datawerk automatiseren, en waarom een assistent een live werkboek geven het patroon is dat slecht afloopt.
Deel 4 gaat over beveiliging en rechten, inclusief de storing waarbij een document de assistent stilletjes instructies geeft.
Deel 5 is het in productie draaien: hosting, versies, kosten en wat er werkelijk stukgaat.
En wilt u dit liever tegen uw eigen systemen laten uitzoeken dan vijf artikelen lezen, dan is daar een AI-audit voor.
