Het instellen staat op de Cursor-pagina. Deze post gaat over de vraag die ontwikkelaars en consultants stellen: waarom zou je je ERP in je code-editor willen?
Wie gebruikt dit, en waarvoor?
Cursor is een code-editor met een ingebouwde AI-assistent. De doelgroep voor deze koppeling is dan ook niet de administratie maar de mensen die eromheen bouwen: consultants die een Exact Online-implementatie inrichten, ontwikkelaars die een koppeling schrijven, en beheerders die uitzoeken waarom een order niet doorkomt.
Het voordeel is dat je de administratie kunt bevragen zonder je editor te verlaten en zonder een testscript te schrijven. Je vraagt gewoon wat er in de data staat.
Drie situaties waarin dit echt scheelt
- Een orderflow debuggen. "Zoek order SO-2026-0412 en laat alle regels zien met hun leverstatus." Sneller dan inloggen, zoeken en doorklikken.
- Een implementatie controleren. "Welke artikelen hebben geen kostprijs ingevuld?" Precies het soort datacontrole dat je tijdens een inrichting tientallen keren doet.
- Een koppeling bouwen. Terwijl je code schrijft die Exact Online-data verwerkt, kun je in hetzelfde venster kijken hoe die data er in werkelijkheid uitziet - inclusief de randgevallen die je anders pas in productie tegenkomt.
Waar je tegenaan loopt
Dit is geen vervanging van de API. Bouw je een productiekoppeling, dan doe je dat op de Exact Online REST API. De MCP-koppeling is bedoeld om tijdens het bouwen te kunnen kijken, niet om in je applicatie te gebruiken. Zie MCP versus de API.
Let op met schrijftoegang in een productieadministratie. Debuggen doe je bij voorkeur alleen-lezen. Wil je schrijfacties testen, doe dat dan in een testadministratie.
De context is je gesprek, niet je codebase. Cursor kent je code en je administratie, maar legt niet automatisch verband. Noem expliciet waar je naar zoekt.
Hoe verder
Wil je weten welke tools er precies beschikbaar zijn, kijk dan in de toolcatalogus. Voor de technische werking van het protocol: de begrippenlijst.
Waarom dit sneller is dan de gebruikelijke route
De gebruikelijke manier om te controleren wat er in een administratie staat, is inloggen op Exact Online, doorklikken naar het juiste scherm, filters instellen en kijken. Als je dat tien keer per dag doet tijdens een implementatie, kost dat merkbaar tijd - en je verliest steeds even de context van waar je in je code mee bezig was.
Het alternatief was een testscript schrijven dat de API aanroept. Dat kost eerst opzet: OAuth regelen, een token bewaren, de juiste endpoint opzoeken. Voor een eenmalige vraag is dat te veel werk, dus doe je het niet en klik je alsnog.
De MCP-koppeling haalt die drempel weg. Je stelt de vraag in het venster waar je toch al bent en krijgt het antwoord terug zonder iets te bouwen.
Waar het minder geschikt voor is
Twee dingen waarvoor je beter iets anders pakt. Bulkbewerkingen horen niet hier: wil je duizend artikelen bijwerken, schrijf dan een script tegen de API met fatsoenlijke foutafhandeling en logging. En herhaalbare controles die je elke sprint wilt draaien, horen in een testsuite, niet in een gesprek dat je elke keer opnieuw voert.
De koppeling is op zijn best bij eenmalige vragen waarvan je het antwoord niet vooraf kent. Precies het werk waar je anders een wegwerpscript voor zou schrijven.
Een praktische werkwijze
Houd tijdens een implementatie een lijstje bij van datacontroles die je steeds opnieuw doet: artikelen zonder kostprijs, klanten zonder btw-nummer, orders die blijven hangen in een status. Zet die als vragen in een notitie naast je project. Bij elke wijziging loop je ze in een paar minuten door, zonder in te loggen.