Setup is covered on the Cursor page. This post answers the question developers and consultants actually ask: why would you want your ERP inside your code editor?
Who uses this, and for what?
Cursor is a code editor with a built-in AI assistant. The audience for this integration is therefore not the bookkeeping team but the people building around it: consultants configuring an Exact Online implementation, developers writing an integration, and administrators working out why an order is not coming through.
The advantage is that you can query the administration without leaving your editor and without writing a test script. You just ask what is in the data.
Three situations where this genuinely helps
- Debugging an order flow. "Find order SO-2026-0412 and show all lines with their delivery status." Faster than logging in, searching and clicking through.
- Checking an implementation. "Which items have no cost price filled in?" Exactly the kind of data check you run dozens of times during a configuration.
- Building an integration. While writing code that processes Exact Online data, you can look at what that data actually looks like in the same window - including the edge cases you would otherwise only meet in production.
What you will run into
This is not a replacement for the API. If you are building a production integration you do that on the Exact Online REST API. The MCP integration is meant for looking while you build, not for use inside your application. See MCP versus the API.
Be careful with write access on a production administration. Debug read-only by preference. If you want to test write actions, do it in a test administration.
The context is your conversation, not your codebase. Cursor knows your code and your administration but does not automatically connect them. State explicitly what you are looking for.
Where to go next
To see exactly which tools are available, browse the tool catalogue. For how the protocol works: the glossary.
Why this is faster than the usual route
The usual way to check what is in an administration is to log in to Exact Online, click through to the right screen, set filters and look. Do that ten times a day during an implementation and it costs noticeable time - and each time you lose the context of what you were doing in your code.
The alternative was writing a test script that calls the API. That costs setup first: arrange OAuth, store a token, find the right endpoint. For a one-off question that is too much work, so you skip it and click through after all.
The MCP integration removes that threshold. You ask the question in the window you are already in and get the answer back without building anything.
What it is less suited for
Two things you should reach elsewhere for. Bulk operations do not belong here: to update a thousand items, write a script against the API with proper error handling and logging. And repeatable checks you want to run every sprint belong in a test suite, not in a conversation you hold again each time.
The integration is at its best on one-off questions whose answer you do not know up front. Exactly the work you would otherwise write a throwaway script for.
A practical way to work
During an implementation, keep a list of data checks you keep repeating: items without a cost price, customers without a VAT number, orders stuck in a status. Put them as questions in a note beside your project. After every change you run through them in a couple of minutes, without logging in.