Business Central MCP and the integration layer

What MCP actually is

Without a protocol, connecting a model to Business Central means writing code that decides in advance which API call to make for which kind of question. That works and it is how most first integrations are built. It stops working when the list of things the assistant should handle grows, because every new capability means new branching logic.

MCP inverts this. Instead of code choosing the call, you publish a set of tools, each with a name, a description and a schema of its inputs. The model reads that catalogue and picks. Adding a capability becomes adding a tool definition rather than editing a decision tree.

MCP or direct API calls

Neither is the right answer in general. A read-only assistant answering a dozen known questions does not need MCP and will ship sooner without it. An agent that will keep gaining capabilities benefits from the structure almost immediately. We choose during architecture, and the honest version of that conversation includes saying when the simpler option is enough.

What a Business Central MCP server exposes

Not tables. Operations — and the difference matters. A tool called list overdue invoices that takes a threshold and a date accepts a narrow, validated input and returns a specific shape. A tool called run any query would be far more flexible and is precisely what you do not build, because it moves the security boundary from your code into the model's judgement.

• Read operations scoped to a purpose: customer balances, item availability, ledger entries for a period, document look-up.
• Write operations, each one built deliberately: create a sales order, update a contact, submit an approval request. Never a generic write.
• Descriptions the model relies on — a badly described tool gets called at the wrong moment, which is a correctness problem rather than a security one, but a real one.

What MCP does and does not change about security

It does not change the permission model. Calls still run under a Business Central identity with a permission set, and the platform still refuses anything outside it. What changes is reviewability: the set of things the AI may attempt becomes an explicit list that a security reviewer can read in one sitting, rather than behaviour distributed across an application's code.

Two risks arrive with the pattern and both are handled at design time rather than in the prompt. First, tool sprawl — every convenience tool added over time widens the surface, so the list needs periodic review like any other permission set. Second, over-broad tools: a single flexible tool is more useful to a developer and more dangerous in production than five narrow ones. We build narrow ones.

Connecting ChatGPT and other clients

A common question is whether ChatGPT or Claude can be pointed at Business Central. With an MCP server the mechanics are straightforward, since the same server can serve several clients. Whether you should is a separate question: routing company financial data through a consumer chat product is a decision for your data policy, and the answer usually involves an enterprise agreement with the model provider and a discussion about what leaves your tenant. We put those terms in writing in the architecture document before anything connects to production.

Limitations worth knowing

MCP is young, and the tooling around it moves faster than enterprise software normally does — worth checking the current state rather than relying on a page written months earlier, including this one. It adds a component to run and monitor. And it does not make a poorly structured Business Central easier to query: if your dimensions are inconsistent, a well-described tool returns well-structured wrong answers.