MCP is een open standaard waarmee een model externe tools en databronnen kan ontdekken en aanroepen via één enkele, consistente interface.
Wat is MCP?
MCP staat voor Model Context Protocol. Het is een open standaard die beschrijft hoe een taalmodel te weten komt welke tools het ter beschikking heeft, en hoe het die aanroept.
Het probleem dat het aanpakt, is weinig spectaculair maar duur. Voordat er een standaard bestond, was elke koppeling tussen een model en een bedrijfssysteem maatwerkcode. Verbind drie modellen met vijf systemen en u hebt vijftien bruggen geschreven, elk met zijn eigenaardigheden, zijn authenticatie en zijn onderhoudslast. Verander van modelleverancier en u begint opnieuw.
MCP maakt daar een client-serverarchitectuur van. Een server kondigt aan wat hij aanbiedt: tools die acties uitvoeren, resources die data leveren, prompts die een taak kaderen. Elke compatibele client kan die vervolgens gebruiken zonder iets te weten over de implementatie die erachter zit.
Waarom MCP ertoe doet
- Integratie vermenigvuldigt zich niet langer. De inspanning volgt het aantal tools, niet de tools vermenigvuldigd met de modellen. Op een geheel van interne systemen is dat het verschil tussen een pilot en iets wat onderhoudbaar is.
- Van leverancier veranderen is geen herschrijving meer. Als het model verandert, blijven de servers. Dat alleen al neemt een van de belangrijkste bezwaren weg om in AI-integratie te stappen.
- Rechten worden expliciet. Elke tool kondigt zijn inputs en outputs aan, waardoor de afbakening een ontwerpbeslissing wordt die zwart op wit staat in plaats van een veronderstelling die in de code begraven ligt.
- Hergebruik wordt reëel. Een server die voor een intern systeem geschreven is, dient alle toekomstige assistenten en agents, in plaats van alleen gebruikt te worden door het ene project dat hem gefinancierd heeft.
Het strategische punt is dat MCP van AI-integratie een infrastructuurbeslissing maakt in plaats van een reeks experimenten. Dat verandert wie mee aan tafel moet zitten wanneer u ze plant.
Hoe het werkt
Drie concepten dragen het grootste deel van de standaard.
Tools zijn acties die het model kan aanroepen: een record lezen, een factuur aanmaken, een bericht versturen. Elke tool kondigt aan wat hij aanvaardt en wat hij teruggeeft, waardoor het model kan redeneren over de vraag of het zinvol is hem aan te roepen.
Resources zijn data die het model kan lezen in plaats van wijzigen: een document, een tabel, een bestand. Het onderscheid telt omdat het lezen scheidt van wijzigen, en dat is de eerste lijn van elk redelijk rechtenmodel.
Prompts zijn herbruikbare taaksjablonen die een server kan aanbieden, zodat een beproefde manier om iets te vragen niet door elke client opnieuw uitgevonden moet worden.
Daaromheen beheert een server de authenticatie en beslist hij wat hij beschikbaar stelt. De client, die een chatinterface of een agent kan zijn, ontdekt wat beschikbaar is en roept het aan. Er wordt niets verondersteld over het model, en net daarom overleeft de opzet een verandering van leverancier.
Het werk in een echt project is niet de server schrijven. Het is de scope bepalen: welke leesacties toegestaan zijn, welke schrijfacties een bevestigingsstap vereisen, wat er gebeurt wanneer een aanroep mislukt, en hoe elke aanroep gelogd wordt. Een te ruim gedefinieerde tool is de belangrijkste bron van onvoorspelbaar gedrag.
Implementatie
- Begin met één enkel systeem dat meerdere toekomstige toepassingen nodig zullen hebben, typisch het systeem dat de klant- of productdata bevat.
- Lijst de acties op voordat u een regel code schrijft. Elke actie moet één ding doen met een voorspelbaar resultaat.
- Scheid leesacties van schrijfacties en geef elke tool de smalste rechten waarmee hij kan werken.
- Vereis een bevestiging voor elke schrijfactie met gevolgen voor een persoon, een contract of een factuur.
- Log elke aanroep met zijn inputs, zijn resultaat en zijn aanroeper. Zonder dat is debuggen gissen en is een audit onmogelijk.
- Behandel het protocol als een adapter. Houd de bedrijfslogica erachter, zodat een toekomstige verandering van standaard u alleen de adapter kost.
Gerelateerde technologieën en tools
- Toolaanroepen: de onderliggende capaciteit van modellen die MCP standaardiseert en overdraagbaar maakt van de ene leverancier naar de andere.
- API-gateways: de laag die de authenticatie en rate limiting al beheert, en waarachter een MCP-server zich zou moeten plaatsen in plaats van ze te vervangen.
- Lagen voor documentzoeken: vaak beschikbaar gesteld als MCP-resources, zodat een model de documenten van het bedrijf leest via dezelfde interface als al de rest.
- Observability: het traceren van elke toolaanroep, waardoor de opzet auditeerbaar wordt in plaats van ondoorzichtig.
- Identiteits- en secretbeheer: per tool afgebakende credentials, zodat geen enkele component brede toegang tot alles heeft.
Conclusie
MCP is leidingwerk, en leidingwerk is de plek waar AI-projecten slagen of vastlopen. Het interessante werk lijkt te zitten in de keuze van het model en het ontwerp van de prompts, maar de kost zit in de integratie, en het is de integratie die een standaard wegneemt.
De redelijke aanpak is om het als infrastructuur te behandelen: een correct beschikbaar gesteld systeem, strak afgebakende acties, bevestigde schrijfacties, alles gelogd, de bedrijfslogica achter de adapter gehouden. Zo gebouwd erft elke nieuwe assistent of agent wat al bestaat, in plaats van dezelfde koppelingen opnieuw te betalen.