Het probleem met "even een export erin plakken"
De gangbare manier om een taalmodel iets over een klant te laten zeggen, is een export. Je trekt een Excel-rapport uit je boekhoudpakket en plakt dat in een chatvenster. Dat werkt, één keer, voor één vraag. Maar het schaalt niet: bij de volgende vraag exporteer je opnieuw, mogelijk een ander rapport. En het is foutgevoelig, want niemand checkt of die export nog actueel is op het moment dat het taalmodel hem leest.
Erger nog, je klantdata staat dan los in een chatgeschiedenis, buiten je eigen systeem, zonder dat iemand bijhoudt waar die kopie blijft. Voor financiële data van klanten is dat een risico dat ik niet wilde nemen. Ik wilde iets anders: een taalmodel dat rechtstreeks kan meekijken in mijn eigen administratiesysteem (Minox), binnen grenzen die ik vooraf heb bepaald, zonder dat er ergens een kopie van die data blijft hangen.
Wat een MCP-server eigenlijk is
MCP staat voor Model Context Protocol. Het is een open standaard waarmee een taalmodel op een gestructureerde, voorspelbare manier "tools" kan aanroepen: kleine, duidelijk omschreven functies die data ophalen of een actie uitvoeren. Geen vrije tekst die het model zelf moet interpreteren, maar een vaste set functies met een vast antwoordformaat. Vraag je het model wat de ouderdom is van de openstaande posten van klant X, dan roept het niet zelf iets willekeurigs aan. Het kiest uit een beperkte, door mij gedefinieerde lijst van tools, en krijgt gestructureerde data terug.
Het verschil met een gewone chatbot-integratie is essentieel. Bij een MCP-server bepaal ik welke tools beschikbaar zijn, welke data ze mogen tonen en welke acties ze wel of niet mogen uitvoeren. Het taalmodel krijgt geen vrije toegang tot het systeem. Het krijgt een afgebakende set deuren, en alleen de deuren die ik heb opengezet.
Waarom een protocol, en niet zomaar een eigen koppeling
Ik had dit ook kunnen bouwen als een eigen, losse integratie: een stukje code dat specifiek mijn taalmodel met Minox verbindt. Dat zou prima gewerkt hebben, maar dan zit ik vast aan die ene combinatie. MCP is een open standaard, niet door mij uitgevonden maar door meerdere AI-leveranciers gezamenlijk ontwikkeld, die vastlegt hoe een taalmodel en een tool met elkaar praten, los van welk taalmodel of welke applicatie het precies is.
Het praktische voordeel: de MCP-server die ik voor Minox heb gebouwd, kan ik vandaag aansluiten op het taalmodel dat ik nu gebruik en morgen op een ander model of een andere chatomgeving, zonder de koppeling zelf opnieuw te bouwen. Het protocol verandert niet mee met de leverancier. Voor een kantoor dat hierin investeert, is dat geen overbodige luxe. Het is precies de garantie die voorkomt dat je over twee jaar alles weggooit omdat je van leverancier wisselt.
Een voorbeeld: van vraag tot antwoord
Concreet ziet een sessie er ongeveer zo uit. Ik stel een gewone vraag in normale taal: "Welke debiteuren van klant X staan langer dan negentig dagen open?" Het taalmodel herkent dat dit een vraag is die het zelf niet kan beantwoorden uit zijn eigen kennis. Het kiest uit de beperkte lijst tools die ik heb opengezet de tool die een ouderdomsanalyse opvraagt, en geeft daarbij automatisch de juiste parameters mee: de klant en de gevraagde periode.
De MCP-server voert die aanvraag uit tegen Minox en krijgt een gestructureerd antwoord terug. Geen losse tekst, maar nette data: debiteurnaam, bedrag, aantal dagen open. Dat antwoord gaat terug naar het taalmodel, en pas dan formuleert het taalmodel een leesbare zin voor mij. Het model verzint dus niets. Het haalt feiten op en vertaalt die naar taal. Dat onderscheid, ophalen in plaats van verzinnen, is precies waarom dit voor financiële data wél verantwoord is en een kale chatbot niet.
Hoe de koppeling met Minox werkt
Ik heb een eigen MCP-server gebouwd die praat met de Minox-administraties die ik beheer. In de praktijk betekent dat dat een taalmodel, als ik daar als gebruiker om vraag, onder andere de saldibalans van een administratie kan opvragen, de openstaande posten en ouderdomsanalyse kan bekijken, de lijst van debiteuren en grootboekrekeningen kan doorzoeken, btw-codes en dagboeken kan raadplegen, en transacties kan opzoeken op referentie. Allemaal leesfuncties. Het model kijkt mee, het verandert niets zonder dat ik dat expliciet bevestig.
Voor het daadwerkelijk boeken van mutaties geldt een ander principe. Het model bereidt een boeking voor en legt die eerst aan mij voor, inclusief grootboekrekening, btw-code en dagboek. Pas na mijn akkoord wordt die definitief vastgelegd. Een mens blijft de laatste stap. Dat is geen technische beperking. Het is een bewuste keuze: AI versnelt het denkwerk, maar de verantwoordelijkheid voor een boeking blijft bij de boekhouder.
Wat dit concreet oplevert
Het verschil zit niet in iets spectaculairs, maar in honderden kleine momenten per week. Een vraag als welke klanten facturen ouder dan negentig dagen openstaan hebben, vroeg voorheen om een apart rapport, een filter en wat handwerk. Nu stel ik de vraag en krijg ik direct antwoord, met de juiste cijfers, uit de juiste administratie, zonder dat ik eerst moet exporteren.
Bij het opstellen van een jaarrekening kan ik het model laten meekijken in de saldibalans en laten signaleren wat afwijkt van vorig jaar, voordat ik er zelf naar kijk. Dat is geen vervanging van mijn beoordeling. Het is een eerste check die mij tijd bespaart en die ik vervolgens zelf controleer. Precies de volgorde die ik in een eerder artikel beschreef: AI levert pas iets op als de onderliggende data klopt en gestructureerd is.
Waarom dit lokaal draait, en niet in de cloud
Klantdata van een boekhoudkantoor is gevoelig. Ik wilde niet afhankelijk zijn van een derde partij die mijn administraties in een cloudomgeving verwerkt, met alle vragen over dataopslag, AVG en leveranciersafhankelijkheid die daarbij horen. Daarom draait de MCP-server lokaal, op eigen hardware, met een eenmalige serverinvestering in plaats van een doorlopend AI-abonnement per gebruiker. Geen klantdata verlaat de eigen omgeving om een vraag te kunnen beantwoorden.
Dat is een bewuste keuze, en niet vanzelfsprekend voor elk kantoor. Het kost meer tijd om te bouwen dan een kant-en-klaar abonnement af te sluiten. Maar het levert volledige controle op over wat er met klantdata gebeurt, en dat weegt zwaarder dan het gemak van een standaard SaaS-oplossing.
Dit kan ook op jouw eigen server, niet op de mijne
Wat ik hierboven beschrijf is mijn eigen opzet, voor mijn eigen kantoor. Het is nadrukkelijk geen unieke installatie die alleen bij mij werkt. Hetzelfde principe, een MCP-server die op een vaste, afgebakende manier met je boekhoudpakket praat, is net zo goed te bouwen voor een ander kantoor. Dan draait hij op jullie eigen server, met permissies en richtlijnen die passen bij jullie praktijk en jullie klantdata. Niet mijn installatie gekopieerd, maar opnieuw ingericht rond wat bij jullie hoort.
Dat is ook precies waar ik andere kantoren mee help: per kantoor opnieuw bepalen welke tools nodig zijn, welke grenzen daarbij horen, en hoe dat op de eigen infrastructuur draait, zodat klantdata nooit het kantoor verlaat.
Wat ik nog wil uitbreiden
De huidige set tools is bewust beperkt tot wat ik dagelijks daadwerkelijk gebruik: saldibalans, openstaande posten, ouderdomsanalyse, debiteuren, grootboekrekeningen, btw-codes, dagboeken en transacties opzoeken op referentie. Ik breid dit liever stap voor stap uit dan in één keer alles open te zetten. Elke nieuwe tool die ik toevoeg, overweeg ik eerst op risico: wat kan er misgaan als het taalmodel deze functie verkeerd interpreteert, en hoe beperk ik die schade tot iets dat altijd herstelbaar is?
Een logische volgende stap is een tool die concept-rapportages voor klanten genereert op basis van de saldibalans en de ouderdomsanalyse samen, een eerste aanzet tot de klantmail waar ik in een eerder artikel over schreef, maar dan direct gevoed vanuit de MCP-koppeling in plaats van een handmatige export.
De denkfout die ik wil voorkomen
Dit artikel is geen pleidooi om morgen zelf een MCP-server te bouwen. Voor de meeste kantoren is dat niet de eerste, en vaak niet eens een noodzakelijke stap. Maar er schuilt wel een bredere les in: bouw koppelingen als herbruikbare bouwstenen met een vaste, voorspelbare grens, niet als eenmalige trucjes die alleen werken voor de specifieke vraag van vandaag. Een script dat één keer een export naar een taalmodel plakt, is een hack. Een afgebakende, herhaalbare manier om een taalmodel veilig bij je data te laten, is infrastructuur. Infrastructuur blijft werken als je van leverancier, model of tool wisselt.
Dat onderscheid, hack versus infrastructuur, zie ik als de denkfout die de meeste kantoren maken zodra ze eindelijk wél aan AI toekomen. Ik help kantoren dat onderscheid te maken voordat ze gaan bouwen, niet erna.
Voor wie dit relevant is, en voor wie niet
Eerlijkheid hierover: voor de meeste kantoren is een eigen MCP-server vandaag geen prioriteit. Het vraagt om een fundering die het al waard maakt. Een kantoor dat nog worstelt met een rommelige documentstroom heeft daar meer aan dan aan een geavanceerde AI-koppeling die toch geen betrouwbare data te verwerken krijgt.
Voor kantoren die de eerdere stappen al hebben gezet, zoals gestandaardiseerde documenten, correcte factuurherkenning en een consistente datastructuur, is dit wél een logische volgende horizon. Dan bouw ik de koppeling niet voor mezelf, maar voor en bij dat kantoor: op de eigen server, met permissies en richtlijnen die we samen vaststellen voordat er één tool wordt aangezet.
Gerelateerde artikelen
Wil je een vergelijkbare opzet voor jouw kantoor?
Ik bouw en zet een MCP-server bij je neer die op jullie eigen server draait, met permissies en richtlijnen die passen bij jullie praktijk. Geen kopie van mijn installatie, maar een opzet rond jullie data.
Plan een gesprek