MCP-server voor SaaS in 2026: waarom je API niet je agent-interface is

Ergens in de afgelopen 12 maanden is er een nieuwe vraag opgedoken tijdens inkoopgesprekken bij grote bedrijven: hebben jullie een MCP-server? De vraag wordt achteloos gesteld, meestal tegen het einde, en is inmiddels een echte dealbreaker. De reflex is om een codegenerator op je OpenAPI-specificatie los te laten, in een weekend 80 tools te publiceren en het vakje aan te vinken.

Die server werkt technisch gezien wel. Maar hij is ook nagenoeg nutteloos. Agents die ermee verbinden, kiezen de verkeerde tool, verzinnen argumenten, verbruiken hun contextvenster met één enkele aanroep en leveren resultaten waar je klant niet op kan vertrouwen. De leverancier krijgt de schuld dat het model niet deugt. Het model was prima. De interface was fout.

Dit artikel is bedoeld voor oprichters, CTO's en productleiders bij SaaS-bedrijven die de vraag krijgen om 'agent-ready' te worden en dit liever in één keer goed doen, in plaats van een wrapper uit te brengen en het komende jaar excuses aan te bieden. Als je op zoek bent naar een basisuitleg over het protocol, dan is dit niet wat je zoekt. In dit artikel leer je wat een MCP-server voor SaaS daadwerkelijk is, waarom een 'één-endpoint-per-tool'-aanpak faalt, welke specifieke problemen wij zijn tegengekomen bij het draaien van MCP-servers in productie, hoe je tools ontwerpt die een agent betrouwbaar kiest, welke beveiligingsvragen je koper zal stellen en hoe je beslist of je zelf gaat bouwen, inkopen of afwachten.

De korte versie: je API is een contract met ontwikkelaars. Je MCP-server is een contract met een model dat geen documentatie heeft, geen geheugen van je product bezit en een strikt budget heeft voor hoeveel het kan lezen. Dat zijn verschillende producten.

Belangrijkste inzichten

• Een MCP-server voor SaaS stelt je product open voor AI-agents als een set benoemde, beschreven tools, niet als een ruwe kopie van je REST API.

• De meest voorkomende fout is het automatisch genereren van één tool per endpoint. Dit levert een server op die technisch geldig is, maar in de praktijk onbruikbaar.

• Agents kiezen tools door namen en beschrijvingen te lezen. De kwaliteit van toolnamen en -beschrijvingen is productwerk, geen documentatiewerk.

• Context is een schaars goed. Eén enkele onbegrensde lijst-aanroep kan het volledige werkgeheugen van een agent verbruiken en de sessie beëindigen.

• Een succesvolle API-respons is geen bewijs van een correct resultaat. Systemen die met agents werken, hebben een apart leespad nodig om te verifiëren wat er daadwerkelijk is gebeurd.

• Schrijfacties hebben een veilige standaardinstelling nodig. De onze maken concepten aan, nooit gepubliceerde wijzigingen, zodat een verkeerde aanroep herstelbaar is.

• Bouw zelf wanneer het agent-oppervlak onderscheidend is of de data gevoelig. Koop de standaardoplossingen in. Wacht alleen als er nog geen klant naar heeft gevraagd.

‍

Wat is een MCP-server, in begrijpelijke taal

Een MCP-server is een programma dat de mogelijkheden van een systeem ontsluit voor AI-applicaties via het Model Context Protocol, een gedeelde standaard voor hoe modellen verbinding maken met tools en data. Anthropic bracht MCP eind 2024 uit en droeg het in december 2025 over aan de Agentic AI Foundation onder de Linux Foundation, samen met meer dan 10.000 actieve publieke servers en client-ondersteuning in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot en Visual Studio Code. Het is niet langer het formaat van één leverancier. Het is de verbindingslaag.

Een server heeft drie dingen te bieden, en het verschil is belangrijker dan de meeste teams beseffen. Tools zijn functies die het model zelfstandig besluit aan te roepen, zoals het doorzoeken van records of het aanmaken van een factuur. Resources zijn alleen-lezen data die de host-applicatie ophaalt als context. Prompts zijn sjablonen die de gebruiker expliciet aanroept. De officiële serverdocumentatie is duidelijk over wie wat beheert: tools worden beheerd door het model, resources door de applicatie en prompts door de gebruiker.

Dat ene onderscheid maakt de meeste naïeve ontwerpen direct onbruikbaar. Als je je volledige leesoppervlak in tools dumpt, geef je het model honderd beslissingen die het helemaal niet hoefde te nemen. Als je nooit resources blootstelt, dwing je het model om een tool-aanroep en een deel van zijn context te verspillen aan iets wat de host gratis had kunnen inladen.

De eerlijke definitie in één zin is dus: een MCP-server is het voor agenten toegankelijke productoppervlak van je SaaS, en zoals elk productoppervlak moet dit worden ontworpen, niet gegenereerd.

‍

Waarom "heb je een MCP-server?" in 2026 een inkoopvraag werd

De druk komt niet van je eigen engineeringteam. Het komt van de interne AI-programma's van je klanten, en het heeft een specifieke vorm.

Grote organisaties bouwen al twee jaar lang agent-workflows bovenop de tools waarvoor ze al betalen. Die workflows zijn slechts zo breed als de beschikbare connectoren. Wanneer een operatieteam hun assistent vraagt om de contractverlengingen van het afgelopen kwartaal op te halen en jouw platform is het enige systeem dat niet bereikbaar is, ben je niet zomaar een kleine tekortkoming in de workflow. Jij bent de reden dat de workflow niet bestaat. Je concurrent met een werkende MCP-server wordt standaard het bronsysteem, simpelweg omdat de agent die wél kan zien.

Er is nog een tweede, stiller effect. Agent-gereedheid is een graadmeter geworden voor technische serieusheid. Het platformteam van een koper kan in een middag naar je MCP-server kijken en zien of je rechtenbeheer echt is, of je datamodel coherent is en of je schrijfacties veilig zijn. Het is een sneller signaal dan een beveiligingsvragenlijst, en dat weten ze.

Dat betekent niet dat elk SaaS-product er dit kwartaal een moet uitbrengen. Het betekent dat de vraag nu commercieel is, en dus een commercieel antwoord verdient in plaats van een reflexmatige engineering-sprint.

‍

De fout die bijna iedereen maakt: één tool per endpoint

Dit is het patroon dat we constant zien. Een team neemt hun OpenAPI-specificatie, haalt die door een generator en brengt een MCP-server uit met een tool voor elk endpoint. Negentig tools, volledige dekking, trouw aan de API. Het voelt als de verantwoorde keuze, omdat dat bij elk ander integratieproject ook zo zou zijn.

Vervolgens koppelt een klant het aan hun assistent en stelt een alledaagse vraag, zoals "welke van onze accounts zijn te laat met betalen en wie is de eigenaar". De agent moet bedenken dat dit betekent: list_accounts aanroepen, dan list_invoices met een statusfilter dat hij zelf moet raden, en dan get_user voor elk gevonden eigenaars-ID. Drie tools die hij correct koos en één die hij fout had, tien retourtjes en een contextvenster vol JSON-velden waar niemand op zat te wachten. Het antwoord is fout, traag, of komt er helemaal niet.

‍

Je endpoints zijn ontworpen voor ontwikkelaars, niet voor agenten

Een REST API is ontworpen voor een ontwikkelaar die je documentatie heeft gelezen, je objectmodel begrijpt en code schrijft die elke keer hetzelfde werkt. Zij combineren vijf aanroepen tot één functie en testen die. Het model heeft dat allemaal niet. Het ziet toolnamen en korte beschrijvingen en redeneert vanuit een menselijke zin naar een reeks aanroepen in één keer, zonder iets te kunnen testen.

De eenheid van ontwerp verandert dus. De juiste eenheid voor een agent is de taak, niet de resource. In plaats van list_accounts, list_invoices en get_user bloot te stellen, kun je beter find_overdue_accounts aanbieden met een duidelijke beschrijving van wat het teruggeeft. Die ene tool doet het samenvoegen en filteren aan de serverkant, waar jij de controle hebt, en geeft een compact resultaat terug. Je hebt het moeilijke werk verplaatst van een probabilistisch systeem naar een deterministisch systeem, en dat is de hele essentie.

‍

Het contextvenster is de echte beperking

Elke tooldefinitie die je publiceert kost tokens voordat de agent überhaupt iets heeft gedaan, omdat de client de hele lijst naar het model stuurt. Negentig uitgebreide schema's vreten bij verbinding een aanzienlijk deel van de beschikbare context op, en elk resultaat dat je terugstuurt kost nog meer. Een sessie die opgeblazen begint en opgeblazen payloads teruggeeft, heeft minder ruimte voor het eigenlijke werk, en dat is precies het moment waarop modellen slechte beslissingen nemen.

Minder, betere tools zijn beter dan volledige dekking. In de praktijk betekent dit meestal 10 tot 25 goed gekozen tools in plaats van één per endpoint, waarbij de rest via je API verloopt, precies waar het hoort.

‍

Dubbelzinnigheid is duurder dan ooit tevoren

Als twee tools bijna hetzelfde doen en hun beschrijvingen maken geen onderscheid, kiest het model min of meer willekeurig tussen beide, zonder aan te geven dat het gokt. Een ontwikkelaar lost dit op door je documentatie te lezen. Een agent lost het op door een keuze te maken en door te gaan.

Dit maakt toolbeschrijvingen tot cruciale productteksten. Ze moeten duidelijk maken wat de tool doet, wanneer je deze gebruikt in plaats van een vergelijkbare tool, wat het resultaat is en wat de kosten zijn. We hebben de nauwkeurigheid van onze agents meer verbeterd door vijf beschrijvingen te herschrijven dan door nieuwe functionaliteiten toe te voegen.

‍

‍

Download de SaaS AI-blueprint

Als je momenteel voor deze keuze staat, behandelt onze AI-blueprint voor SaaS-oprichters hoe je het AI-oppervlak bepaalt voor een product dat al betalende klanten heeft, inclusief waar agent-toegang waarde toevoegt en waar het alleen maar leidt tot supporttickets. Het is gratis en kost ongeveer 20 minuten om te lezen.

‍

Wat we leerden van het draaien van MCP-servers in productie

We schrijven dit niet als buitenstaanders. Bij Codelevate bouwen en beheren we MCP-integraties voor klantplatforms en we gebruiken ze dagelijks op onze eigen systemen, inclusief de content-pipeline die dit artikel heeft gegenereerd. Vier fouten hebben ons het meest gekost, en geen daarvan staat in de protocol-documentatie.

‍

Eén list-aanroep leverde 1,6 miljoen tekens op

We koppelden een agent aan een CMS om een routinematige content-audit uit te voeren. Het eerste wat de agent deed, was de list-items tool aanroepen met een redelijke limiet van 100. Die tool gaf elk veld van elk item terug, inclusief volledige artikelteksten. Het antwoord was meer dan 1,6 miljoen tekens, wat veel meer is dan de agent kan verwerken, waardoor de sessie effectief voorbij was voordat er enig werk was verzet.

Er was niets kapot. De API deed precies wat er werd gevraagd. Het ontwerp was fout. Een list-tool voor agents heeft een harde limiet nodig voor de responsgrootte, veldprojectie zodat aanroepers alleen identifiers en samenvattingen krijgen in plaats van volledige objecten, en een aparte get-detail tool voor het specifieke record dat er echt toe doet. Als je tool een onbeperkte payload kan teruggeven, ga er dan vanuit dat dit gebeurt, bij de eerste aanroep, voor de ogen van je belangrijkste klant.

‍

Een succesvolle respons is geen bewijs voor een correct resultaat

We schrijven content naar een CMS via de API. De schrijfactie geeft een 200-statuscode terug, de opgeslagen waarde is exact gelijk aan wat we hebben verstuurd, en toch ziet de gepubliceerde pagina er verkeerd uit. Dit komt doordat het platform na het schrijven bepaalde opmaak normaliseert en stilletjes verwijdert wat het niet zint. Controleren door de ruwe opgeslagen waarde uit te lezen helpt hier niet; alleen het uitlezen van de gerenderde output werkt.

Dat is een bug in dat specifieke systeem, maar de les is breder toepasbaar. Agents kunnen je UI niet zien, dus elke stille transformatie tussen het accepteren van input en het tonen van output is voor hen onzichtbaar en ze zullen vol vertrouwen rapporteren dat het gelukt is. Als je product normaliseert na een schrijfactie, bied agents dan een verificatiepad dat de uiteindelijke status weerspiegelt en documenteer deze beperking in de toolbeschrijving.

‍

Schrijfacties hebben een veilige standaardinstelling nodig, geen bevestigingsvenster

Onze CMS-tools publiceren nooit direct. Ze maken concepten aan. Een mens controleert en publiceert deze vervolgens. Dat is een bewuste beperking, en het heeft ons meer dan eens gered toen een agent een instructie verkeerd begreep en het verkeerde op de verkeerde plek aanmaakte. De kosten van die fout bleven beperkt tot het verwijderen van een concept.

MCP ondersteunt menselijk toezicht via goedkeuringsvensters en permissie-instellingen, en die moet je ook gebruiken. Maar goedkeuringsmoeheid is een reëel probleem; een gebruiker die al 40 keer op goedkeuren heeft geklikt, leest de 41e keer niet meer. De sterkere bescherming is het gebruik van schrijftools waarvan de ergste uitkomst herstelbaar is: maak concepten in plaats van te publiceren, zet klaar in plaats van door te voeren, doe voorstellen in plaats van uit te voeren. Reserveer harde bevestigingen alleen voor die weinige operaties die echt niet ongedaan gemaakt kunnen worden.

‍

Toolnamen botsen zodra er meer dan één server is verbonden

Echte agentsessies maken verbinding met meerdere servers tegelijk. Die van jou is niet de enige in de lijst. Als je een tool genaamd search of update_item uitbrengt, concurreert deze met de generieke tools van elke andere leverancier om de aandacht van het model, en soms zal het model die van hen aanroepen terwijl het die van jou bedoelde. Het toevoegen van een namespace aan je toolnamen en het in de beschrijvingen vermelden van het systeem waarop ze acteren, is een kleine wijziging met een meetbaar effect op de nauwkeurigheid.

‍

‍

Het beveiligingsmodel waar het platformteam van je klant naar zal vragen

Verwacht dat dit gesprek serieuzer zal zijn dan een normale API-beveiligingsreview, omdat een MCP-server een probabilistisch systeem de mogelijkheid geeft om binnen je product te handelen. Drie gebieden komen telkens terug.

Het eerste is identiteit en scope. Je klant wil dat de agent handelt als een specifieke gebruiker met de bijbehorende permissies, niet als een service-account dat de sleutels tot de hele tenant in handen heeft. Als je autorisatiemodel alleen brede API-sleutels ondersteunt, is dat het werk dat je moet verzetten voordat je überhaupt tools gaat bouwen. Tenant-isolatie moet bij elke aanroep standhouden, ook bij de aanroepen die eruitzien als onschuldige leesacties.

Het tweede is waar het model bij mag. Agents roepen alles aan wat je blootstelt, en een tool die de gegevens van andere klanten teruggeeft door een ontbrekend filter is een inbreuk, geen bugrapport. Zakelijke klanten willen steeds vaker per tool kunnen bepalen wat de scope is, zodat een beheerder schrijftools volledig kan uitschakelen, of leesacties in de hele workspace kan toestaan terwijl schrijfacties tot één project worden beperkt.

Het derde is auditability. Elke tool-aanroep heeft een logregel nodig met de actieve gebruiker, de argumenten, het resultaat en de tijdstempel, in een formaat dat een beveiligingsteam kan doorzoeken. Wanneer er iets misgaat in een agent-workflow – en dat zal gebeuren – is het vermogen om exact te reconstrueren wat er door wie is aangeroepen het verschil tussen een incident en een oplossing van vijf minuten.

Prompt-injectie verdient vermelding. Als je tools content teruggeven die gebruikers kunnen schrijven, zoals ticketteksten, opmerkingen of bestandsinhoud, kan die content instructies bevatten die op het model zijn gericht. Behandel alles wat een tool teruggeeft als data, nooit als instructies, en vermeld dit expliciet in je documentatie. Klanten met volwassen AI-programma's vragen hier nu naar, en een duidelijk antwoord valt op.

‍

Bouwen, kopen of afwachten: hoe maak je de keuze

De denkwijze die teams op een dwaalspoor brengt, is dit als een binaire keuze te zien. Het is een portfoliobeslissing, en voor de meeste SaaS-bedrijven is de juiste aanpak een combinatie van beide.

Bouw zelf wanneer het agent-oppervlak deel uitmaakt van de waarde van je product. Als je onderscheidend vermogen ligt in een eigen datamodel, een unieke workflow of een gereguleerde dataset, dan is de manier waarop agents daarmee interageren een productbeslissing die je niet moet uitbesteden. Bouw ook zelf als je permissiemodel ongebruikelijk is; beheerde platforms gaan uit van conventionele scopes en daar zul je tegenaan lopen.

Koop de standaardoplossingen. Als je agent-toegang nodig hebt tot standaardobjecten via standaard authenticatie, dan bereik je je doel sneller en goedkoper met een beheerd MCP-platform dan wanneer een team voor het eerst transport, sessiebeheer en token-vernieuwing moet leren. Er is geen strategisch voordeel in het voor de vijfde keer zelf bouwen van OAuth.

Wacht als niemand erom vraagt. Echt waar. Als geen enkele klant erom vraagt, geen concurrent het aanbiedt en niemand een agent-workflow kan beschrijven, dan wordt een server op basis van speculatie gebouwd voor imaginaire use-cases. Deze zal moeten worden herschreven zodra de echte behoeften duidelijk worden. Drie maanden wachten en bouwen op basis van twee concrete klant-workflows levert een beter resultaat op dan vandaag iets generieks uitbrengen.

De kostenkwestie verdient ook eerlijkheid. Een werkende demo kost dagen. Een productieserver met echte authenticatie, tenant-isolatie, rate limiting, audit logging, versiebeheer en ondersteuning is een serieus technisch project met doorlopend onderhoud. Volgens industriestandaarden kost het jaarlijkse onderhoud tienduizenden euro's. Begroot voor het tweede jaar, niet alleen voor de lancering.

‍

‍

Een stappenplan van 90 dagen voor een MCP-server die klaar is voor gebruik

Wanneer we dit met een klant doorlopen, ziet het proces er bijna altijd hetzelfde uit, en de eerste maand bevat helemaal geen protocolwerk.

Schrijf in de eerste 30 dagen de 5 taken op die klanten daadwerkelijk aan een agent in jouw product zouden vragen. Haal deze uit echte gesprekken, niet uit een workshop. Formuleer elke taak als een zin die een gebruiker zou uitspreken. Controleer vervolgens of je API elke taak in één of twee aanroepen kan uitvoeren. Meestal is dat niet zo, en dat gat is waar het echte werk ligt.

Ontwerp in de volgende 30 dagen de toolset op basis van die taken. Richt je op 10 tot 20 tools. Schrijf de beschrijvingen vóór de implementaties, want de beschrijving is de interface. Bepaal wat in resources thuishoort in plaats van in tools. Stel voor elke leesactie responslimieten en veldprojecties in. Kies een veilige standaardinstelling voor elke schrijfactie.

Hard en test het in de laatste 30 dagen met agents, niet met een testsuite. Voer echte prompts uit je takenlijst uit via ten minste 2 verschillende clients en kijk waar het model de fout in gaat. Elke verkeerde toolkeuze is een probleem van de beschrijving of de afbakening; het nu oplossen is goedkoop, na de lancering is het duur. Voeg audit logging en per-tool scoping toe voordat de eerste klant verbinding maakt, niet pas nadat hun security-team erom vraagt.

Lever het aan 3 klanten voordat je het aankondigt. Agent-gedrag onder echte data is niet iets wat je kunt voorspellen vanuit een staging-omgeving.

‍

Hoe we dit bij Codelevate aanpakken

We behandelen de MCP-server als een productoppervlak met een eigen ontwerpfase, wat in de praktijk betekent dat de eerste oplevering een takenlijst en een tool-specificatie is, geen code. Onze AI-ontwikkeling -teams bouwen eerst de deterministische laag onder de tools, omdat elk stukje logica dat je naar de server verplaatst, een beslissing is die het model niet meer zelf hoeft te nemen. Daarna testen we met echte agents tegen echte data voordat er iets wordt blootgesteld aan een klant.

De reden dat we hier zo uitgesproken over zijn, is dat we het zelf uitvoeren. De hierboven beschreven fouten zijn van onszelf, op de dure manier ontdekt in live systemen. Als je nog in een eerdere fase zit en agents verbindt met interne systemen in plaats van ze aan klanten bloot te stellen, bekijk dan onze gids voor het verbinden van AI-agents met je bestaande systemen dekt die fase af.

‍

De kernboodschap

Een MCP-server voor SaaS is geen integratieklus en het is niet simpelweg je REST API in een ander jasje. Het is de interface waarmee een redenerend systeem zonder context en met een beperkt budget probeert je product te gebruiken. Als je dit goed ontwerpt, wordt jouw platform het platform waar een agent naar grijpt – en dat zal binnenkort net zo belangrijk zijn als het platform waar een gebruiker naar grijpt. Als je dit slordig aanpakt, wordt jouw product de bron van foutieve antwoorden.

De transformatie waar je naar moet streven is simpel: van een product dat onzichtbaar is voor agents, naar een product dat agents correct gebruiken en waar een securityteam zonder slag of stoot akkoord mee gaat.

Wil je het grotere plaatje zien van de rol van AI in een product dat al klanten heeft? De AI-blauwdruk voor SaaS-oprichters is gratis en behandelt de keuzes die je moet maken voordat je aan dit alles begint. En als je dit liever bespreekt aan de hand van je eigen roadmap, boek dan een gratis gesprek met ons team en we geven je eerlijk advies of je moet bouwen, kopen of wachten.