Anyone who has tried ChatGPT, Claude or Microsoft Copilot knows the limit: the assistant writes well, but it does not know which orders are open in your ERP, which customer has had a reminder or where an item is stored. You copy data in, get an answer and copy it back out. That is retyping with a clever step in the middle.
To be genuinely useful in a business, an assistant has to be allowed to ask the business’s programs. A standard has emerged for that: the Model Context Protocol, MCP for short. An MCP Server is the piece of software that makes a program - your ERP, your inventory system, your ticketing tool - addressable for assistants.
What an MCP Server is, in plain words
Imagine an employee sitting next to the assistant with access to the ERP. The assistant says: “I need every overdue order that has not been delivered yet.” The employee looks them up and hands them back. The assistant summarises and answers.
That is exactly what an MCP Server does, only as a program. It offers the assistant a list of things it can do - “search orders”, “show customer”, “create delivery note” - each with a description in plain language. The assistant decides which of them it needs for the question, calls them and gets the data.
How it differs from an interface
A classic interface connects two programs according to fixed rules: every shop order becomes an ERP order, always the same way. An MCP Server is also an interface, but on the other side sits not a program with fixed rules but an assistant that decides, question by question, what to query.
| Interface between programs | MCP Server | |
|---|---|---|
| Who asks | a program, following a fixed routine | an AI assistant, depending on the employee’s question |
| When | continuously or at set times | whenever someone wants to know or do something |
| What | always the same data | whatever the assistant needs for the answer |
| Who checks | the rules of the interface | the permissions of the employee who is asking |
| Example | shop order becomes sales order | “Which orders are overdue?” |
The two complement each other: the fixed interface makes sure the data is there, the MCP Server lets you ask about it in ordinary language.
What an MCP Server can do for an ERP
Examples from everyday business:
- Answer questions: “Which orders are overdue?”, “What did we last deliver to Müller?”, “Which items are below minimum stock?”
- Summarise: “Summarise the correspondence on this complaint.”
- Prepare: draft a quote from a customer enquiry in the mailbox, for a person to check and approve.
- Trigger: create a delivery note, enter an appointment, hand a task to the field team - each so that the employee confirms before anything happens.
Reading is the easy part. As soon as the assistant creates or changes something, a confirmation belongs in between.
Why permissions have to be checked
The most important point about an MCP Server is not the AI but the permission check. The assistant asks on behalf of an employee. So it may only see what that employee may see: the salesperson their customers, not the payroll; the warehouse worker the stock, not the margins. The MCP Server therefore has to know who is asking and enforce the ERP’s permissions - not its own, more generous ones.
An MCP Server that reaches the ERP through a shared service account undermines every permission structure: then anyone using the assistant can ask anything. Raise it before the first assistant gets access, and involve your data protection officer: which data the assistant sees and where the model runs need checking.
Which assistants support MCP
MCP came from Anthropic, the maker of Claude, and is now an open standard. Claude, ChatGPT and Microsoft Copilot now support MCP Servers. Local models can be used too: if you run your model in-house through Ollama, you can connect it to an assistant interface that understands MCP. That is the advantage of the standard: the MCP Server for your ERP is built once and works with today’s assistant and tomorrow’s. Where the model should run when it sees your data is covered in Running AI in-house.
Where the limits lie
- The assistant is only as good as the data. If the master data is messy, it summarises mess.
- It answers with probability, not certainty. Figures from the ERP come back exactly; the interpretation comes from the model and can be off.
- Every function the server offers has to be built and described. There is no MCP Server for “everything in the ERP”; it grows with the questions actually asked.
- The model runs somewhere. With a provider in the US, its computers see the data the assistant queries; whether that is acceptable needs checking.
What this means for your software
Programs that come with an MCP Server can be queried straight away. Many ERP systems lack one yet; then it is added, where possible through the interfaces the ERP offers anyway. ElbDesk, the foundation we build on, comes with an MCP Server: an application built on it can be queried by AI assistants, and the application’s permissions apply to the assistant too. If you have an ERP, it stays - accounts and warehouse stay out of it.
Questions before you decide
- Which questions do your staff ask today that mean looking in several programs?
- Who may see which data, and is that properly set up in the system?
- Where should the model run: with a provider or in-house?
- Should the assistant only read, or also be allowed to create things?
Our AI Consulting begins with these questions too - with the workflow, not with the model.
