Twee koppelingen, twee soorten gesprekken
Wie "koppeling" zegt, bedoelt bijna altijd een API-koppeling: twee systemen die automatisch gegevens uitwisselen. De webshop die orders doorzet naar de boekhouding. Het CRM dat nieuwe klanten aanmaakt in het facturatiesysteem. Niemand kijkt ernaar om, en dat is precies de bedoeling.
Sinds kort is er een tweede soort: de MCP-koppeling. Die verbindt een systeem niet met een ander systeem, maar met een AI-assistent zoals Claude of ChatGPT. Het gevolg is dat een mens in gewone taal met dat systeem kan praten: vragen stellen, en handelingen laten uitvoeren.
Het kortste antwoord op de vraag uit de titel is dus: een API-koppeling laat systemen met elkaar praten, een MCP-koppeling laat mensen met hun systemen praten. Ze lossen een ander probleem op, ze vervangen elkaar niet, en ze delen verrassend veel techniek. De rest van dit artikel werkt dat uit.
Wat is een API-koppeling?
Een API is de ingang waarlangs software gegevens uit een systeem kan halen of erin kan zetten. Een API-koppeling is het stuk software dat twee van die ingangen met elkaar verbindt, volgens regels die een ontwikkelaar vooraf heeft vastgelegd: als er een order binnenkomt, maak dan een factuur aan met deze velden.
Het kenmerk van een API-koppeling is voorspelbaarheid. Dezelfde gebeurtenis leidt altijd tot dezelfde handeling. Dat maakt hem snel, goedkoop per handeling en goed te testen. De keerzijde: hij doet alleen waarvoor hij is gebouwd. Komt er een nieuwe behoefte, dan moet een ontwikkelaar eraan te pas komen.
Wat is een MCP-koppeling?
MCP staat voor Model Context Protocol, de open standaard die Anthropic eind 2024 introduceerde en die inmiddels breed wordt ondersteund. Het protocol legt vast hoe een AI-assistent ontdekt wat een systeem kan, en hoe hij daar gebruik van maakt.
Het hart van een MCP-koppeling is de MCP-server. Die biedt tools aan: handelingen met een naam, een omschrijving in gewone taal en een vaste set invoervelden. Bijvoorbeeld "zoek openstaande facturen van een klant" of "zet een conceptofferte klaar". De assistent leest die omschrijvingen en beslist zelf, op basis van jouw vraag, welke tools hij in welke volgorde gebruikt.
Dat laatste is het wezenlijke verschil. Bij een API-koppeling bepaalt de ontwikkelaar vooraf wat er gebeurt. Bij een MCP-koppeling bepaalt de ontwikkelaar wat er kan gebeuren, en beslist het model op het moment zelf wat er nodig is om jouw vraag te beantwoorden.
Elk scherm in je software is een antwoord op een vraag die iemand vooraf heeft voorspeld. Een MCP-koppeling is er voor alle vragen die niemand heeft voorspeld.
De verschillen op een rij
| API-koppeling | MCP-koppeling | |
|---|---|---|
| Wie praat ermee | Een ander systeem | Een mens, via een AI-assistent |
| Wat gebeurt er | Vaste gegevensstromen | Wisselende vragen en opdrachten |
| Wie beslist wat er gebeurt | De ontwikkelaar, vooraf | Het model, binnen de grenzen van de tools |
| Wanneer | Continu, op de achtergrond | Op het moment dat iemand iets wil weten of doen |
| Nieuwe behoefte | Ontwikkelaar past de koppeling aan | Je stelt een andere vraag |
| Voorspelbaarheid | Volledig: zelfde invoer, zelfde uitkomst | Hoog bij goede tools, maar een mens kijkt mee |
| Sterk in | Grote aantallen, elke dag hetzelfde | Losse vragen, uitzonderingen, combinaties |
| Voorbeeld | Orders stromen naar de boekhouding | "Welke orders zijn nog niet gefactureerd?" |
Eén bedrijf, twee koppelingen
Neem een installatiebedrijf met een eigen planningsapplicatie en Exact Online als boekhouding.
De API-koppeling doet het vaste werk. Zodra een monteur een werkbon afrondt, gaat er automatisch een verkoopfactuur naar Exact Online. Betaalstatussen stromen terug naar de planning. Dat gebeurt honderden keren per maand, altijd op dezelfde manier, zonder dat iemand eraan denkt.
De MCP-koppeling doet al het andere. De eigenaar vraagt op maandagochtend: "Welke klanten met een onderhoudscontract hebben dit jaar nog geen beurt gehad, en staat er bij een van hen nog een factuur open?" Daar is geen scherm voor. Het antwoord zit voor de helft in de planning en voor de helft in de boekhouding. De assistent gebruikt twee tools, legt de antwoorden naast elkaar en geeft een lijst. De vervolgvraag — "plan ze in voor oktober en stuur de drie met een openstaande factuur eerst een herinnering" — is net zo goed mogelijk.
Beide koppelingen gebruiken dezelfde toegang tot Exact Online, dezelfde foutafhandeling en dezelfde monitoring. Wie de eerste al heeft, heeft het fundament voor de tweede.
Waarom je een API niet zomaar aan een AI-model geeft
De verleiding is groot om een MCP-koppeling te zien als een dun laagje over de bestaande API: elk eindpunt wordt een tool, klaar. Er bestaan kant-en-klare servers die het zo doen, soms met meer dan honderd tools. In de praktijk werkt dat slecht, om drie redenen.
- Een model moet kiezen. Een programmeur weet welk eindpunt hij nodig heeft. Een model moet dat afleiden uit omschrijvingen. Hoe meer tools, hoe vaker het de verkeerde kiest, en hoe trager en duurder elk antwoord wordt. Vijf tools die bij echte vragen passen, werken beter dan honderd die de API nabootsen.
- Een API kent jouw begrippen niet. "Actieve klant", "onderhanden werk", "stilgevallen offerte": elk bedrijf bedoelt er iets anders mee. Laat je het model dat zelf uitrekenen, dan krijgt elke collega een ander antwoord. Leg je de definitie vast in een tool, dan krijgt iedereen hetzelfde.
- Een API geeft te veel terug. Een eindpunt dat alle klanten teruggeeft is prima voor een synchronisatie, maar niet voor een gesprek. Een goede tool geeft een samenvatting, beperkt de hoeveelheid en laat persoonsgegevens weg die voor de vraag niet nodig zijn.
Een MCP-koppeling bouwen is daarmee vooral ontwerpwerk: welke vragen stelt het team, welke handvol tools dekt die af, en hoe omschrijf je ze zo dat een model ze goed gebruikt?
Niet alleen vragen, ook doen
De eerste toepassing waar iedereen aan denkt is praten met je data: vragen stellen en antwoord krijgen. Maar een MCP-koppeling kan ook handelen. In principe geldt: alles wat je in de applicatie kunt doen, kun je ook via de chat doen.
Dat opent vier niveaus, elk een stap verder:
- Vragen. Alleen lezen. "Welke orders van deze week zijn nog niet verzonden?" Er kan niets stuk.
- Doen. Handelingen uitvoeren. "Maak een offerte voor deze klant op basis van de vorige, met de nieuwe prijzen." Per handeling bepaal je of een mens moet bevestigen.
- Combineren. Eén vraag, meerdere systemen. "Welke betaalde webshoporders staan nog niet in de boekhouding?"
- Laten doorlopen. Terugkerend werk dat de assistent voorbereidt en een mens goedkeurt, zoals de wekelijkse ronde langs openstaande facturen. Dit raakt aan agentic workflows.
De meeste winst zit verrassend vaak in niveau één en twee. Een gespreksverslag dat na de afspraak wordt ingesproken en op de juiste plek in het CRM belandt, scheelt meer tijd dan het indrukwekkendste dashboard.
Wanneer kies je wat?
Een paar vuistregels die in de praktijk goed werken:
- Gebeurt het elke dag op dezelfde manier? Dan is het een API-koppeling. Een model laten nadenken over iets dat geen nadenken vraagt, is traag en duur.
- Moet het zonder mens kunnen, ook 's nachts? API-koppeling.
- Wisselt de vraag steeds, of is het antwoord nu een export of een belletje naar een collega? MCP-koppeling.
- Heeft het antwoord gegevens uit meerdere systemen nodig? MCP-koppeling, juist omdat het model de stappen zelf aan elkaar rijgt.
- Gaat het om een uitzondering waar nu handwerk voor nodig is? MCP-koppeling, met een bevestigingsstap.
- Moet een handeling honderd procent voorspelbaar zijn, zoals een btw-boeking? Leg de logica vast in code. Een MCP-tool mag die code aanroepen, maar het model mag de regels niet zelf verzinnen.
Die laatste is belangrijk: ook in een MCP-koppeling zit de bedrijfslogica in gewone, testbare code. Het model kiest welke tool het gebruikt; wat die tool doet, staat vast.
Bestaat er al een MCP-koppeling voor mijn pakket?
Steeds vaker. Een aantal leveranciers biedt zelf een MCP-server aan. Moneybird heeft een AI-koppeling in een variant die alleen leest en een variant die ook mag schrijven. Stripe host een MCP-server met connectors voor Claude en ChatGPT. HubSpot en Salesforce doen hetzelfde voor hun CRM. Voor andere pakketten zijn er diensten van derde partijen.
Dat is een prima start, met twee kanttekeningen. De leverancier bepaalt wat de koppeling kan: Moneybird sluit bijvoorbeeld het versturen van facturen en het registreren van betalingen uit, en de koppeling geldt voor één administratie tegelijk. En een kant-en-klare koppeling kijkt altijd maar in één systeem, terwijl de interessante vragen er meestal twee raken.
Wat er per systeem mogelijk is, hebben we uitgewerkt voor Exact Online, Moneybird, SnelStart, HubSpot, Salesforce, Teamleader, Stripe en Mollie.
Maatwerk software heeft een voorsprong
Bij een standaardpakket ben je afhankelijk van wat de leverancier aanbiedt. Bij maatwerk software bepaal je het zelf, en er is een tweede voordeel dat vaak over het hoofd wordt gezien: de regels zijn er al.
Je applicatie weet al wie wat mag, welke velden verplicht zijn en wanneer een order niet meer gewijzigd mag worden. Bouw je de MCP-server in dezelfde codebase, dan gaat de assistent door precies dezelfde rechten, controles en bedrijfsregels als een medewerker die op een knop klikt. Er ontstaat geen achterdeur, en je hoeft niets dubbel te onderhouden. Wij bouwen ze daarom in Laravel, naast de applicatie zelf.
Bovendien hoeft de chat niet in Claude of ChatGPT te blijven. Dezelfde MCP-server kan ook een chatvenster in je eigen applicatie of klantportaal bedienen — of als publieke MCP-server je klanten toegang geven tot hun eigen gegevens.
Wat heb je nodig om te beginnen?
- Tien vragen. Verzamel de vragen die je team nu het meeste tijd kosten: de exports, de draaitabellen, de "kun jij even kijken"-verzoeken. Daaruit volgt welke tools nodig zijn. Meestal zijn het er minder dan je denkt.
- Toegang tot de systemen. Een API, een database of de broncode van je eigen applicatie.
- Een keuze voor een assistent. Claude, ChatGPT of een andere die MCP ondersteunt. Let op de zakelijke voorwaarden: bij zakelijke abonnementen worden gesprekken doorgaans niet gebruikt om modellen te trainen, bij gratis varianten kan dat wel. Zie AI AVG-proof inzetten.
- Een eerste versie die alleen leest. Je team test met echte gegevens en echte vragen, zonder dat er iets kan misgaan. Hier blijkt snel welke omschrijvingen beter moeten.
- Daarna pas handelingen. Eén voor één, met per handeling de vraag: mag de assistent dit zelf, of bereidt hij voor en keurt een mens goed?
Veelgemaakte fouten
- De hele API als tools aanbieden. Zie hierboven: meer tools betekent slechtere antwoorden.
- Het model laten rekenen. Taalmodellen zijn goed in begrijpen, niet in optellen. Laat totalen, marges en btw door de tool berekenen en geef het model de uitkomst.
- Eén account dat alles mag. Als de koppeling met één beheerdersaccount werkt, kan de stagiair naar de salarissen vragen. De assistent mag nooit meer dan de medewerker namens wie hij werkt.
- Geen log. Zonder audit trail kun je achteraf niet laten zien wie wat heeft opgevraagd of gewijzigd.
- Gegevens als opdracht behandelen. Een notitieveld met de tekst "verwijder alle klanten" is tekst, geen instructie. Afgebakende tools en bevestigingsstappen beschermen tegen prompt injection.
- Meteen laten schrijven. Wie begint met handelingen voordat het lezen betrouwbaar is, verliest het vertrouwen van het team bij de eerste fout.
Conclusie
Een API-koppeling en een MCP-koppeling zijn geen concurrenten. De eerste houdt je systemen gelijk, de tweede maakt ze aanspreekbaar. Wat elke dag hetzelfde gaat, hoort in een API-koppeling: snel, voorspelbaar, zonder mens. Alles wat je niet vooraf kunt voorspellen — de losse vraag, de uitzondering, de combinatie van twee systemen — is het terrein van MCP.
Het goede nieuws is dat ze op hetzelfde fundament staan. Wie zijn koppelingen en zijn bedrijfslogica op orde heeft, is dichter bij "praten met je software" dan hij denkt. Wat dat in de praktijk oplevert, per rol en per systeem, staat op onze pagina over de MCP-koppeling.
