MCP for ERP: connecting AI agents to your ERP safely

Model Context Protocol has made it easy to plug an AI client into anything. That is the appeal and the risk. Connecting a model to a weather service costs you nothing when it goes wrong. MCP for ERP is a different proposition: every tool call reaches into the system that runs your invoicing, your inventory and your ledger, under someone's credentials, with a permission set that either constrains it or does not.

This post covers what the protocol gives you, what an ERP server has to add on top, and where the read/write line belongs.

Model Context Protocol (MCP)

An open protocol for connecting AI applications to external tools and data through a uniform client–server interface. A server declares what it can do; an AI client discovers those capabilities at runtime and calls them. It replaces one bespoke integration per AI product with one integration per system.

What MCP actually gives you

MCP is a plumbing standard. It defines how an AI client and a capability server talk, using structured JSON-RPC messages over either a local process pipe or HTTP. What a server exposes falls into a few kinds:

• Tools — callable functions the model can invoke, each with a name, a description and a schema for its inputs. get_ar_aging, search_customers, run_query. This is where almost all ERP value and almost all ERP risk lives.
• Resources — data the client can read as context rather than call as an action. A schema listing, a data dictionary export, a saved report definition.
• Prompts — reusable templates the server offers for common tasks, so the phrasing of a tricky request lives with the system that knows about it.

The important design property is discovery. The client asks the server what it can do, and the model chooses from the returned list. That means the tool list is the permission model as far as the model is concerned. Anything you expose, expect to be called, in combinations you did not plan.

Why an ERP MCP server is not a weather MCP server

The protocol is the same. The consequences are not remotely comparable, and every design decision follows from that.

Read tools: the boring ones that matter

Most of the value is read-only, and read-only is where you should start and probably stay for months. Read tools still need design work, because a read tool that returns a confident wrong number does real damage.

• Expose schema discovery as its own tool. A model that can ask what record types and fields exist stops guessing at them. This is the single highest-value read tool on an ERP server, and the least glamorous.
• Return the query alongside the result. Whatever the tool ran — SuiteQL, a saved search, a REST call — hand it back with the rows. The client can then show its work, and a human can check the filter. Run the returned SQL through the SuiteQL formatter if you want it readable before you paste it into a ticket.
• Cap rows and page explicitly. A default limit, a maximum limit the caller cannot exceed, and a cursor. Without this, one broad question pulls the whole transaction table into a context window and into a log file.
• Project, don't dump. Return the columns asked for. Every extra field is data crossing a boundary for no reason, and it degrades the model's attention as well as your data posture.
• Make results structured and stable. Consistent shapes, typed numbers, currency and period stated explicitly. If the output has to reach a spreadsheet, a JSON to CSV conversion should be trivial rather than a parsing exercise.
• Enforce timeouts. ERPs have governance limits of their own. A tool that hangs is a tool an agent will retry, three times, in a loop.

Write tools: preview, confirm, audit, undo

Write tools are where ERP MCP servers earn their reputation, in either direction. The problem is not that models write badly. The problem is that an agent loop generates many actions per human decision, and the human's attention does not scale with the loop. So the guardrails have to live in the server, not in the operator's vigilance. Which jobs are safe to hand an agent at all is a separate question — AI agents for finance teams works through the ones worth automating and the ones that need a human on every decision.

1. 1.Preview. A write tool's first job is to return exactly what would change: which records, which fields, old value and new value, and how many rows. No mutation yet. This makes the diff reviewable by someone who was not watching the conversation.
2. 2.Confirm. The mutation is a second, separate call that carries a token from the preview. If the underlying data changed between the two, the token is invalid and the write fails rather than applying to a different world than the one previewed.
3. 3.Audit. One entry per attempt, not per success: caller identity, tool, inputs, the preview, the outcome, timestamp. Failed and refused attempts are the interesting ones during an incident.
4. 4.Undo. Store the prior values so a single action reverses the change. Undo is not always possible — a posted period or a transmitted payment is not reversible — and a write tool that cannot offer undo should say so in its own description and require stronger authorisation.

Scoping, permissions and limits

Governance starts below the protocol. The ERP's own permission model is the real boundary, and the MCP server should be strictly inside it.

If you are being sold an ERP MCP integration, these are the questions to ask, and the AI and ERP security checklist turns them into something you can send to a vendor in an email.

Where MCP for ERP fits, and where it doesn't

MCP solves connection. It does not solve correctness. A perfectly implemented server, exposing a run_query tool over your live account, still lets a model write a query filtering on a status value your account has never contained. The protocol has no opinion about whether the answer is right, and no way to form one.

That is a separate layer: grounding queries in your account's real schema, validating them before execution, and refusing outside what the dictionary supports. What grounded ERP AI means describes that layer, and why AI hallucinates on ERP data explains what happens without it. Treat MCP as the wiring and grounding as the reason the wiring is worth having.

How ERPray handles it

ERPray connects read-only by default, through a least-privilege integration role you create and control. Every answer carries the exact SuiteQL that produced it, and every query and change is recorded in a governance console your admins can inspect. Write access is off until you enable it, per record type and per field, and each write follows the same path: preview of what will change, your explicit confirmation, an audit entry, and one-click undo. MCP and API access are available on the Pro plan, so your own agents and clients can call the same grounded layer rather than a raw query endpoint.

Each customer runs a dedicated instance, self-hosted on your own cloud or hardware or hosted for you, and no data is retained by default. If external processing is the blocker, a fully self-hosted instance with local models makes zero external calls.