ERP MCP Server: Let Staff Ask Your ERP and Internal APIs Questions

In many companies, simple questions about the business need three systems and a phone call. Is this item in stock at the second warehouse? Has customer order 4417 shipped? Can I raise a purchase request for more packaging? The answers exist in the ERP, the inventory system and an old order database, but only a few people know where to look.

The usual fix is another internal screen. That takes months, needs training, and soon becomes one more system to maintain. Meanwhile staff keep interrupting the same experts, and customers wait for answers that should take seconds.

What this does

MCP (Model Context Protocol) is an open standard introduced by Anthropic. It lets AI assistants such as Claude, and other clients that support it, connect to tools and data through small programs called MCP servers. Support varies by AI client, so check each client's current documentation before you plan a rollout.

An MCP server for internal systems gives staff one conversational way into the tools you already run. It exposes a small set of business tools, such as:

• Check stock for an item across warehouses.
• Get order status including shipping and payment state.
• Look up a supplier and their open purchase orders.
• Create a purchase request that goes into your normal approval chain.

Staff ask in plain language. The assistant calls the right tool and answers with live data. No new user interface is needed, and your existing systems remain the source of truth.

A day in the office

Take a customer service agent handling a call. The customer asks where their order is. The agent asks the assistant, which calls the order status tool and returns the shipping state and tracking reference. The customer then asks whether a replacement part is in stock nearby. One more question, one more tool call, and the agent has the answer by warehouse.

Later, a buyer notices packaging stock is low. She asks the assistant to raise a purchase request for the usual quantity from the usual supplier. The assistant fills in the request and shows a preview. She checks the quantity and approves it. The request then enters the ERP's normal approval chain.

Neither person opened the ERP, and neither needed training on a new screen. The systems behind them did not change at all.

How it works, step by step

1. Map the questions. We interview the people who get interrupted most and list what they are asked.
2. Find the access path. For each system, we choose the safest route: an official API, a read-only database view, or a small new API layer.
3. Wrap legacy systems. Where a system has no usable API, we build a thin service in front of it. It enforces limits and protects the old system from load.
4. Design narrow tools. Each tool does one thing with validated inputs, for example an item code and a warehouse.
5. Ship read-only first. Stock levels, order status and supplier details come first.
6. Add approved actions. Tools like "create purchase request" show a preview. The user approves before anything is submitted, and your ERP's own approval rules still apply.
7. Log and monitor. Every call is logged with user, inputs, outcome and timing.

Tools we use

• MCP SDKs in Python or TypeScript.
• Python with FastAPI for integration layers in front of legacy systems.
• Your ERP's and internal systems' existing APIs, using service accounts with the narrowest possible permissions.
• n8n when an action should trigger a wider workflow, such as notifying a buyer when a purchase request is approved.
• Event-driven patterns where systems need to stay in sync without hammering an API.

Integration options differ between ERP vendors and versions. Check your vendor's current documentation and offerings before choosing a route.

Integration work with strict rate limits is familiar ground for us. In our event-driven Canvas LMS integration, the system handled 50K+ daily API calls with zero rate-limit incidents in the first two terms. The same discipline applies to ERP APIs.

What you need to get started

• A list of the systems involved and who owns each one.
• API documentation, or database access, for each system. For legacy systems, someone who knows how they behave.
• The ten most common questions and the two or three actions that would save the most time.
• Your approval rules for any action, for example who can raise a purchase request and up to what limit.
• A test or staging environment, so actions can be tried without touching live data.

Typical scope and timeline

As an estimate, a first read-only version covering one or two systems typically takes one to three weeks. Systems with clean APIs sit at the lower end. Legacy systems that need a new integration layer take longer. Approved actions usually follow in a second phase, once the read-only tools are trusted.

Risks and how we handle them

Overloading fragile systems

Old systems may not cope with sudden traffic. The integration layer adds caching, rate limits and timeouts, so the assistant cannot overwhelm them.

Unapproved or wrong actions

Action tools are narrow, validated and gated by approval. They follow your existing business rules rather than bypassing them. Our article on AI agents with human approval explains the approval patterns in detail.

Permissions drift

A shared service account can see more than individual staff should. Where systems allow it, we pass the user's identity through. Where they do not, we enforce role checks in the MCP server itself.

Security exposure

An MCP server is a new entry point into core systems. We apply the controls in our MCP server security checklist and keep the server inside your network where possible.

When not to build this

If your ERP vendor already offers an official AI connector that covers your questions and permissions, start there. If the work is a fixed, high-volume process, such as entering every supplier invoice, a dedicated automation fits better than a conversation. See AI invoice processing automation. And if the system is about to be replaced, wait and integrate with the new one.

Weighing a custom build against an off-the-shelf tool? Our guide to AI automation: build vs buy walks through the trade-offs.

How UnlockLive can help

UnlockLive IT is a Toronto-headquartered software agency with its own engineering team. We build these integrations for companies in the US, Canada, the UK and Australia. Our MCP server development service covers scoping, the threat model, the build, deployment and ongoing maintenance. Where the work touches several systems and approval flows, our AI Workflow Automation team designs the workflows around the MCP tools.

If you want a second opinion on scope or risk, book a free 30-minute call. Bring one or two questions your team asks every week, and we will tell you honestly whether an MCP server is the right tool.