MCP Explained: The Missing Link Between AI and Your ERP

If you run a distribution or manufacturing business, you have probably heard “MCP” in vendor pitches this year without anyone explaining it in business terms. The Model Context Protocol is an open standard that lets an AI assistant ask your business systems questions through a defined, permission-controlled connection. Getting an AI to write well is the easy part. Getting it to read your ERP correctly, with the right customer price and the right branch inventory, is the hard part, and that is the part MCP standardizes. This article explains what MCP is, how it differs from the APIs you already have, what makes it safe or unsafe, and three questions to put to any vendor who pitches it.

What is the Model Context Protocol?

The Model Context Protocol (MCP) is an open standard that defines how AI applications discover and use tools and data from other systems. A system that wants to be usable by AI runs an MCP server. The server publishes a list of what an AI may ask for, what each request needs, and what comes back. Any AI application that supports MCP can then use that list.

Think of an MCP server as the order counter at a warehouse. The counter posts what you can request, such as stock by SKU, order status, or a customer’s price. The clerk checks who is asking before handing anything over. Nobody walks into the stockroom. The ERP stays where it is, and the AI only gets what the counter is allowed to give.

Anthropic introduced MCP in late 2024. In December 2025 it donated MCP to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. No single AI vendor controls it. The latest stable revision of the specification is dated July 28, 2026.

For a developer-level walkthrough, see our earlier piece on MCP as a modern language for LLMs.

Why ERP access is the hard part

AI models are increasingly interchangeable. Your ERP data and the business rules inside it are what make an answer correct.

Take a call an inside sales rep at a distributor might get on a Tuesday morning: “Are these two fitting SKUs in stock, and what’s my price?” Answering it correctly takes five lookups:

1. The customer account and its credit status.
2. Product details for both SKUs.
3. Live stock at every branch.
4. The contract price for that account, not the list price.
5. Recent orders, to spot a related item worth offering.

Each answer lives in a different part of the ERP, and each comes with its own permissions. A general-purpose AI without access will produce a confident, wrong answer. A custom integration built for this one question works, but you would need another one for the next question, and another for every AI tool your team tries.

MCP changes the economics. You define those lookups once, as tools on an MCP server, with access rules that decide which roles can call each tool and see each field. Any AI application your company approves that supports MCP can then call them.

MCP vs API: what actually changes

MCP does not replace your APIs. An MCP server usually sits on top of the APIs or integration layer you already have and describes them in a form an AI can use without custom code.

For an executive, the useful difference is the last two rows. With MCP you build access once and decide centrally what the AI can see for each role. Switching AI vendors no longer means rebuilding the integration from scratch.

Is MCP secure?

MCP is as secure as the server that implements it. The protocol carries the request, and the server decides what to return. That puts the important controls on your side of the line.

A well-built MCP server for an ERP should do four things:

• Start read-only. The AI can look things up but cannot create orders, change prices, or edit records until you decide otherwise.
• Scope access by role. Each role sees only the tools and data fields it needs; a customer support rep’s AI, for example, never sees costs or margins. If those roles live in a separate layer rather than in the ERP, keep the two aligned.
• Log every request. Each answer should trace back to the user or connected client that asked, which tool ran, and which records it touched. Sirius, for example, logs every AI request with the connected client, its role, the time, and the result.
• Expose business actions, not raw tables. “Get contract price for account and SKU” is safer and more accurate than open database access.

The risks to watch are on the edges: an AI vendor’s data retention terms, a server that grants broader access than the user has, and write actions added before anyone has defined who approves them. Connect only to MCP servers you trust, too. Anthropic warns in its connector guidance that a malicious server can carry hidden instructions that try to make the AI take actions you didn’t intend. Also check how each connection signs in: Anthropic notes that a connector set up with one shared credential, such as an API key, gives everyone who uses it that credential’s access, not their own.

What “bring your own AI” means for your business

Bring your own AI means your ERP data stays put and your team uses whichever AI assistant the company already pays for. MCP makes that practical, because the same server works across AI applications that support the standard.

Major AI applications already support it. By December 2025, ChatGPT, Gemini, Microsoft Copilot, Cursor, and Visual Studio Code had all adopted MCP, according to Anthropic. Claude supports custom MCP connectors on every plan (free users get one), with Team and Enterprise owners deciding which ones members can use. OpenAI lets ChatGPT Business and Enterprise workspaces connect custom MCP servers, with admins controlling which ones staff can use, and lets individual Pro users connect them with read-only access. Commerce vendors are adopting it too: Adobe uses a Commerce Developer MCP in its migration tooling for Adobe Commerce as a Cloud Service.

This is the approach behind Sirius MCP. Sirius is the integration layer Atwix built to connect ERPs to Adobe Commerce stores. Its MCP layer, now in early access, lets an AI assistant query Infor CloudSuite Distribution through the same governed bridge. It is read-only, and its own role model (admin, sales rep, finance manager, warehouse operations, and customer support) decides which tools and data fields each connected AI client can use. We showed it live at TUG CONNECTS 2026, and the session recap walks through three real workflows, from order investigation to live branch inventory on a phone call.

Where MCP is still immature

MCP is still maturing in three places: the specification keeps changing, AI applications support it unevenly, and write actions carry most of the production risk. The specification has gone through several dated revisions since late 2024, and the July 2026 revision changed how clients and servers start a connection. Servers and AI applications adopt new revisions at different speeds, so a server built today needs maintenance.

Client support also varies. Custom MCP connections in ChatGPT, for example, sit behind workspace and plan settings that an admin controls. Location matters too: Claude reaches remote MCP servers from Anthropic’s cloud, not from your office, so a server that runs inside your network has to be reachable from the internet or opened to Anthropic’s IP addresses. For an on-premises ERP, that is a real infrastructure step. Write actions, such as creating an order or changing a quote, are where most production risk sits, and few distributors should enable them in a first rollout.

The practical response is to start with read-only questions that save real time, measure the result, and expand from there.

Three questions to ask any vendor pitching MCP

When an ERP vendor, integrator, or AI startup pitches MCP, these three questions separate a demo from a production system.

1. What can the AI see, and who decides? Ask how access is scoped by role, down to individual data fields, and how those roles stay aligned with the permissions you already set in the ERP.
2. Can it write, and who approves a write? A good answer starts with “read-only by default” and names the approval step for anything beyond that.
3. Can we trace an answer back to the records it came from? If the vendor can’t show a log of which user or connected client asked, what ran, and what came back, you can’t audit it and you can’t trust it at month end.