MCP for an ERP: An Open Standard That Keeps the Model Choice With You
MCP, the Model Context Protocol, is an open standard for connecting AI applications to the systems that hold data. When an ERP exposes an MCP server, any AI client that follows the standard can use it. The part that matters for a group, which data the agent may read, what it may write and under whose name, is configured once on the ERP side and survives a change of model. That is how you keep the model choice with you.
We run this on our own Business Central, with an AI client that is not Microsoft’s, for internal checks such as time sheets. What follows is what turned out to be portable between clients, and what did not.
What is MCP, in plain terms?
A common plug between AI applications and business systems. The system side runs an MCP server that describes what it offers as tools: list these records, create that one, run this action. The AI side, the client, discovers those tools and calls them.
Two facts matter for an architect. The specification is public and versioned: Microsoft’s Business Central documentation points to the version dated 2025-11-25. And since December 2025, MCP has been governed under the Agentic AI Foundation, a fund of the Linux Foundation. No single AI vendor owns the plug your ERP exposes.
What does an ERP like Business Central expose over MCP?
Its API pages, as tools. Business Central has one MCP endpoint shared by all tenants, and an MCP configuration decides which API pages are exposed and which operations each one allows. By default the access is read-only; writing has to be turned on in a configuration.
Microsoft lists the clients it supports: Visual Studio Code with GitHub Copilot, Copilot Studio, and other clients that follow the MCP specification. Copilot is one option in that list, not the only one. The setup details, and the rules we apply before letting an agent write, are in our article on AI agents inside Business Central over MCP.
Why does MCP keep the model choice with you?
Because almost everything you build sits on the ERP side, and none of it mentions a model.
Look at what an AI project on an ERP actually produces: a list of exposed API pages, a read-only configuration for questions, a separate configuration for writes, a holding area where the agent drops its proposals, an action that commits them, permissions on that action, named users. Every one of those lives in Business Central. Swap the AI client and they stay exactly where they are.
On our tenant, the part tied to the AI client was the sign-in. Business Central uses Microsoft Entra ID for authentication, and a client that is not Microsoft’s needs its own app registration. Microsoft’s documentation states that the same app registration can serve different clients. Changing the model means changing a client configuration, not rebuilding the ERP side.
What does not travel between AI clients?
Client behaviour. The standard is shared, the implementations are not, and each difference shows up as a day of debugging if nobody expected it.
- Sign-in. The MCP specification allows clients to register themselves automatically with the authorization server. Microsoft Entra ID does not support that, so you register an app by hand. A client that tries automatic registration by default fails with an error that retrying will never fix. We hit it.
- Tool limits. Some clients cap the number of tools an agent can hold. Microsoft cites Copilot Studio’s 70-tool limit as a reason to use Dynamic Tool Mode, where the agent searches for the action it needs instead of loading every tool.
- How the company is chosen. Business Central can pin the company with a connection header, or, for clients that support it, take the company as a parameter on each call. Which mode you get depends on the client. That matters before any write: the agent has to confirm which company it is in.
- Action arguments. On our configuration, bound actions went through only without input parameters, and we built a workaround. Another client may behave differently. Test it on yours.
The rule we draw from it: the ERP side is portable, the client side needs a test per client. Keep a short test script, run it against each new client, and only then let that client near production data.
What should an architect decide before picking a model?
The things that do not depend on the model. In our experience, these are the decisions that make the model swappable later:
- Which API pages are exposed, per use case. A configuration for questions, another for writes. Never one configuration that does everything.
- Where writes land. A holding area and a deliberate action to commit, so the model never writes straight into business data.
- Who the agent runs as. Every operation runs under the signed-in user’s identity and permissions. No shared AI account.
- What you can observe. From version 28.0, Business Central telemetry records each MCP tool call with the user, the tool, the configuration and the client that made the call. That makes two models running side by side measurable, not anecdotal.
With those four in place, the choice of model becomes what it should be: a decision per task, revisited when a better option appears. How the write path and the approvals hold up in front of an auditor is covered in our article on AI governance in finance.
Is an open standard enough to make it safe?
No. MCP standardises the connection. It does not decide what an agent should be allowed to do. A badly scoped configuration is just as badly scoped over an open standard.
Safety stays where it always was, in the ERP: exposed pages, read-only by default, write paths built on purpose, named users. MCP makes that work reusable across models. It does not replace it.
The Asio Services way
We design the ERP side first and treat the model as a replaceable part. Read-only configurations for questions, separate write paths with a holding area, named users, telemetry switched on, and a test script for every new client before it touches real data. That is how we approach AI for multi-entity groups: Copilot when it fits, another model when it fits better, the same ERP underneath.
If you are about to choose an AI vendor for your ERP and want to keep the option to change your mind, start with a clarity session.
FAQ
What is MCP in an ERP context?
An open standard that lets AI clients discover and call what an ERP exposes, such as reading records or running actions. The ERP runs an MCP server; any compliant client can connect to it, within the permissions of the signed-in user.
Does MCP lock us into one AI vendor?
No. The specification is public, and since December 2025 it is governed under the Linux Foundation’s Agentic AI Foundation. On Business Central, Microsoft supports its own clients and other clients that follow the specification.
Can we switch AI models without rebuilding the ERP integration?
Mostly yes. The exposed pages, write paths, permissions and users live in the ERP and stay in place. What changes is the client configuration, the sign-in setup and client-specific behaviour, which you should test before production.
Is MCP read-only by default on Business Central?
Yes. Microsoft’s documentation states that the default configuration gives agents read-only access. Creating, modifying, deleting and running actions must be allowed explicitly in an MCP configuration.