The connection between AI and your ERP
MCP is the open standard that lets an AI assistant use a real system instead of guessing about it. We build one for your ERP, so your team asks questions in plain English and gets answers out of live data. Scoped, logged, and read only until you say otherwise.
Works with Claude, ChatGPT, and Copilot. Runs in your infrastructure, on your accounts.
The gap
A chatbot that has never seen your order book cannot help you run your business.
A general assistant will happily answer a question about your backlog. It will make the answer up, because it has no way to look. Confident and wrong is worse than nothing on a shop floor.
Answers you cannot act on and cannot check
The workaround is exporting a spreadsheet and pasting it in. It works once. It does not scale, it goes stale immediately, and your data ends up somewhere nobody approved.
A demo, not a process, plus a data problem
Wire your ERP to one AI tool, then a second one ships and you build it again. Every connection is bespoke, every one needs maintaining, and none of them share anything.
N tools times M systems, built by hand
What we do
One connection, built once, that every assistant you use can speak to.
Your team asks the way they would ask a person. The assistant queries your ERP through the MCP server and answers from live records, with links back to what it read.
In practice
Someone types "which open jobs are past their promise date and already over quoted hours." The assistant runs the query, comes back with the actual job numbers, and shows where each one came from so anybody can check it.
MCP is a standard, not a vendor. Build the server once and Claude, ChatGPT, Copilot, and whatever ships next quarter can all use the same connection.
In practice
You are not betting the build on one AI vendor. If your team moves from one assistant to another, the ERP connection does not get rewritten. That is the entire point of a protocol.
The same server can expose your other systems too. Quality data, shipping, the spreadsheets that never made it into the ERP, your documents.
In practice
One assistant that can see the job in the ERP, the cert in the file share, and the shipment in the carrier portal, and answer a customer question that touches all three.
Reading is where everyone starts. When you trust it, the same server can take scoped actions: release a job, update a due date, post a transaction.
In practice
Writes go through your ERP's supported interface, so validation and audit trail run exactly as they would if a person keyed it. Each action is enabled deliberately, one at a time, never as a blanket permission.
Nobody's ERP is stock. The server is built against your fields, your customizations, and the way your company actually names things.
In practice
If your shop calls it a traveler and the ERP calls it a job routing, the assistant understands both. Generic connectors do not, which is why they demo well and fail in week two.
Every request the assistant makes is logged: who asked, what it read, what it returned. You can answer the security question before it gets asked.
In practice
When IT or a customer auditor asks what the AI can see, you show them the scope config and the log, not a shrug. This is usually what turns a maybe into a yes.
Not sure which of these matters most for your company? That is what the first call is for.
Under the hood
The interesting engineering is in the boundaries, not the protocol.
2 to 4 weeks
from first call to a working server your team can use
Read only
default posture, with writes enabled one tool at a time
1
connection to build, for every assistant you will ever use
Systems
We build this on any system we can read. These are the ones we work in most.
Questions
MCP stands for Model Context Protocol. It is an open standard, introduced by Anthropic in late 2024 and now supported broadly, for connecting AI assistants to real systems and data. Before MCP, every AI tool needed a custom integration with every system. MCP replaces that with one common way to describe what a system can do, so any assistant that speaks it can use any system that exposes it.
Any system with a usable interface, which in practice is nearly all of them. We have pages on Epicor Kinetic, SYSPRO, Global Shop Solutions, Made2Manage, and abas because those are systems we work in regularly. If your ERP exposes an API, OData, business objects, or even just a database we can read, an MCP server is buildable.
It is, when the connection is built properly, and that is most of what we are actually selling. Read only by default. Scoped to what each user is already allowed to see. Every request logged. Deployed in your infrastructure. The unsafe version is what happens without this: people pasting exports into a public chat window because they need an answer.
No, and that is the point of using a protocol instead of a product. The same server works with Claude, ChatGPT, Copilot, and whatever your team standardizes on later. If you switch assistants, the ERP connection does not get rebuilt.
It starts read only. When you are ready, we enable specific actions one at a time, and each write goes through your ERP's supported interface so validation, costing, and the audit trail all run. Most companies spend the first few months reading, and that alone is where the value shows up.
The server itself is small and cheap to host, since it is a connector rather than a model. Your ongoing cost is whatever your team already pays for their AI assistant, plus hosting that usually rounds to noise next to the ERP bill. We give you the real number before you commit.
It is complementary, and it is not locked to one vendor's roadmap. Vendor AI features work inside that vendor's product, on that vendor's schedule. An MCP server works across your ERP and everything running beside it, and it exists as soon as you build it rather than when it reaches your version.
Let's talk
Thirty minutes. You tell us what system you run and the questions people keep having to dig for. We tell you what an MCP server for it would look like, and what it would take.
Read next
Other things we build
AI for manufacturers
A guided way into AI for small and mid-sized manufacturers. We start with what is already costing you, prove it, then build from there at your pace.
Data foundations for AI
Getting your data into a shape AI can actually use. The unglamorous part that decides whether everything after it works.
AI chatbots for manufacturing
A chatbot grounded in your ERP data and your own documents, so it answers from your reality instead of the internet.
Manufacturing dashboards
Live dashboards built from your ERP and the spreadsheets beside it. One set of numbers, on a wall screen and a phone.
Everything we build