Connecting an AI Assistant to an ERP with MCP — Read-Only by Design
The Model Context Protocol (MCP) is an open standard for letting AI assistants call real tools and data through a well-defined interface. As a learning exercise, the DP Sound Systems demo ERP — the same sales orders, inventory, MRP, and VERIDEX data from the ERP tutorial series — was wrapped as a small set of MCP tools. This post is about the design: what to expose, what never to expose, and how to let an AI act without letting it act unchecked.
The core idea
Instead of an AI guessing at your data, MCP lets it call named tools with clear inputs and outputs. The demo exposes seven, split by intent — five that only read, and two that handle a single, carefully guarded write path.
| Tool | Answers questions like |
|---|---|
| get_sales_orders | "Show open orders for a customer" |
| get_order_details | "What's on this order?" |
| check_inventory | "Do we have enough of this item?" |
| mrp_shortage_check | "What should we buy, and how much?" |
| veridex_score | "Is this order safe to release — and why?" |
| propose_purchase_order | "Queue a purchase order" — pending human approval |
| get_purchase_proposals | "What's waiting for approval?" |
Design rule: the AI proposes, a human disposes
The single most important decision was that the assistant can look at everything and change nothing on its own. Read access is read-only, enforced at the data layer — not merely by asking the model nicely. The one write path, proposing a purchase order, does not create anything real: it places a request in a separate queue that a person must approve through a channel the AI cannot reach. Approvals happen out-of-band, by a human, every time.
This matters because prompt instructions are not a security boundary. An AI told "don't modify data" can still be steered into trying. Enforcing read-only at the database and routing every write through human approval means the guarantee holds regardless of what the model is convinced to attempt.
Responses that carry their reasoning
MCP is only useful if the assistant can reason over what comes back, so the tools return structured results with the "why" attached. A shortage check does not just list items — it returns availability, open demand, and a suggested buy quantity, worst item first. A release-risk score does not just say HOLD — it returns the factors behind the number.
For example, a VERIDEX score weighs stock coverage, customer credit headroom, and due-date pressure. When an order scores low, the response includes each factor and its weight, so the assistant can explain that the block is driven by, say, thin credit headroom against a large order — not simply announce a verdict. The reasoning travels with the data.
Validation is part of the contract
Every tool validates its inputs before doing anything. A proposal for an item that does not exist is refused. A proposal for zero or an absurd quantity is refused. These refusals are first-class outcomes — the tool returns a clear message rather than failing silently or, worse, acting on bad input. In a system where an AI is the caller, defensive validation is not optional; the caller will eventually send something unexpected.
Everything is logged
Every tool call and every human approval decision is recorded to an audit trail. That trail captures attempts, not just successes — including inputs that validation rejected. For a system that blends automated calls with human decisions, a single ordered record of "what was asked and what a person decided" is what makes the whole thing reviewable after the fact.
Security posture, in principle
Exposing internal data to any networked caller — human or AI — raises the stakes, so the demo follows a few principles rather than shortcuts:
- Least privilege. The service runs with the minimum access it needs and no more. Read paths cannot write; the write path cannot execute approvals.
- Defence in depth. Network isolation, transport encryption, authentication, and rate limiting each stand on their own, so no single failure opens the door.
- Assume hostile input. Inputs are validated and parameterised; a classic injection attempt returns nothing useful and leaves the data untouched.
- Automated verification. A test suite exercises the tools, the reasoning, and the security properties, and must pass before any deployment.
What this demonstrates
The interesting lesson is not that an AI can read an ERP — it is how to let it do so responsibly. Read-only by default, human-in-the-loop for anything that changes state, structured responses that explain themselves, validation on every input, and a complete audit trail. Those principles apply far beyond this demo; they are what separates a genuinely useful AI integration from a risky one.
*This is a learning demonstration on fictional data, built on the open MCP standard. It is not a production system and not professional advice — verify before relying on any output.*
Comments (0)