MCP-servers bouwen voor enterprise AI

Enterprise AI heeft een integratieprobleem. Geen modelprobleem - de modellen zijn goed genoeg. Geen dataprobleem - de meeste bedrijven hebben meer data dan ze weten te gebruiken. Het probleem is het verbinden van AI met de systemen die het bedrijf daadwerkelijk draaiende houden. Elke nieuwe AI-applicatie heeft toegang nodig tot je ERP, je CRM, je documentopslag, je interne API's. En al die koppelingen betekenden tot voor kort: custom code.

Heb je drie AI-applicaties en vijf backend-systemen, dan zijn dat vijftien unieke integraties. Komt er een zesde systeem bij? Weer drie erbij. Wissel je van modelprovider? Alles opnieuw bouwen. Dit is het N×M-integratieprobleem, en het maakt al jaren stilletjes enterprise AI-projecten kapot.

Het Model Context Protocol (MCP) verandert die vergelijking. Oorspronkelijk uitgebracht door Anthropic als open-source standaard en nu beheerd via een open specificatie, biedt MCP een universele interface tussen AI-applicaties en externe systemen. Bouw één MCP-server voor je ERP, en elke MCP-compatibele AI-host - Claude, ChatGPT, VS Code, je eigen custom agent - kan ermee verbinden. Het N×M-probleem wordt N+M.

Zie het als USB-C voor AI. Vóór USB-C had elk apparaat zijn eigen connector. MCP geeft AI-integraties diezelfde standaardisatie: één protocol, universele connectiviteit.

De MCP-architectuur

MCP volgt een client-server-architectuur met vier kerndeelnemers en twee communicatielagen.

Hosts, clients en servers

Een MCP host is elke AI-applicatie die met externe systemen moet communiceren - Claude Desktop, VS Code met Copilot, of je eigen LangGraph-gebaseerde agent. De host maakt voor elke server een MCP client aan. De client beheert de verbindingslevenscyclus: initialisatie, capability-onderhandeling en de lopende request-response-uitwisseling. Een MCP-server is het programma dat de mogelijkheden van je enterprise-systeem beschikbaar maakt voor de AI-wereld. Het is de brug tussen je SAP-instantie en elke AI-agent die er query's op wil uitvoeren.

Deze scheiding is belangrijk. De host hoeft niets te weten over hoe je database werkt. De server hoeft niet te weten welk AI-model de vragen stelt. De client is de tussenpersoon die beide talen spreekt.

Transports: lokaal en remote

MCP ondersteunt twee transportmechanismen. Het stdio transport start de server als een subprocess - de client schrijft JSON-RPC-berichten naar stdin en leest antwoorden van stdout. Geen netwerkoverhead, ideaal voor lokale tools. Het Streamable HTTP transport draait de server als een onafhankelijke HTTP-service die meerdere clientverbindingen aankan, met POST-requests voor client-naar-server-berichten en optionele Server-Sent Events voor streaming. Dit is het transport dat je gebruikt voor enterprise-deployments - het schaalt, ondersteunt standaard HTTP-authenticatie en kan achter je bestaande API-gateway zitten.

Onder de motorkap gebruiken beide transports hetzelfde JSON-RPC 2.0 berichtformaat. Je servercode verandert niet als je van transport wisselt - alleen de bedrading.

De drie primitieven: Resources, Tools en Prompts

Alles wat een MCP-server kan doen valt in drie categorieën. Het begrijpen van deze primitieven is de sleutel tot het ontwerpen van een goede server.

Resources: passieve data voor context

Resources zijn read-only databronnen die context bieden aan de AI-applicatie. Ze worden bestuurd door de applicatie, niet door het model - de host bepaalt welke resources worden opgehaald en wanneer ze in het gesprek worden opgenomen. Elke resource heeft een unieke URI en een gedeclareerd MIME-type.

Resources bestaan in twee smaken: directe resources met vaste URI's (zoals erp://schema/orders) en resource templates met parameters (zoals crm://contacts/{department}). In een enterprise-context zijn resources de manier om databaseschema's, configuratiedocumenten, kennisbankartikelen of andere referentiedata beschikbaar te stellen voor grounding.

Tools: acties die het model kan uitvoeren

Tools zijn uitvoerbare functies die het AI-model kan aanroepen. Anders dan resources worden tools bestuurd door het model - het LLM besluit wanneer het ze aanroept op basis van het verzoek van de gebruiker. Elke tool heeft een naam, een beschrijving en een JSON Schema dat de inputparameters definieert.

Hier wordt het krachtig - en hier worden enterprise-overwegingen cruciaal. Een tool kan een order aanmaken in SAP, een contact bijwerken in Salesforce, of een inkoopverzoek goedkeuren. Tools zijn acties met consequenties, en daarom benadrukt MCP menselijk toezicht: goedkeuringsdialogen, rechtenbeheer en activiteitenlogboeken zijn onderdeel van het ontwerp.

Prompts: herbruikbare interactietemplates

Prompts zijn vooraf gebouwde instructietemplates die het AI-model begeleiden in het werken met specifieke tools en resources. Ze worden door de gebruiker gestuurd - een gebruiker selecteert een prompt om de interactie te structureren. Zie prompts als recepten: "Vat de salespipeline van dit kwartaal samen" of "Stel een inkooporder op op basis van deze aanvraag." Ze combineren systeeminstructies, few-shot voorbeelden en verwijzingen naar beschikbare tools en resources tot een samenhangende workflow.

Voor enterprise-gebruik zijn prompts stilletjes belangrijk. Ze coderen institutionele kennis - de specifieke manier waarop jouw organisatie het datawarehouse bevraagt, het format dat compliance verwacht voor auditrapporten, de stappen in een inkoopworkflow. Ze maken stammkennis om tot herbruikbare AI-instructies.

Een MCP-server bouwen: een conceptuele walkthrough

Laten we doorlopen hoe het bouwen van een MCP-server er in de praktijk uitziet. Stel dat je AI-agents toegang wilt geven tot het orderbeheersysteem van je bedrijf.

Stap 1: Definieer je primitieven. Begin met het mappen van de mogelijkheden van je systeem naar MCP-primitieven. Welke data moet de AI kunnen lezen? Dat zijn resources. Welke acties moet het kunnen uitvoeren? Dat zijn tools. Welke workflows moet het ondersteunen? Dat zijn prompts.

Voor een orderbeheersysteem zou je het volgende kunnen blootstellen:

• Resources: Orderschema, productcatalogus, klantsegmenten, voorraadniveaus
• Tools: Orders zoeken, order aanmaken, orderstatus bijwerken, factuur genereren
• Prompts: "Verwerk een retour"-workflow, "Kwartaalanalyse orders"-template, "Leverancier herbestelling"-checklist

Stap 2: Kies je SDK en transport. De officiële MCP SDK's zijn beschikbaar in TypeScript en Python. De TypeScript SDK (@modelcontextprotocol/server) wordt geleverd met middleware-packages voor Express, Hono en raw Node.js HTTP - waardoor het eenvoudig te integreren is in bestaande backend-stacks. Voor enterprise-deployments gebruik je vrijwel zeker het Streamable HTTP transport, zodat de server als standalone service achter je infrastructuur kan draaien.

Stap 3: Implementeer de handlers. Elk primitief-type heeft gestandaardiseerde methoden: tools/list en tools/call voor tools, resources/list en resources/read voor resources, prompts/list en prompts/get voor prompts. Je server registreert handlers voor deze methoden. Wanneer een client tools/list aanroept, retourneert je server de catalogus van beschikbare tools met hun JSON Schema-definities. Bij tools/call met specifieke parameters voert je server de bedrijfslogica uit - je database bevragen, een interne API aanroepen, wat de operatie ook vereist - en stuurt het resultaat terug.

Stap 4: Levenscyclusbeheer. MCP is een stateful protocol. Clients en servers onderhandelen over capabilities tijdens initialisatie - je server declareert welke primitieven het ondersteunt, de client declareert wat het aankan. Deze capability-onderhandeling betekent dat servers kunnen evolueren zonder oudere clients te breken, en clients zich kunnen aanpassen aan servers met verschillende featuresets.

De SDK's abstraheren het meeste protocolwerk. Jouw taak is definiëren wat je systeem kan doen en de bedrijfslogica schrijven die het mogelijk maakt.

Enterprise-overwegingen: waar het serieus wordt

Een demo MCP-server bouwen kost een middag. Eén bouwen die productiewaardig is voor een enterprise-omgeving kost aanzienlijk meer denkwerk. Dit is wat een proof-of-concept onderscheidt van een systeem dat je CISO goedkeurt.

Authenticatie en autorisatie

De MCP-specificatie bevat een volledig OAuth 2.1-gebaseerd autorisatieraamwerk voor HTTP-transports. Servers kunnen bearer tokens vereisen, dynamische clientregistratie ondersteunen (zodat nieuwe AI-applicaties kunnen verbinden zonder handmatige setup), en integreren met je bestaande identity provider. De specificatie ondersteunt zowel authorization code grants (wanneer een menselijke gebruiker betrokken is) als client credentials grants (voor service-to-service communicatie).

Maar authenticatie is slechts het begin. In productie heb je fijnmazige autorisatie nodig: welke gebruiker toegang heeft tot welke tools, welke resources beschikbaar zijn voor welke rollen, wat er gebeurt wanneer iemand een tool probeert aan te roepen waar die geen toegang toe zou moeten hebben. Hier moet je MCP-server integreren met je bestaande RBAC- of ABAC-systeem, niet er eentje opnieuw uitvinden.

Audit trails en observability

Elke tool-aanroep via je MCP-server is een actie op een productiesysteem. Je moet loggen wie wat heeft aangeroepen, wanneer, met welke parameters en wat het resultaat was. Dit is niet alleen goede praktijk - het is een wettelijke vereiste onder frameworks als de EU AI Act en SOC 2. Je MCP-server moet gestructureerde logs en traces uitzenden (OpenTelemetry is de logische keuze) die in je bestaande observability-stack terechtkomen.

Permissiegrenzen en menselijk toezicht

MCP is ontworpen met menselijk toezicht in gedachten. Tools kunnen expliciete gebruikersgoedkeuring vereisen vóór uitvoering. Je kunt tools categoriseren op risiconiveau - read-only query's worden automatisch uitgevoerd, terwijl schrijfoperaties bevestiging vereisen. Voor high-stakes acties (een inkooporder goedkeuren, klantgegevens wijzigen) kun je meerstaps-goedkeuringsworkflows implementeren die de uitvoering pauzeren totdat een mens akkoord geeft. Dit is geen beperking van het protocol; het is een feature die enterprise-adoptie realistisch maakt.

Datafiltering en PII-bescherming

Je MCP-server zit tussen het AI-model en je data. Dat maakt het de natuurlijke plek om datagovernance te implementeren: PII redacteren voordat het bij het model komt, resultaten filteren op basis van het clearanceniveau van de gebruiker, en ervoor zorgen dat gevoelige velden nooit je infrastructuur verlaten. Als je AI-host verzoeken stuurt naar een cloud-gebaseerd model, is de MCP-server je laatste verdedigingslinie voor datasoevereiniteit.

MCP vs custom API-integraties

Je denkt misschien: waarom niet gewoon een REST API bouwen en de AI die laten aanroepen? Dat kan. Mensen doen het. Maar er zitten echte kosten aan die aanpak.

Custom integraties zijn per definitie maatwerk. Elke heeft zijn eigen authenticatieschema, zijn eigen foutafhandeling, zijn eigen manier om capabilities aan het model te beschrijven. Wissel je van AI-provider of voeg je een nieuwe AI-applicatie toe, dan begin je van voren af aan. Er is geen discoverability - de AI weet niet wat je API kan totdat je het handmatig beschrijft in een systeemprompt of tooldefinitie.

MCP geeft je gestandaardiseerde capability discovery (clients roepen tools/list, resources/list, prompts/list aan), gestandaardiseerde uitvoering (tools/call met JSON Schema-validatie), gestandaardiseerd levenscyclusbeheer en gestandaardiseerde auth. Je tooling - debuggers zoals de MCP Inspector, clientbibliotheken, observability-integraties - werkt voor al je MCP-servers. Je schrijft het één keer, test het één keer, en het werkt met elke conforme host.

De trade-off is dat MCP een abstractielaag toevoegt. Voor een enkele, strak gekoppelde integratie is een directe API-aanroep eenvoudiger. Maar zodra je meer dan één AI-applicatie hebt, meer dan één backend-systeem, of enige verwachting dat een van beide kanten zal veranderen - verdient MCP zichzelf snel terug.

Praktijkvoorbeelden

Waar komt dit in de praktijk terecht? Dit zijn de patronen die we het vaakst zien in enterprise-omgevingen.

ERP-integratie. Een MCP-server die SAP of Microsoft Dynamics wrapt, laat AI-agents orderstatus opvragen, voorraadniveaus controleren en inkooporders aanmaken - allemaal via natuurlijke taal. De server stelt het databaseschema van het ERP bloot als resource, orderoperaties als tools, en veelvoorkomende workflows zoals "versnel een vertraagde zending" als prompts. Financiële teams werken met complexe ERP-data zonder de ERP-interface te hoeven leren.

CRM en Sales Intelligence. Een Salesforce- of HubSpot MCP-server geeft AI-agents toegang tot de volledige klantrelatie-levenscyclus. Resources stellen pipelinedata en klantinteractiegeschiedenis beschikbaar. Tools maken contactupdates, opportunity-creatie en meetingplanning mogelijk. Prompts templaten veelvoorkomende analyses zoals "bereid een kwartaalgesprek voor met klant X."

Documentbeheer en kennisbanken. SharePoint, Confluence of custom documentrepositories worden AI-toegankelijk via MCP-servers die documenten als resources beschikbaar stellen (met full-text search als tool) en veelvoorkomende workflows als prompts. De server handelt permissiemapping af - zodat de AI alleen documenten kan benaderen waarvoor de aanvragende gebruiker geautoriseerd is.

Interne tooling en DevOps. MCP-servers voor GitHub, Jira of CI/CD-platforms laten engineeringteams AI gebruiken om issues te triagen, pull requests te reviewen of deployment-fouten te debuggen - met de AI die directe toegang heeft tot logs, metrics en code-repositories via gestandaardiseerde interfaces.

Hoe Laava productie-MCP-servers bouwt

Bij Laava past MCP-serverontwikkeling natuurlijk in onze drielagenarchitectuur voor enterprise AI. De MCP-server leeft in de Action-laag - het is het integratiepunt waar AI-redenering echte systemen ontmoet. Maar een goede MCP-server heeft ook de Context-laag nodig (welke data blootstellen, hoe structureren) en de Reasoning-laag (welke prompts aanbieden, hoe tools samengesteld worden tot workflows).

Onze aanpak is bewust saai. We gebruiken TypeScript voor de servercode omdat het past bij onze stack en het ecosysteem van enterprise-backendsystemen waarmee we integreren. We deployen op Kubernetes omdat MCP-servers schaalbaar, observeerbaar en onafhankelijk deploybaar moeten zijn. We koppelen OAuth 2.1 aan de bestaande identity provider van de klant - geen schaduw-authsystemen. We instrumenteren alles met OpenTelemetry zodat elke tool-aanroep in het observability-platform van de klant verschijnt.

We bouwen MCP-servers ook standaard model-agnostisch. Dezelfde server werkt of de host nu Claude, Llama, Mistral of een fine-tuned domeinmodel draait. Dat is precies het punt van een standaardprotocol - en het sluit aan bij onze bredere overtuiging dat enterprise AI-architectuur nooit aan één leverancier gekoppeld moet zijn.

Een typisch traject begint met een vierwekelijkse Proof of Pilot: we nemen één enterprise-systeem, bouwen er een MCP-server voor, verbinden het met het AI-platform naar keuze van de klant, en bewijzen waarde in productie - niet in een sandbox. Aan het eind heeft de klant een werkende integratie en een helder beeld van hoe opschalen naar extra systemen eruitziet.

Vooruitkijken

MCP is nog jong, maar de richting is duidelijk. Het ecosysteem groeit snel - grote AI-platforms adopteren het als standaard, de specificatie rijpt met enterprise-grade auth en transportmechanismen, en de community van open-source MCP-servers dekt een steeds breder scala aan systemen. De organisaties die hun integratielaag vandaag op MCP bouwen, hebben een significante voorsprong wanneer AI-agents de primaire interface naar enterprise-software worden.

De integratielaag hoeft niet de plek te zijn waar AI-projecten sterven. Met MCP kan het de plek zijn waar ze tot leven komen.

Wil je je enterprise-systemen via MCP aan AI koppelen? Wij kunnen helpen. Lees meer over onze MCP Server Development services of neem contact op om je specifieke integratieuitdagingen te bespreken.