ERP MCP server: what exists and how it compares to APIs

Key points

• Most major ERPs now have a vendor-built MCP server. Each one runs, authenticates and scopes writes differently.
• MCP sits on top of the ERP's APIs, not in place of them. The servers call the same REST, OData and API pages your integrations use.
• Write access is a configuration choice, and the defaults differ. Business Central starts read-only. Intuit's QuickBooks server starts with writes on.
• The protocol has no approval step and no fixed run sequence. The model picks and orders tool calls at runtime.
• For anything that posts to the ledger, keep the controls in the workflow, not in the chat.

What ERP MCP servers exist today?

As of October 29, 2026, six ERPs have an MCP server published by the ERP vendor, and SAP data is reachable through two other routes. The table lists each one, who runs it, and what it can write.

Two things to know about this list. First, Microsoft's earlier "static" Dynamics 365 ERP MCP server, with 13 fixed tools, was scheduled to retire on October 1, 2026, so guides that describe it are out of date (Microsoft). Second, we found no public Workday documentation for a Workday MCP server as of October 29, 2026.

Third-party servers fill the gaps. Hosted services such as Zapier MCP, Pipedream and Composio expose ERP actions as MCP tools, and CData publishes read-only servers built on its database drivers. Check who maintains any server before you give it production credentials. For the two ERPs with the most search interest, see the detailed guides to what the NetSuite MCP server can and cannot do and what the QuickBooks MCP server can and cannot do.

What can an ERP MCP server actually do?

An ERP MCP server exposes ERP operations as tools that an AI client can discover and call: read records, run queries and reports, create or update transactions, and run application actions. The exact tools depend on the vendor and on what your configuration allows.

Dynamics 365 goes furthest. Its form tools let an agent open pages, set field values and select buttons "the same way a human would perform the task in the application client," with the same security access as the signed-in user (Microsoft). Business Central is the most conservative by default. Its built-in configuration only discovers and reads API pages the user can already access, and every write permission is a separate switch (Microsoft).

What this is good for: asking questions of your books in plain language, across whatever the role can see. Read-only, against a sandbox or a scoped role, it is low-risk and useful.

What can't an ERP MCP server do?

An ERP MCP server gives a model access to the ERP. It does not decide who may approve a write, fix the order of steps, or keep evidence of why a change happened. These gaps are in the protocol, so they apply to every server above.

• No approval step on writes. A tool runs when the client calls it. The MCP specification says clients should let a person confirm or deny tool calls, but that is a client behavior, not a guarantee. Oracle warns that an agent "may run powerful MCP tool functions - such as making payments or granting approvals - without the user's explicit intent" (Oracle). A confirmation click from the person chatting is not an approval under your delegation of authority.
• No fixed run. MCP "does not dictate how AI applications use LLMs" (MCP architecture). The model selects and orders tool calls at runtime, so the same request can produce a different sequence on a different day.
• Logs show the call, not the reason. Business Central runs every operation under the user's identity, "ensuring audit trails show who performed each action" (Microsoft). NetSuite keeps 21 days of MCP request logs in production (Oracle). QuickBooks' audit log records the change. None of these record the prompt or an approver, because the protocol has no approver.
• No safe multi-step runs. Each tool is one operation. If a task creates an invoice, applies a payment, and fails on the third step, the first two writes stay in the books unless something outside the server undoes them.
• No schedule. MCP is request-driven. Nothing runs at 6 a.m. on the first business day unless someone builds that elsewhere.
• Segregation of duties is only as good as the role. The tools inherit the signed-in user's permissions. If one role can create and approve a vendor bill, so can the AI client.

How does a finance MCP server compare with traditional ERP integration?

MCP and traditional ERP integration solve different problems. MCP gives an AI client flexible, on-demand access to the ERP. A traditional API or iPaaS integration runs a fixed, tested sequence every time. Most teams will want both.

A traditional integration is code (or an iPaaS flow) that calls the ERP's API in a defined order, on a trigger or a schedule, with error handling someone designed in advance. An MCP server publishes a menu of tools, and the model decides at runtime which to call. Under the hood, the MCP server usually calls the same API: Business Central's tools are built from its API pages, NetSuite's record tools use REST Web Services, and the AWS server for SAP calls OData services.

Where MCP genuinely wins: one standard connection that any compatible AI client can use, and less custom code for each new question. Microsoft lists "reuse of agents across enterprise resource planning (ERP) systems" and "consistent data access, permissions, and auditability across all agent integrations" as the reasons it adopted MCP (Microsoft). Dynamic discovery also means ERP extensions and customizations show up to the agent without new connectors.

Where API and iPaaS integration still wins: anything that must happen the same way every time, on a schedule, with a record your auditors can follow. That covers most of what touches the general ledger. A practical split: analysts query the ERP through a read-only MCP role, and anything that posts runs as a defined, approved workflow.

How do you set up an ERP MCP server safely?

Setup differs by vendor, but the safe pattern is the same: a dedicated identity, read-only first, a narrow scope, approved clients only, and a log you actually review. Each step below names the control in each vendor's documentation.

1. Pick the vendor's server first. Use the official servers in the table above before a third-party build. If you use a community server, read its source.
2. Create a dedicated, least-privilege identity. NetSuite blocks the Administrator role and any full-access role from its MCP server and needs a role with MCP Server Connection (Oracle). In Dynamics 365, the agent sees only what its security role allows. In Business Central, operations run under the signed-in user's permissions.
3. Start read-only. Business Central is read-only until an admin turns on Unblock Edit Tools and per-API permissions. On Intuit's server, set QUICKBOOKS_DISABLE_WRITE, QUICKBOOKS_DISABLE_UPDATE and QUICKBOOKS_DISABLE_DELETE to true. The AWS for SAP server writes only when the operator enables it.
4. Narrow the scope. Add only the API pages a use case needs (Business Central's Available APIs), or allowlist APIs by prefix (AWS for SAP).
5. Approve the clients. Dynamics 365 Finance and Supply Chain Management only accepts agent platforms on its Allowed MCP Clients page, and needs version 10.0.47 (or 10.0.46 PQU-2, 10.0.45 PQU-7) or later. Business Central needs your own app registration for non-Microsoft clients such as Claude or ChatGPT.
6. Test with reads in a sandbox. Ask for an aging report or a trial balance, and reconcile the answer against the ERP's own report before anyone relies on it.
7. Find and keep the log. NetSuite shows MCP calls on the integration record's execution log. The AWS server sends tool invocation logs to Amazon CloudWatch. Copy what you need to keep beyond the vendor's retention.
8. Turn on writes one at a time, with an approval outside the chat. Decide who approves each write type and where that approval is recorded before you enable it.

Where does an ERP MCP server leave a finance-controls gap, and how does Loopfour close it?

MCP is a connection layer, not a control layer. It answers "can the model reach the ERP?" Finance controls answer "should this change post, who approved it, and can we prove it a year from now?" Auditors ask the second question.

An AI agent decides what to do at runtime. Loopfour does only what was approved.

Loopfour, the deterministic finance workflow automation platform, runs finance workflows on ERPs such as NetSuite and QuickBooks through its own integrations, with access scoped through OAuth. AI handles the parts that need interpretation (reading an invoice PDF, classifying a remittance). Everything that touches the ledger runs as fixed, programmatic steps. Loopfour is a managed service: we build the workflow, run it, and maintain it.

A typical flow: vendor invoice arrives → line items extracted → approval in Slack → bill posted to the ERP → run record kept. The model never holds a write-enabled ERP credential. The workflow does, and it runs only the steps that were approved.

Loopfour does not ship an MCP server today. Its workflows run on the ERPs and other systems listed on the integrations page now. Native MCP support for Loopfour workflows is coming soon.

Go deeper

For how MCP fits a full finance stack (hosts, clients, servers, MCP vs API vs iPaaS, and where approvals belong), read how financial workflow MCP connects AI to ERP and accounting systems with approvals and an audit trail.