Short answer: an MCP server for Business Central is a layer that publishes a list of described operations — "list overdue invoices", "create a purchase order" — authenticates against Business Central and executes only what is on the list. The model chooses from a catalogue; it does not reach the database.
What MCP is, plainly
Model Context Protocol is a convention for telling an AI model which tools are available to it. Nothing more.
Without a protocol, connecting a model to Business Central means writing code that decides in advance which API call corresponds to which kind of question. That works, and it is how most first integrations are built. It stops working when the list of things the system should handle grows: every new capability becomes a new branch, and after a year nobody can say what the system can do.
MCP inverts this. You publish a set of tools, each with a name, a description and a parameter schema. The model reads the catalogue and picks. Adding a capability means adding a tool definition rather than editing a decision tree.
The main practical consequence is not developer convenience. It is that the list of what is permitted becomes a document — one a security reviewer can read in a sitting. In a hard-coded integration that information is spread across files.
How an MCP server works
It is a separate application sitting between the model and Business Central, with four responsibilities:
- Publishing the tool catalogue. Answering "what can you do" with a list of operations and parameter schemas.
- Validating parameters. A sum beyond a sane range or a date in the future gets rejected before Business Central is called.
- Authenticating. It holds the credentials and calls Business Central under a specific identity. The model never sees those credentials.
- Returning results in a predictable shape — including an explicit "no data" that cannot be confused with an error.
The server is usually deployed in your own Azure environment or at your implementation partner. That choice determines where credentials and logs end up, so it is a data-policy decision more than a technical one.
What it exposes to the model
Not tables. Operations — and the difference is fundamental.
| Type | Example | Parameters |
|---|---|---|
| Purpose-scoped read | Overdue receivables | Amount, days, company |
| Record look-up | Find customer | Name or code |
| Point-in-time state | Item availability | Item, location |
| Create | Draft purchase order | Vendor, lines |
| Targeted update | Last contact date | Customer, date |
| Start a process | Submit for approval | Document |
Note the last two rows: write operations are deliberately narrow. Not "update the customer card" but "update the last contact date". The difference is that the first allows changing a credit limit and the second does not — and that constraint lives in code, not in hope that the model behaves.
Tool descriptions are separate work that gets underestimated. The model chooses a tool by its description, so a poorly worded one gets called at the wrong moment. That is a correctness problem rather than a security one, but a real one, and a noticeable share of debugging goes into it.
What a badly designed server looks like
Three signs, useful if you are evaluating somebody else's work.
A universal tool. An operation like "run query" or "get data from table X" with arbitrary filters. More convenient for the developer, and it moves the security boundary out of your code and into the model's judgement. A sign the designer was saving time.
Operations that return too much. A tool that hands over a whole table and leaves the model to filter. Two consequences: more data leaves your environment than needed, and the agent hits Business Central's request throttling.
No explicit "no data" response. If an empty result and an error look the same, the model tends to fill the gap with a plausible number. In a financial context that is the most dangerous behaviour available.
When MCP is justified
Not always — and an honest answer here saves budget.
Not needed if you have a narrow read-only assistant covering a dozen known questions that will not grow. Direct API calls are cheaper, simpler and ship sooner.
Needed if you are building agents that must choose among many operations; if the capability list will keep growing; if several clients need to reach the same data; or if a security function has to review what is permitted on a regular basis.
A practical rule: if you can list every future capability on one sheet and are confident the list will not change, MCP is overhead. If you cannot, it pays for itself around the third or fourth capability.
Three risks
- Catalogue sprawl. Every convenience tool added over a year widens the surface. The list needs periodic review like any permission set — otherwise in two years nobody knows what the system can do.
- Another component to operate. The server needs hosting, monitoring and checking after every Business Central release. Not much, but not nothing.
- False sense of security. MCP makes what is permitted visible; it forbids nothing by itself. Business Central permissions and the authentication model remain the actual control.
Separately: MCP is young and the tooling around it moves faster than enterprise software usually does. Check the current state rather than relying on an article written months earlier — this one included.
What you can do yourself
| Part | In-house? |
|---|---|
| Stand up a server and verify the connection | Yes, with a developer |
| Register the app in Entra ID | Yes, standard procedure |
| Decide which operations are needed at all | Only you |
| Design narrow operations against the BC data model | Needs BC knowledge, not just API |
| Write descriptions the model picks correctly from | Experience shows |
| Verify the server refuses what it should | Hard without a list of other people's mistakes |
The first two rows are worth attempting before talking to any partner: a few days and you will know exactly what is missing.
Indicative pricing: discovery from $750, assistant from $3,000, agent from $6,000. Server hosting and model usage are separate running costs.
Frequently asked questions
Is MCP required for AI to work with Business Central?
No. A narrow assistant answering a dozen known questions works fine on direct API calls and ships sooner. MCP earns its cost when the capability list will grow, or when you are building agents that must choose among many operations.
Does MCP give a model access to our database?
The opposite. The model sees a list of described operations with validated parameters, and neither the database nor the credentials. The server executes calls under a Business Central identity, and the platform applies the same permissions it would to a person.
Where is the MCP server deployed?
In your own Azure environment or at your partner. That determines where credentials and logs live, which makes it a data-policy decision rather than a technical one.
How many tools should the catalogue have?
As many as fit in a document readable in one sitting. If you cannot take it in at a glance, nobody will review it and the model will start choosing badly.
Will the server survive Business Central updates?
If built on the standard API, yes — it needs checking after each major release. If it reads undocumented internals, no, which is exactly why that approach is avoided.
Can one server serve several AI clients?
Yes, and that is one of the advantages. Each client still needs its own decision about authentication and which data it may reach.