Het gat tussen een MCP-server die indruk maakt in een vergadering en een waar een bedrijf op kan bouwen, heeft bijna niets met technische verfijning te maken. Het is een handvol saaie beslissingen over waar hij draait, wat er gebeurt als hij faalt, wat hij kost, en wie hem over een jaar nog begrijpt.
Hiermee sluit een reeks van vijf: wat MCP is, uw systemen koppelen, spreadsheets automatiseren en beveiliging.
Zet de server naast het systeem, niet naast het model
De neiging is de server te hosten waar de AI-stack staat, want daar voelt hij thuis. Meestal verkeerd.
De eigenlijke taak van de server is praten met uw systeem, en dat doet hij voortdurend: meerdere heen-en-weertjes voor één vraag. Latency, netwerktoegang en dataresidentie pleiten er allemaal voor hem dicht bij het systeem te zetten dat hij verpakt, niet dicht bij de assistent.
Een on-premise ERP krijgt dus een on-premise server. Data die in een EU-regio moet blijven, krijgt een server in die regio. Dat vereenvoudigt ook het gesprek met wie vraagt waar de data heen gaat, want het antwoord wordt concreet: de records blijven staan, alleen de samenvatting reist.
Bij een lokale server speelt de vraag nauwelijks, wat een deel van de aantrekkingskracht is. Bij een gedeelde is het de eerste beslissing en de vervelendste om later te wijzigen, want al het andere wordt eromheen gebouwd.
Versioneer alles, ook wat te klein lijkt om te versioneren
Leg de protocolversie vast waartegen u bouwt — bij het schrijven hiervan 2026-07-28. MCP is een jonge standaard en de randen bewegen nog. U wilt dat een upgrade een beslissing is die u op een rustige middag neemt, geen gebeurtenis die zich op maandag vanzelf aandient.
De stateless revisie illustreert precies waarom. Hosting werd er flink eenvoudiger van, en tegelijk verdween de opstart-handshake waar oudere servers op leunden. Allebei prima als u bewust meebewoog, allebei een onaangename verrassing als dat niet zo was.
Behandel uw eigen toolschema's als een publieke API, ook al is een model de enige afnemer. Een optioneel veld toevoegen is veilig. Een veld hernoemen, een type wijzigen of een geldige waarde verwijderen is een breaking change.
En dit is het deel waarop mensen struikelen: die breuk ziet er niet uit als een foutmelding. Hij ziet eruit als een assistent die stilletjes slechter wordt — meer herhaalpogingen, meer rare antwoorden, geen enkele waarschuwing. Geef gewijzigd gedrag dus een nieuwe toolnaam en bouw de oude volgens schema af, in plaats van ter plekke te bewerken en te hopen.
Houd toolbeschrijvingen in versiebeheer bij de code. Het is gedrag, geen documentatie. Een wijziging in een beschrijving verdient dezelfde review als een wijziging in een functie, want hij kan hetzelfde effect hebben.
Beheers de kosten waar ze ontstaan
Het serverproces zelf is goedkoop — het is een klein programma dat weinig werk doet. De tokens zijn niet goedkoop, en vrijwel alle tokenkosten worden door één ding bepaald: wat uw tools teruggeven.
Een tool die een volledig contract van veertig pagina's teruggeeft, kost misschien honderd keer zoveel als een die "looptijd: 24 maanden, opzegtermijn: 3 maanden, stilzwijgende verlenging: ja" teruggeeft. Beide beantwoorden de gestelde vraag. Maar één ervan is betaalbaar als hij duizend keer per maand draait.
Begroot dus in kosten per afgeronde taak, niet per aanroep. Die lopen verder uiteen dan mensen verwachten: een taak met vier kleine aanroepen is vaak veel goedkoper dan één aanroep die een document de context in sleept. Per taak is ook het getal dat op een businesscase aansluit, want dat kunt u afzetten tegen de handmatige kosten.
Zet er daarna een plafond op. Begrens per gebruiker. Maximeer resultaatgroottes in de server zelf in plaats van erop te vertrouwen dat de aanroeper netjes vraagt. Waarschuw als de gemiddelde kosten van een taak verschuiven in plaats van als een totaal wordt overschreden — kosten kruipen zelden omhoog, ze springen op de dag dat iemand de assistent op een grotere map richt.
Bewaak de drie dingen die echt misgaan
Credentials en connectiviteit
Tokens verlopen. Certificaten lopen af. Een upstream-API scherpt zijn limieten aan zonder iemand iets te laten weten. Dit zijn gewone operationele storingen, gewone monitoring vangt ze, en het enige echte risico is dat niemand eraan dacht de monitoring op de server te richten omdat het niet als productie voelde.
Kwaliteit van toolkeuze
Deze is specifiek voor de AI-laag en dit is degene die teams missen. Log welke tool bij welk soort verzoek werd aangeroepen, en volg de verdeling over de tijd.
Meer herhaalpogingen, of een tool die wordt aangeroepen en daarna losgelaten, betekent meestal dat twee beschrijvingen naar elkaar toe zijn gekropen. Er faalt niets. Er gaat geen melding af. De assistent wordt gewoon minder bruikbaar, en mensen gaan stilletjes terug naar handwerk — wat u maanden later hoort.
Antwoordkwaliteit over tijd
Modelupdates en schemawijzigingen verschuiven gedrag geruisloos. Houd twintig echte taken met bekende juiste antwoorden, draai die volgens schema en vergelijk de uitvoer.
Twintig is genoeg. Dit is de goedkoopste regressietest in de hele stack, en het enige dat u vertelt dat de assistent slechter werd voordat een collega dat doet.
De tracingkant is een onderwerp op zich — zie AI-agent observability voor de instrumentatielaag.
Schrijf op wat er gebeurt als het plat ligt
Elke nuttige automatisering wordt stilletjes dragend. Niemand besluit dat; het gebeurt gewoon, ergens in de derde maand als mensen de oude spreadsheet niet meer parallel bijhouden.
In de maand dat hij niet beschikbaar is, moet iemand het werk dus handmatig doen. Heeft niemand opgeschreven hoe, dan hebt u een traag proces vervangen door een broos proces, en degene die de oude manier kende is misschien vertrokken.
Houd de handmatige route gedocumenteerd en oefen hem af en toe — eens per kwartaal is ruim voldoende. Het kost een uur en het is het verschil tussen een storing als ongemak en een storing als crisis.
Wijs ook een eigenaar aan. Geen team: een persoon die de melding krijgt en weet waar de tool voor was. Automatisering zonder aangewezen eigenaar verslechtert gestaag tot iemand hem uitzet, en tegen die tijd weet niemand genoeg om hem weer aan te zetten.
Hoe de eerste maand er werkelijk uitziet
Week één en twee zijn rustig, en dat is misleidend. De mensen die hem gebruiken zijn nog degenen die meebouwden, ze stellen de vragen waarvoor hij ontworpen is, en alles werkt.
Week drie is wanneer hij de rest ontmoet. Iemand formuleert een vraag op een manier die niemand voorzag. Iemand vraagt naar een periode die de data niet dekt. Iemand probeert hem voor een klus waarvoor hij nooit bedoeld was, omdat het leek alsof het zou kunnen.
Dit is de nuttige week, en de fout is die gevallen te behandelen als mislukkingen waarvoor u zich verontschuldigt. Het is de specificatie die u niet had. Schrijf ze allemaal op en beslis dan: ontbreekt hier een tool, is een beschrijving dubbelzinnig, of is dit een verzoek dat beleefd geweigerd hoort te worden?
Die derde categorie telt zwaarder dan mensen verwachten. Een tool die duidelijk zegt wat hij niet dekt, is bruikbaarder dan een die gokt, want dan gaat iemand het zelf doen in plaats van op een fout antwoord te vertrouwen.
De overdrachtstoets
Een simpele controle die voorspelt of dit standhoudt, en die niets kost.
Vraag een collega die er niet bij betrokken was om de toolbeschrijvingen te lezen en in eigen woorden uit te leggen wat de server doet en wanneer je hem gebruikt. Lukt dat, dan heeft u documentatie die leeft waar hij gebruikt wordt in plaats van in een bestand dat niemand opent. Lukt het niet, dan heeft u een systeem dat door precies één persoon in leven wordt gehouden.
Doe hetzelfde met het draaiboek. Kan die collega vinden waar hij gehost is, welk account hij gebruikt, waar de logs staan en wie te bellen? Vier vragen. Kost er één meer dan een minuut, schrijf het dan nu op en niet tijdens het incident.
Weten wanneer u stopt
Niet alles verdient het om productie te halen, en dat vroeg zien is vakmanschap en geen falen.
Wordt de tool na het nieuwtje minder dan een handvol keren per week gebruikt, dan loste hij waarschijnlijk een probleem op dat niemand veel kostte. Vraagt hij constant bijstelling om accuraat te blijven, dan is het onderliggende proces waarschijnlijk nog in beweging en is automatiseren voorbarig. Klaagt niemand als hij stukgaat, dan is dat het duidelijkste signaal dat er is.
Zo'n ding uitzetten is goedkoop en eerlijk. Duur is een portfolio van zes half onderhouden servers die het meestal doen, want die kosten zitten verspreid over ieders aandacht in plaats van op een factuur.
Liever twee dingen goed draaien dan zes dingen hopelijk.
Hoe goed er na zes maanden uitziet
De server is saai. Hij heeft een versienummer, een aangewezen eigenaar, een afgebakend credential en een dashboard waar niemand naar kijkt, omdat er niets misgaat.
De kosten per taak zijn bekend en stabiel, dus niemand is zenuwachtig als het gebruik groeit. Een collega die er bij de start niet bij was, kan de toolbeschrijvingen lezen en begrijpen wat het ding doet en waarom. De handmatige terugvaloptie staat op papier en is vorig kwartaal getest.
Dat is een lagere lat dan de demonstraties suggereren en een hogere dan de meeste pilots ooit halen. Hem halen is precies wat automatisering die zich door een bedrijf verspreidt scheidt van automatisering die stilletjes wordt losgelaten zodra degene die hem bouwde vertrekt.
Wilt u dit liever tegen uw eigen systemen laten uitzoeken dan het uit vijf artikelen samenstellen, dan is daar de auditstap voor — en de proof of concept die erop volgt is bewust de goedkope plek om te ontdekken dat u het mis had.
