What the Heck Is an MCP, and Does My ERP Need One?

---

title: "What the Heck Is an MCP, and Does My ERP Need One?" description: "MCP lets your AI assistant work inside your ERP under the same roles as your staff. What that means, and what to ask a vendor first."

If you run a company, you have probably heard "MCP" recently, from a software vendor or from your own artificial intelligence (AI) assistant. I build custom ERP systems (enterprise resource planning, the software that runs a company's orders, jobs, billing and scheduling), and I build the MCP servers that connect them to AI. I sell custom software, so I have an interest in the build-or-buy question, and I will say so where it applies. This is how I explain MCP to a client across the table.

What is an MCP in plain English?

MCP stands for Model Context Protocol. It is an interface for the AI to do what your employees do on your system.

Your users have roles, and there are tasks they can accomplish. There is an underlying data model, but they don't touch it directly. They work through specific screens, and the system guides what each user should or shouldn't be doing. An MCP is the same thing for an AI. Instead of going through web pages and clicking on buttons, it has its own language for talking to the system, and it performs the same tasks. Most vendors are adding a chatbot to their product, a feature you talk to inside their screens. MCP goes the other direction. Your business software becomes a tool that the assistant you already use can operate.

Treat the AI as an employee with a role. It really isn't much more complicated than that. Where people make it complicated is when roles aren't clearly defined and things get done "with an understanding." In a system designed with roles and permissions, the AI's ability to wreak havoc is limited by its role. You give it no more permission than you would give an employee with the same level of trust.

What could my AI do with my ERP?

There are two levels. The first is asking questions across your data. The second is making changes.

Level one is the ad hoc query, blurted out in English. The one I like best comes from a manufacturer: "What are all the parts we make with a similar workflow to this one, and what is the average production time?" The workflows are real, discrete data. "Similar" is a judgment. The AI runs a query, gets a number of results, and pares them down to the similar ones. Production time varies on a number of factors, so it then makes a second set of judgments to weigh them. They do this by hand today, for quoting and for reviewing whether a job made or lost money, and it takes at least thirty minutes a day. We are about to build the assistant version. I expect the gain to be accuracy more than time, because they will do more of it.

Level two is allowing the AI to make changes. That usually comes after we have already automated the routine work. It is a different mode of communication for setting something in motion: a voice agent speaking to a customer on the phone, or an external system that makes a decision and triggers a workflow.

Why not just connect the AI to my email and spreadsheets?

Because the AI would skip everything your system does around the action.

At a case management firm, when a case manager sends an email from inside their system, a secure delivery option strips the documents out and delivers them through a secure method. There is an option to send it as a fax, which clearly doesn't work from Outlook. The system generates a note on the case, because it knows which case the email belongs to. Connect an AI directly to Outlook and it skips all of these things. In this one example there is a lot you would have to reteach an AI, and then hope it keeps lockstep with the system. An MCP exposes these actions the way you work. That requires discipline in system design.

The same problem shows up with data. When something doesn't fit in the ERP, people find a special place to put it outside the system. A spreadsheet or a misused notes field doesn't enforce permissions. Either the AI doesn't get that data, or you have to tell it after the fact what its permissions are. I have seen real directory structures in healthcare where the folders held some of the most commonly searched items and the names included no numerical identifiers. An AI trying to make sense of that is the new employee who doesn't know what they're doing. They save things in the wrong folder under the wrong name, they clean things up, and people can't find anything.

What have you actually built?

AI functions that run inside client systems, and two MCP servers on our own platform.

The most used one works on case notes. A miniature app on the case manager's phone captures a voice recording right at that moment, wherever they are, and hands it to the AI. The system determines what type of note it is and which template applies, and always grabs specific case data so there is no ambiguity. Once the note is complete, it extracts billing data and any changes to case information it discovered in the note. That one little thing automates a few different jobs.

We also run two MCP servers against our platform. One is for building the system itself, the forms and pages, and we maintain parity with the tools our own developers use. The second gives access to the business actions. Both are part of the lease version of our platform, now in closed beta. These are real requests that did real work:

"Can you reorganize the customer page? It is set up on a grid pattern. I would like it to be organized by topic and fields sized appropriately."

"Can you build a dashboard that shows for each team the number of project hours. Make them pie charts proportionate to project hours and divided by employee, type and customer, selectable."

For us, building an MCP is honestly not much more than a few lines of code, because the interface underneath already enforces roles and permissions.

Is this safe?

It is as safe as the roles and approvals in the system behind it. My advice for most owners today is to start with read access only.

Nothing from AI goes straight into any of our systems. What the AI produces are suggestions: suggested billing records, suggested changes to a case. Somebody goes clickety-click and approves them, and each one has to be chosen. They show up in the form of a form, so they can be modified. In some sense it is an autocomplete, because what the person is looking at is just as if they had typed it in themselves.

Our worry is the same as with any system that works almost perfectly: people will trust it too much. People change the suggestions more often than you would think, and not so much because the AI is making mistakes. Once somebody sees their work in print, upon reflection they have changes. The same applies to anything customer-facing. If an agent is placing orders on behalf of customers and there is any risk of error, maybe you are not placing orders. You are placing requests, a human being approves them, and you tell your customers that is what you are doing.

Never connect data to an MCP if you don't understand that data. People misuse fields when the system doesn't provide what they need, and when the need gets solved later, the old data never gets removed. On more than one occasion we have found data that somebody wouldn't want to share sitting in an innocuous, safe-looking notes field, years after the habit stopped. It was embarrassing rather than compromising, but it was unexpected, and a security policy can't contain the word unexpected. There needs to be a control. It can't be "this is where we connect your data, and after that the AI has everything."

If you are asking yourself whether your MCP should read or write, it should probably just read. Even that carries risk. When you connect two systems, one of them saying it is read-only doesn't mean it won't try to get into the other. If that sounds funny, you haven't read the recent news. You will be intimately familiar with your system and your processes before the answer to write access is yes.

What should I ask a vendor who says they've added MCP?

Ask what you would ask about an employee with a role: what can it do, what is the safety level, can I audit it, and can I back it out. The last one matters most. If an action changes so many things that unraveling it becomes difficult, and you are not sure about the execution, you probably don't want to use it. This is a risk and reward decision. Know why you are connecting the two systems, and weigh the benefit against the possible harm. Ask the same questions when you are shopping for a system. "Does it have a rational MCP" belongs on the list.

A vendor's MCP is also a great covert analysis tool for how their system works. A well thought out MCP is probably working against a well thought out system. If the MCP almost can do things that you really can do in the product, that asymmetry probably indicates a number of systems behind it that are some mess. If it has a very limited set of functions, no roadmap and a lot of hand waving, ask why.

Here is a real gap. As of September 2026, the public MCP server for a major accounting package can create, read, update and search invoices, but it cannot email one to the customer. There is an open request for it in the project's issue tracker. We implemented this exact pattern for a client: the invoice goes to the accounting package, but delivery to the customer or the insurance carrier happens in the client's own system, because delivery is part of their workflow.

This is where I have an interest, so here is the other side. The MCP that comes with a packaged product is fine if you can verify the outcome of everything you do with it, and, if you give it write access, if you have established the controls and trust to protect yourself.

Vocabulary matters too. At a healthcare case management company, a "file" is a case. At an IT firm, a file is a thing on a disk. Anyone building up their own AI prompts should keep a glossary document and keep it up to date.

What doesn't work yet, and what does it cost?

Simple actions work today, complicated writes are not ready, and the cost depends on the system underneath.

We are building a voice agent for scheduling, and we started there because it has a very simple interface. Getting to the easy stuff is very easy, and getting to something good is minutes of work. Getting to something great always takes extra time. Taking notes and putting a date on the schedule are easily within reach. Voice agents that write more complicated data either wait or use an integrated product.

On cost, MCP is built into our platform. Building it onto somebody else's system is like saying "I need an interface between two different systems." That doesn't say much, and it is hard to guess at cost or feasibility until someone has looked at what is there.

Where is this going?

I won't give you a five-year prediction. It is easy to predict when things are speeding up, the way chips kept getting faster. A phase transition like this one is hard to predict. We are still solving old problems with new tools, and we need new systems to go with the new tools. That is going to take a generation to work through. "I'll wait" might work for you. Whoever pays attention to this problem in the next few years is going to get ahead because of it.

How does this connect to Service as Software?

AI didn't remove the problem of running a business on software. It changed the shape of it. The AI can do a whole bunch of things, but you don't want to spend your entire day understanding all of the questions, the data pieces and the vernacular, and you can't tell it "give me the best outcome." You still need somebody to make those choices. What they have now is a much better set of tools.

That is the argument in SaaS is Dead. Long Live SaS: Why Service as Software is the Future: when building gets cheap, you stop renting software as a service (SaaS) that sort of fits and have software built around how your business works. An ERP your AI can operate, under your roles and in your vocabulary, is the next step of that.