Een MCP-server is een klein programma dat u zelf draait. Aan de ene kant spreekt hij het protocol dat assistenten begrijpen; aan de andere kant praat hij met uw bestaande systeem in de taal die dat systeem al gebruikt — meestal een web-API, soms een database, af en toe een map vol bestanden.
Er is niets voor nodig dat uw softwareleverancier ooit van MCP gehoord heeft. Dat is het bruikbare deel, en de kern van dit artikel: u kunt deze maand beginnen met de systemen die u al heeft, zonder op iemand te wachten.
Is het protocol zelf nog nieuw voor u, dan legt deel 1 uit wat MCP is, inclusief de drie soorten dingen die een server kan aanbieden. Dit deel gaat ervan uit dat die woorden bekend zijn.
Welk systeem u als eerste verpakt
De neiging is te beginnen bij het grootste systeem, want daar zit de meeste data. Meestal is dat de verkeerde keuze. Grote systemen hebben ingewikkelde rechten, meer belanghebbenden, en een langere lijst mensen die het eens moeten zijn voordat er iets verandert.
Een betere filter is de vraag over welk systeem mensen elkaar onderbreken. In de meeste bedrijven is er één waar een collega zich drie keer per dag omdraait om iemand iets te laten opzoeken. Die onderbreking is de meetbare kost, en hem wegnemen vraagt geen businesscase omdat iedereen hem al voelt.
In een Nederlands mkb-bedrijf is het meestal één van vier. Het ERP- of boekhoudpakket, want daar staan order- en factuurstatus. De gedeelde schijf of SharePoint, want daar staan de documenten die niemand kan vinden. Het order- of ticketsysteem, want daar staat waar klanten op wachten. En een rapportagedatabase die één persoon met de hand bijhoudt, want daar staan de cijfers waar de directie om vraagt.
Kies er één. Geen twee.
Wat "verpakken" feitelijk inhoudt
Het woord doet groter aan dan het is. In de praktijk schrijft u een kleine dienst met drie verantwoordelijkheden.
Hij authenticeert bij het onderliggende systeem, met een account dat u ervoor aanmaakt. Hij biedt een korte lijst benoemde acties aan de assistent. En zodra zo'n actie wordt aangeroepen, doet hij het benodigde werk tegen het systeem en geeft een net resultaat terug.
Voor onze groothandel en zijn ERP is dat misschien tweehonderd regels code. De complexiteit zit niet in de techniek. Ze zit in het bepalen wat die korte lijst acties moet zijn, en dat is de volgende paragraaf — degene die bepaalt of dit standhoudt.
Ontwerp tools rond beslissingen, niet rond endpoints
Hier gaat de eerste poging meestal mis, en de fout is begrijpelijk omdat hij op grondigheid lijkt.
De verleiding is de API van de leverancier te spiegelen. Het ERP biedt dertig endpoints, dus maakt u dertig tools: haal_klant, haal_orders, haal_orderregels, haal_facturen, haal_kredietlimiet, enzovoort. Volledige dekking. Niets vergeten.
Het presteert slecht, om een reden die de moeite is te snappen. De assistent heeft nu bij elk verzoek dertig opties, waarvan de meeste niets met de vraag te maken hebben. Erger nog: één gewone menselijke vraag beantwoorden vereist dat hij meerdere aanroepen correct aan elkaar knoopt en de resultaten combineert. Elke extra stap is een extra kans om mis te grijpen.
Beter is de beslissing ontsluiten in plaats van de mechaniek. Een collega die vraagt "kunnen we Van Dijk op rekening leveren?" stelt geen vier vragen. Hij stelt er één. Bouw dus één tool.
In plaats van vier opzoekacties, één antwoord
controleer_kredietstatus(klant) doet de vier queries intern — openstaande facturen, ouderdom, kredietlimiet, waarde van de huidige order — past de regel toe die uw bedrijf werkelijk hanteert, en geeft de conclusie terug: akkoord, of geblokkeerd met de reden.
Daar volgen drie goede dingen uit. De assistent heeft één voor de hand liggende keuze in plaats van vier onduidelijke. Uw bedrijfsregel staat in code, waar hij testbaar is en waar een collega hem kan lezen. En verandert de leverancier komend voorjaar een endpoint, dan past u één server aan in plaats van instructies in drie verschillende assistenten.
Als vuistregel dekken drie of vier tools per server het meeste echte werk. Gaat u richting de tien, dan spiegelt u waarschijnlijk opnieuw de API.
Schrijf beschrijvingen alsof het voor een nieuwe collega is
De beschrijving van een tool is geen documentatie voor ontwikkelaars. Het is de instructie die de assistent werkelijk leest bij het bepalen of dit de juiste tool is voor wat er net gevraagd werd. Vage beschrijvingen zijn veruit de meest voorkomende reden dat een tool op het verkeerde moment afgaat.
"Zoek een klant op" is zwak. Het zegt niet wat er terugkomt, wanneer u het gebruikt, of wat het niet doet.
Vergelijk: "Geeft de actuele kredietstatus van één klant terug, inclusief openstaande facturen ouder dan 30 dagen en de resterende kredietruimte. Gebruik dit vóór het goedkeuren van een nieuwe order of een levering op rekening. Alleen-lezen — maakt, wijzigt of keurt niets goed."
Die versie vertelt de assistent wanneer hij ernaar grijpt, wanneer niet, en wat hij krijgt. Het levert voorspelbaar gedrag op, en voorspelbaar gedrag is waar het om draait.
Dezelfde zorg geldt voor de invoer. Geef aan welke velden verplicht zijn. Gebruik echte types, zodat een datum een datum is. Waar de geldige waarden een bekende korte lijst vormen — orderstatus, land, afdeling — bied die lijst aan in plaats van vrije tekst te accepteren, want in vrije tekst gaat de assistent improviseren.
De feitelijke toollijst van de groothandel
Om het concreet te maken: dit is wat de ERP-server uit deel één uiteindelijk aanbiedt na de tien-vragenoefening. Vier tools, allemaal alleen-lezen, precies rond waar de klantenservice voor werd onderbroken.
controleer_orderstatus(ordernummer)
Geeft status, verzenddatum en track-en-trace terug als die er is. Dekt in zijn eentje ruwweg de helft van de onderbrekingen.
zoek_orders(klant, periode)
Geeft een korte lijst terug als de vrager het ordernummer niet heeft, en dat is meestal zo. Gemaximeerd op twintig resultaten, want een langere lijst is geen antwoord.
controleer_kredietstatus(klant)
De samengestelde beslissing van hierboven: openstaande facturen, ouderdom, ruimte, en een simpel akkoord of geblokkeerd.
controleer_voorraad(artikel, magazijn)
Actuele vrije voorraad en de eerstvolgende verwachte leverdatum. De enige tool die het magazijnsysteem raakt in plaats van het ERP, en dat is prima — een server mag met meerdere backends praten als de vraag over beide gaat.
Vier tools, geen ervan verandert iets, samen goed voor de overgrote meerderheid van de onderbrekingen in een week. Dat is een realistische eerste oplevering, en klein genoeg dat één persoon hem kan bouwen en begrijpen.
Kiezen waar hij draait
Deze beslissing is eenvoudiger dan er meestal van gemaakt wordt, en volgt uit wie de functionaliteit nodig heeft.
Op één machine, voor het werk van één persoon
De server draait als proces op dezelfde computer als de assistent, en de twee praten via standaardinvoer en -uitvoer — dezelfde leidingen die een opdrachtregelprogramma gebruikt. Er luistert niets op het netwerk, dus er valt niets per ongeluk bloot te stellen. Past bij het werk van een specialist en is de snelste route naar iets echts, vaak één middag.
Als webdienst, voor een team
De server is een gewone webapplicatie. Een team maakt er verbinding mee, toegang loopt via OAuth zodat iedereen onder zijn eigen identiteit autoriseert, en u krijgt één plek om activiteit vast te leggen en limieten toe te passen.
Dit was vroeger de ongemakkelijke optie, omdat het protocol elk gesprek aan één specifieke serverinstantie koppelde, met sticky sessions en een gedeelde sessiestore tot gevolg. De specificatie 2026-07-28 haalde dat weg: MCP is nu stateless, dus een gedeelde server draait achter een gewone load balancer zoals elke andere webdienst.
Die wijziging is recent genoeg om te snappen vóór u hosting ontwerpt — wat de stateless spec van 2026 in de praktijk betekent.
Veel bedrijven draaien uiteindelijk allebei: een lokale server voor het afstemwerk van de financieel specialist, en een gedeelde voor de orderstatusvragen die iedereen stelt.
En als het systeem geen API heeft?
Oudere systemen hebben vaak niets wat u een interface zou noemen. Dat komt veel voor en het is geen blokkade; het verandert alleen waar de server op zit.
Een alleen-lezen replica van de database werkt, en is in een ouder landschap vaak de schoonste optie. Een nachtelijke export naar een map werkt, zolang iedereen begrijpt dat de antwoorden tot gisteravond lopen. Zelfs een gedeelde schijf vol pdf's werkt, als mensen die vooral moeten vinden en lezen.
De afweging is eerlijkheid over actualiteit. Is de data een dag oud, dan hoort de toolbeschrijving dat te zeggen, zodat de assistent het erbij vertelt in plaats van te suggereren dat het live is. Die ene zin voorkomt de meeste vertrouwensproblemen die anders volgen.
Eerst lezen, dan schrijven
Lever eerst de alleen-lezen versie op en laat die twee weken meelopen met echte vragen.
Dit is de goedkoopste manier om te ontdekken of uw toolgrenzen aansluiten op hoe mensen werkelijk vragen, en het risico is begrensd: het ergste is een fout antwoord dat iemand opmerkt. Er wordt niets gewijzigd, verstuurd of verwijderd.
Schrijfrechten zijn een ander gesprek. Ze vragen goedkeuringsstappen, ze moeten veilig opnieuw uitgevoerd kunnen worden zonder hetzelfde twee keer te doen, en er hoort vast te liggen wat er gebeurde en namens wie. Dat is het onderwerp van deel vier, en daar komt u het liefst bewust aan, niet omdat een tool makkelijk toe te voegen leek.
Dezelfde fasering zit achter hoe wij projecten in het algemeen doen: eerst bewijzen op echte data, dan pas vastleggen op productie. Het is de middelste stap van onze volgorde audit, proof of concept, productie, en die bestaat omdat vroeg ongelijk krijgen veel goedkoper is.
Twee realistische eerste weken
Dag één tot drie is geen programmeren. Kies het systeem en schrijf de tien vragen op die mensen er werkelijk aan stellen — niet de tien die u zich voorstelt, maar die uit de berichten van vorige week. Groepeer ze. Meestal vallen ze uiteen in drie of vier verschillende acties.
Dag vier tot zeven: bouw de alleen-lezen server tegen een testomgeving, met die drie of vier tools en zorgvuldig geschreven beschrijvingen.
Week twee: zet hem voor twee collega's neer en kijk mee. Stuur ze niet. De vragen die hij verprutst zijn de nuttige opbrengst van de hele oefening.
Die missers vertellen u welke van drie dingen mis is: er ontbreekt een tool, een beschrijving is dubbelzinnig, of — het vaakst — het proces stond nooit op papier en twee mensen doen het anders. Dat laatste kost de meeste tijd om te repareren en levert daarna het meeste op.
Hierna in de reeks: spreadsheet- en datawerk automatiseren, waar de meeste bedrijven ontdekken waar de uren feitelijk heen gaan. Daarna beveiliging en rechten.
