Vrijwel elke softwareleverancier heeft er het afgelopen jaar een chatvenster bij gezet. Handig als je wilt weten waar een knop zit. Alleen kan dat venster je meestal niet vertellen hoeveel marge er op je laatste order zat, want het kent de handleiding en niet jouw bedrijf.
MCP staat voor Model Context Protocol. Het is een open standaard waarmee een taalmodel op een gecontroleerde manier toegang krijgt tot software en de gegevens die daarin staan. Niet door een chatvenster in een scherm te bouwen, maar door de software zelf te laten publiceren wat een model mag opvragen en mag uitvoeren.
Dat klinkt technisch en de gevolgen zijn dat niet. In dit artikel lees je wat MCP is, waarin het verschilt van een gewone koppeling, tien dingen die een ondernemer straks aan zijn eigen systeem zou kunnen vragen, en wat er eerst in je bedrijf op orde moet zijn voordat daar iets zinnigs uitkomt.
Wat is MCP precies?
Een systeem met een MCP-server publiceert een lijst met handelingen die een taalmodel mag uitvoeren. Zoek orders van deze klant. Haal de geboekte uren op van deze week. Maak een conceptcalculatie aan. Bij elke handeling staat in gewone taal beschreven wat hij doet en welke gegevens hij nodig heeft.
Het model krijgt die lijst te zien op het moment dat jij een vraag stelt, en bepaalt zelf welke handelingen het nodig heeft om je te kunnen antwoorden. Vraag je welke orders van een klant dit kwartaal onder de calculatie uitkwamen, dan haalt het eerst de orders op, dan de nacalculaties, en zet het die naast elkaar. Jij hebt geen van die stappen genoemd.
Dat is het hele idee: niet een programmeur die vooraf uittekent welke vraag gesteld gaat worden, maar een beschrijving die goed genoeg is dat een model er zelf zijn weg in vindt.
Wat is het verschil tussen een API en een MCP-server?
Een API is gebouwd voor een ander programma dat precies weet wat het wil vragen. Een ontwikkelaar legt eenmalig vast welk veld waar terechtkomt, en daarna doet die koppeling elke dag hetzelfde. Een MCP-server is gebouwd voor een model dat een vraag in gewone taal krijgt en zelf moet uitzoeken welke stappen daarbij horen.
API-koppeling | MCP-server | |
|---|---|---|
Gebouwd voor | Een ander programma | Een taalmodel |
Vraag ligt vast | Vooraf, door een ontwikkelaar | Op het moment zelf, door het model |
Uitkomst | Elke keer hetzelfde | Kan per keer verschillen |
Bij een nieuwe wens | Iemand past de koppeling aan | Vaak geen aanpassing nodig |
Die laatste rij is waar het interessant wordt. Bij een koppeling moet er iemand aan te pas komen zodra je iets anders wilt weten. Bij een MCP-server stel je gewoon een andere vraag. Wat een API precies is en hoe koppelingen werken, staat in Wat is een API-koppeling in ERP-software?.
Waarom een chatvenster in je software iets anders is
Het verschil tussen een assistent die iets voor je betekent en een assistent die dat niet doet, is niet het model. De modellen zijn voor iedereen ongeveer gelijk beschikbaar. Het verschil is de toegang.
Een venster dat op de handleiding is getraind, kan je uitleggen waar je de orderstatus vindt. Een model met toegang via MCP geeft je de orderstatus zelf. Het eerste is een zoekfunctie met betere formuleringen. Het tweede is iemand die in je administratie kan kijken.
Dat heeft een gevolg voor de softwaremarkt dat nu nog weinig wordt benoemd. Leveranciers die hun systeem dichthouden, houden daarmee ook de deur dicht voor alles wat er de komende jaren aan gereedschap bij komt. Zonder toegang valt er voor een model niets te doen, hoe goed dat model ook wordt.
Tien dingen die je straks aan je eigen systeem zou kunnen vragen
Hieronder staan tien situaties uit de praktijk van een metaalbedrijf. Ze zijn voorwaardelijk geformuleerd, want dit is wat mogelijk wordt als je administratie via MCP bereikbaar is, niet wat er vandaag in elk pakket klaarstaat.
Administratie naar binnen krijgen
1. Bonnen uit een map. "In deze map staan alle bonnen van deze week. Zet ze in mijn systeem." Het model leest de PDF's en foto's, haalt er leverancier, datum, bedrag, btw en omschrijving uit, zoekt de leverancier op in je relatiebestand en zet per bon een inkoopboeking klaar. Staat er een ordernummer op de bon van de gereedschapshandel, dan koppelt het die eraan. Wat jij nog doet is goedkeuren, want een handgeschreven bon van de bouwmarkt leest een model minder zeker dan een nette factuur.
2. Pakbonnen afletteren. "Hier zijn de pakbonnen van vandaag. Klopt dit met wat we besteld hadden?" Het model zoekt bij elke pakbon de inkooporder, vergelijkt aantallen en artikelen, en meldt de verschillen: twee platen minder geleverd dan besteld, één artikel dat niet op de order stond. Dit is werk waar een mens niet beter in is, alleen trager, en dat in veel bedrijven pas gebeurt als de factuur binnenkomt en niet blijkt te kloppen.
Werk voorbereiden
3. Aanvraag omzetten naar een calculatie. "Er staat een aanvraag in mijn mail met een tekening erbij. Zet er een calculatie voor klaar." Het model leest de mail, opent de bijlage, zoekt een eerdere order die erop lijkt en zet een conceptcalculatie klaar met de bewerkingen en tijden van die vorige keer als vertrekpunt, inclusief de opmerking dat de materiaalprijs sindsdien is gewijzigd. De prijs bepaal jij. Dat is een ondernemersbeslissing en geen rekensom, en dat moet het blijven.
4. Een klantvraag beantwoorden. "Klant vraagt naar order 24-1187. Waar staat die en schrijf een antwoord." Het model haalt de status op, gesneden, gekant, wacht op de poedercoater, retour verwacht donderdag, en schrijft een conceptmail in de toon die jij gebruikt. Dit voorbeeld laat het verschil met een chatvenster het scherpst zien. Zo'n venster vertelt je waar je de status kunt vinden. Hier krijg je de status.
Vragen over je eigen cijfers
5. Marge per klant. "Welke orders van deze klant kwamen dit kwartaal onder de calculatie uit, en waardoor?" Het model zet voor- en nacalculatie naast elkaar, selecteert de orders met een negatief verschil en kijkt waar dat verschil zit: meer uren op de kantbank, meer materiaalverbruik, of een bewerking die er niet in gecalculeerd zat. Dit kun je vandaag ook beantwoorden, alleen moet er dan iemand een rapport voor bouwen. De drempel om het te vragen wordt lager, en daardoor vraag je het vaker.
6. Gaten in je urenregistratie. "Welke uren zijn deze week nog niet geboekt?" Het model vergelijkt de aanwezige uren met de geboekte uren per medewerker en per dag, en noemt de verschillen. Dinsdagmiddag van twee man staat niet op een order. Klein voorbeeld, en het raakt iets belangrijks: zonder geboekte uren is voorbeeld vijf een schatting.
7. Prijsafspraken die achterlopen. "Voor welke artikelen met een vaste prijsafspraak zijn onze kosten sinds die afspraak het hardst gestegen?" Het model kijkt per artikel naar wat het de afgelopen keren werkelijk heeft gekost en zet dat af tegen de afgesproken prijs. De uitkomst is een lijstje voor je volgende jaargesprek.
Op de werkvloer en over systemen heen
8. Restplaat zoeken. "Hebben we nog RVS 3 millimeter liggen dat groter is dan een halve plaat?" Het model doorzoekt je restmateriaal op soort, dikte en afmeting, en noemt wat er ligt en waar. Iedereen in de metaal kent het probleem van een nieuwe plaat bestellen terwijl er een halve in de stelling staat.
9. Waar zit de druk deze week. "Waar knelt de planning deze week?" Het model zet de geplande bewerkingen per machine af tegen de beschikbare capaciteit en kijkt welke orders nog op materiaal wachten. Antwoord: de kantbank staat woensdag vol en twee orders wachten op een levering die pas donderdag komt.
10. Drie systemen in één opdracht. "Haal de nieuwe aanvragen uit mijn mailbox van vandaag, maak er offerteaanvragen van, en zet de tekeningen in de projectmap." Je mailbox, je bestandsopslag en je bedrijfssoftware zijn drie systemen van drie leveranciers. Hebben ze alle drie een MCP-server, dan kan één model ze achter elkaar zetten zonder dat iemand daar een koppeling voor heeft gebouwd. Dit is het voorbeeld dat laat zien waarom MCP een standaard is en geen functie, en het is meteen het voorbeeld waar je het zorgvuldigst mee om moet gaan.
Wat er eerst moet kloppen
Bij alle tien geldt hetzelfde voorbehoud, en het is het belangrijkste deel van dit artikel. Een model kan alleen antwoorden over gegevens die er zijn. Een bedrijf dat de uren op vrijdagmiddag reconstrueert, krijgt een keurig geformuleerd antwoord dat op een schatting berust.
Het achtste voorbeeld maakt dat tastbaar. Vragen wat er aan restplaat ligt, levert alleen iets op als dat restmateriaal is ingeboekt toen het overbleef. Een model dat netjes antwoordt dat er niets ligt terwijl er twee platen in de stelling staan, is schadelijker dan geen antwoord, want je gelooft het.
AI verandert dus niets aan het principe dat een systeem zichtbaar maakt wat er wordt geregistreerd, en niets meer. Het maakt dat principe alleen belangrijker, omdat de antwoorden zelfverzekerder klinken dan een rapport. Welke voordelen er onder die registratie zitten, staat in 10 voordelen van een ERP-systeem voor metaalbedrijven.
Lezen en schrijven zijn twee verschillende dingen
Een model dat je orders mag inzien is iets anders dan een model dat een order mag aanmaken of een prijs mag wijzigen. In de tien voorbeelden hierboven zitten allebei de soorten, en het onderscheid hoort in de software te zitten en niet in de vraag die je stelt.
Drie dingen die daarbij horen. Rechten gelden per gebruiker en per handeling, niet per systeem: wie zelf geen prijzen mag wijzigen, kan dat ook niet via een model. Alles wat een model doet, moet terug te vinden zijn, dus wie vroeg wat, wanneer, en wat er is gewijzigd. En bij handelingen die iets vastleggen, is een tussenstap waarin jij goedkeurt geen omweg maar de bedoeling.
Daar hoort ook bij dat MCP een jonge standaard is die nog in beweging is. Wie nu zegt precies te weten hoe dit er over twee jaar uitziet, overdrijft.
Waar wij aan werken
Wij bouwen bij Fledge aan een MCP-laag boven het platform, en dat is een van de dingen waar we op dit moment vol op inzetten. De gedachte erachter is dezelfde als achter de open API: je moet je eigen gegevens kunnen gebruiken met het gereedschap dat jij kiest, en een deel van dat gereedschap bestaat vandaag nog niet.
Wat dat concreet betekent, is dat een taalmodel straks op een gecontroleerde manier bij je orders, uren, calculaties en voorraad kan, en dat je je eigen werkstromen aan elkaar kunt lussen zonder dat daar per geval een koppeling voor gebouwd hoeft te worden. De voorbeelden hierboven zijn niet willekeurig gekozen: het zijn de dingen die metaalbedrijven ons noemen als we vragen waar hun tijd in gaat zitten.
Het is werk in uitvoering en we doen er geen datum bij. Wat wel vaststaat is waar het draait: Fledge staat uitsluitend in Europese datacentra, en dat verandert hier niet mee. Wat er intussen wordt opgeleverd, staat in de changelog.
Veelgestelde vragen
Gaan jullie onze bedrijfsgegevens gebruiken om een AI-model te trainen? Nee. Een model dat via MCP een vraag van jou beantwoordt, raadpleegt je gegevens op dat moment om jouw vraag te beantwoorden. Dat is iets anders dan gegevens gebruiken als trainingsmateriaal.
Wat als het model iets verkeerd doet? Dat is precies de reden dat lezen en schrijven gescheiden horen te zijn, dat rechten per gebruiker gelden en dat handelingen terug te vinden moeten zijn. Bij alles wat iets vastlegt, hoort een stap waarin een mens akkoord geeft. Een model dat ongecontroleerd in je administratie mag schrijven, is geen assistent maar een risico.
Moeten wij hier zelf iets voor bouwen? Nee. Een MCP-server is iets dat de softwareleverancier levert, net als een API. Wat het van jou vraagt is een keuze over wie wat mag, en gegevens die actueel genoeg zijn om op te vertrouwen.
Kort samengevat
MCP is een open standaard waarmee een taalmodel op een gecontroleerde manier bij software en de gegevens daarin kan. Het verschil met een gewone koppeling is dat een ontwikkelaar niet vooraf hoeft uit te tekenen welke vraag er gesteld gaat worden. Daardoor kun je je systeem dingen vragen die niemand als functie heeft ingebouwd, van bonnen inlezen tot marge per klant tot restplaat zoeken. De kwaliteit van die antwoorden hangt volledig af van wat er in je administratie staat, en het onderscheid tussen lezen en schrijven hoort in de software geregeld te zijn en niet in de vraag. Het is een jonge standaard, en wie beweert precies te weten hoe dit er over twee jaar uitziet, overdrijft.

Geschreven door
Bart is Account Executive bij Fledge en werkt dagelijks met metaalbedrijven aan de software achter hun productieproces. Vanuit Enschede begeleidt hij MKB-maakbedrijven van eerste kennismaking tot livegang, waardoor hij goed zicht heeft op wat er in de praktijk komt kijken bij het inrichten van ERP voor de metaalindustrie. In de kennisbank schrijft hij over ERP voor metaalbedrijven en over de keuzes die daarbij komen kijken.

Benieuwd naar wat Fledge voor jouw maakbedrijf kan betekenen?
In 30 minuten maken we kennis en verkennen we hoe Fledge jou vooruit kan helpen.



