Model Context Protocol: hoe MCP tool-integratie standaardiseert

Voor wie? Developers die AI-agents of LLM-gebaseerde applicaties bouwen en merken dat elke tool-integratie zijn eigen formaat, transport en authenticatiemechanisme vereist — en die willen begrijpen wat MCP daaraan verandert.

Kort: Het Model Context Protocol geeft je een gemeenschappelijke taal tussen een AI-applicatie en externe tools of databronnen. Je schrijft de integratie één keer; elk MCP-compatibel systeem kan hem gebruiken. Dit artikel legt het mechanisme uit — de concepten die we in de tweedaagse workshop voor developers hands-on doorwerken.

Stel: je bouwt een agent die interne databaseresultaten ophaalt, acties uitvoert via een externe API, en via een IDE-plugin toegankelijk is voor je team. Zonder standaard schrijf je drie integraties. Elk met hun eigen formaat voor tool calls, hun eigen transportlaag, hun eigen authenticatiestructuur. En als je morgen wil overstappen naar een ander taalmodel of een andere IDE, begin je opnieuw.

Dit was de situatie vóór november 2024. Elke tool-integratie was proprietary. Je schreef voor Cursor iets anders dan voor Claude Desktop, iets anders dan voor je eigen orchestration-laag. De tools werden beter, maar de integratieproblemen stapelden zich op.

MCP — het Model Context Protocol, gepubliceerd door Anthropic, inmiddels beheerd door de Linux Foundation — is de standaard die dat oplost. Niet als marketingbelofte, maar als architectuurkeuze met een concreet mechanisme.

Hoe het client-server model werkt

MCP is gebouwd op een client-server architectuur met drie rollen.

De MCP host is de AI-applicatie zelf: Claude Desktop, een IDE-plugin zoals Cursor, of een eigen agent die je schrijft. De host beslist wanneer hij een tool aanroept en wat hij met het resultaat doet.

De MCP server is het proces dat tools, data en prompts aanbiedt. Je schrijft één server voor je interne database, en die server werkt met elke host die het protocol spreekt.

De communicatie loopt via JSON-RPC 2.0: lokaal via stdio (het host-proces start de server als subprocess), over een netwerk via HTTP met Server-Sent Events. De transportkeuze is pragmatisch — lokale servers draaien als gewone processen, geen cloud-setup nodig voor een eerste integratie.

Drie typen primitieven

Een MCP-server biedt drie soorten capabilities aan.

Tools zijn acties: functies met een naam, een beschrijving, en een JSON-schema dat de input-parameters beschrijft. Een tool kan een database-query uitvoeren, een bestand aanmaken, een HTTP-request sturen. De agent beslist op basis van de beschrijving welke tool hij aanroept voor een gegeven taak — de beschrijving is de interface, niet de implementatie.

Resources zijn data die de agent kan lezen: bestanden, databaseresultaten, API-responses. Het onderscheid met tools is intentioneel: resources zijn passief leesbaar, tools voeren acties uit. Dat scheiding houdt de server begrijpelijk voor de host.

Prompts zijn herbruikbare templates met parameters. Een team kan gedeelde instructiepatronen in een MCP-server stoppen en ze consistent beschikbaar stellen aan elke host.

Bij de eerste verbinding voert de host een discovery-handshake uit: de server stuurt terug welke tools, resources en prompts hij aanbiedt, inclusief hun schema’s. De host weet daarna precies wat beschikbaar is, zonder hardcoded kennis van de server.

Wat je er concreet mee wint

De winst zit in de ontkoppeling.

Je schrijft je databaseintegratie als MCP-server. Diezelfde server is bruikbaar in Claude Desktop, in Cursor, in de agent die je zelf bouwt. Je hoeft niet drie keer hetzelfde te implementeren met drie verschillende formaten.

Je AI-logica en je tool-implementaties leven apart. Een agent die beslissingen neemt via een taalmodel, hoeft niets te weten over hoe de database-query precies werkt — hij roept de tool aan op naam, geeft de parameters mee, en verwerkt het gestructureerde resultaat. Dat gestructureerde resultaat is het sleutelpunt: de server geeft data terug, geen tekst die de agent opnieuw moet parsen.

Voor lokaal testen is dit direct bruikbaar: een MCP-server is een gewoon proces. Je start hem, je test hem, je debugt hem zonder dat je iets in de cloud hoeft te hebben draaien.

Bovendien hoef je voor veel veelgebruikte diensten niet zelf te beginnen. Er zijn al MCP-servers beschikbaar voor filesystem, GitHub, PostgreSQL, Slack, Jira, Linear — het ecosysteem groeide snel nadat het protocol vendor-neutraal werd.

Wat MCP niet oplost

Twee beperkingen zijn het noemen waard.

MCP is stateloos van nature. Elke tool call staat op zichzelf; de server houdt geen sessie bij. Als je agent tussensteps wil combineren of context over meerdere calls wil bewaren, is dat de verantwoordelijkheid van de host-applicatie, niet van het protocol. Je moet de state-laag zelf ontwerpen.

Een MCP-server met brede permissies is een aanvalsoppervlak. Een server die bestanden kan lezen, databases kan bevragen en externe API’s kan aanroepen, geeft ook aan een kwaadwillend prompt die permissies. Bedenk per server welke permissies hij echt nodig heeft en welke je bewust weglaat.

Tot slot: niet elke use case heeft MCP nodig. Als je agent één interne tool aanroept en je bouwt niets wat meerdere systemen of teams moeten hergebruiken, volstaat een directe function call. MCP is het meest waardevol op het moment dat je schrijfwerk begint te dupliceren over tools, hosts of teams heen.

Wat het protocol in de praktijk verandert

Het mechanisme achter MCP lijkt bescheiden: JSON-RPC, een discovery-handshake, drie primitieve typen. Maar de consequentie is dat er eindelijk een gedeelde taal bestaat tussen AI-applicaties en de rest van je infrastructuur — niet omdat één leverancier dat heeft afgedwongen, maar omdat een open standaard door genoeg partijen is aangenomen om het coördinatieprobleem op te lossen.

Anthropic, OpenAI, Google DeepMind, Microsoft en tientallen anderen ondersteunen het protocol. Dat is het moment waarop een standaard bruikbaar wordt: niet bij de aankondiging, maar wanneer de tooling, de servers en de hosts er al zijn voor je begint.

In de tweedaagse workshop voor developers schrijf je een eigen MCP-server, koppel je hem aan een agent, en werk je de architectuurkeuzes uit voor een use case uit je eigen context — inclusief state-beheer, permissiemodel en lokale testopzet.