Business Central AI Agents Over MCP: What the Layer Does, and What It Must Never Do

The Business Central MCP server lets an AI client, such as Claude, Copilot Studio or GitHub Copilot in Visual Studio Code, read Business Central data and, if you allow it, create, change and delete records through API pages. It runs under the signed-in user’s identity and permissions, and it is read-only until someone turns writing on. Connecting it takes an afternoon. The real work is deciding what the model may write, and making sure every write goes through a path that was designed for it.

We run it on our own Business Central tenant, from Claude Code, for internal work such as checking and rebuilding time sheets.

On our side, Claude Code runs Klyr, the AI clone our founder Nabil BA-MOH built. It keeps a persistent memory of his context.

What does the Business Central MCP server actually expose?

It exposes API pages as tools. There is one endpoint, shared by all tenants, https://mcp.businesscentral.dynamics.com, and four HTTP headers pick the target: TenantId, EnvironmentName, Company and, optionally, ConfigurationName.

A configuration is a record on the Model Context Protocol (MCP) Server Configurations page (page 8351). You add API pages to it and, for each one, tick what the agent may do: read, create, modify, delete, run bound actions. Each allowed operation becomes a tool. Only top-level API pages qualify: Microsoft’s documentation states that ListPart and CardPart API pages are not supported as MCP tools.

The fact that should frame every discussion with a finance team: by default, the MCP server gives agents read-only access to all exposed Business Central API pages. Nothing writes until a configuration says so.

When a configuration lists many pages, Dynamic Tool Mode replaces the long tool list with three system tools, bc_actions_search, bc_actions_describe and bc_actions_invoke. The agent searches for the action it needs, reads its schema, then calls it. Microsoft gives the reason: Copilot Studio currently caps an agent at 70 tools, and the standard API set is larger than that.

How do you connect an AI client like Claude to Business Central?

You register your own application in Microsoft Entra ID. Claude Code tries Dynamic Client Registration by default, and Entra ID does not support it. That shows up as “Incompatible auth server: does not support dynamic client registration”. Retrying does nothing. The fix is a manual app registration and its client ID in the client configuration.

Three details cost us time and are worth writing down:

• The redirect URI for Claude Code is http://localhost:<port>/callback. The /callback suffix is required.
• The port must be fixed and identical in Entra and in the client configuration, otherwise the client picks a random port that never matches.
• The sign-in opens a browser on the user’s machine. An unattended agent cannot complete it on its own, which is a feature, not a bug.

Microsoft’s setup guide has you grant the delegated permission Financials.ReadWrite.All, and we found no read-only delegated scope for Business Central. In practice, the token the AI client holds is a read-write token. That fact decides where the guardrail has to live.

Where does the read-only guardrail actually live?

In Business Central, not in Entra. Two layers do the work.

The first is the configuration switch Unblock Edit Tools. When it is off, the create, modify, delete and bound-action permissions are all forced to false, and every tool in the configuration is read-only, whatever the checkboxes say.

The second is the user. Microsoft’s documentation states that all operations run with the user’s own identity and permissions, so audit trails show who performed each action. An agent cannot do what its user cannot do. This is why we never connect an agent through a shared account: the audit trail would only say “the account”.

We do not take the read-only setting on trust. With Dynamic Tool Mode, we search for actions of type Create, Modify, Delete and BoundAction. A read-only configuration answers “No matching actions found”. That answer is the proof. The checkbox is only the intention.

One setting deserves a warning. Discover Additional Objects gives agents read-only access to every API page in the environment, including pages you never added to the configuration. Read-only is still access. Turn it on for exploration, not for an agent that a whole department will use. The same goes for the ConfigurationName header: it is optional, and when a client connects without naming a configuration, Microsoft’s documentation states that read-only tools are available for all API pages.

What does an AI agent do well on Business Central?

Reading, cross-checking and preparing. On our own time sheets, the agent reads the month’s entries, groups them, flags lines that do not add up and prepares the corrected lines. The checking pass only reads. Writing is a separate step, run on purpose, never a side effect of a question.

Reading is also where the agent fails silently, and the failure looks like confidence. Two cases we hit:

• The wrong axis. Absences in our tenant are not recorded the same way for employees and for contractors: one uses a cause-of-absence code, the other a dedicated project and task. The agent searched the project, found nothing for employees, and reported “no absence recorded”. The absences were there, on the other axis.
• The truncated window. One of our API pages does not accept a filter on the resource number. Fetching the first 1,000 lines and filtering afterwards returned a window that stopped months before the target period, and the agent reported zero lines for a month that had plenty. The rule since: always bound the query by date first.

An agent that filters the wrong field, or filters a capped page of results, reports “nothing found” with exactly the same confidence as a real empty result. Any number an agent reads from Business Central gets checked against a second route before anyone acts on it.

What must an AI agent never do on Business Central?

Four rules, each born from something we saw.

Never write before confirming the company. The company is an HTTP header read when the client connects. It is not a per-call parameter: in our tests, a request carrying a company property was rejected as an unknown property. Changing the header has no effect until the connection is re-established. So before any create, modify or delete, the agent reads the company information record and checks the display name. Proofs of concept run in a test company, never in production.

Never write straight into the business data. In our own extension, the write path we designed for AI-entered time is a staging page: quantities land there first, and a separate, explicit process action moves them into the time sheets. The model fills a buffer. A deliberate action commits it. That staging design is ordinary AL work, and it is the part that makes the AI safe, which is why the question of which Business Central customizations are worth writing applies to AI features too.

Never assume a bound action receives its arguments. On our tenant, the describe step for our own bound actions exposed no input parameters, and only parameterless actions went through. We work around it with a context record: the agent first writes the parameters to a per-user record, then calls a parameterless action that reads and deletes it. The record is single-use and expires after five minutes. Single-use also means strictly serial calls, so bulk writes run as a plain REST loop against the same Business Central API pages, and MCP is kept for reading, checking and single, deliberate writes. This is what we observed, on our configuration; test it on yours before relying on it.

Never let an agent run under an identity you cannot audit. Operations carry the user’s identity, and Business Central telemetry, from version 28.0, records MCP server tool calls. That is the audit trail a finance director will ask for. A shared “AI” account throws it away.

Is this “ERP plus AI”, or a chatbot on top of an ERP?

The difference is what has been designed. The AI part is small: a client, a configuration, a sign-in. The ERP part is most of the work. Which API pages are exposed, which ones are read-only by construction, where the staging buffers sit, which actions exist to commit a change, and who can run them. None of that is new technology. It is the same discipline as any integration, with one extra constraint: the caller can misread a question.

A partner who shows an agent writing freely into production has shown a demo, not a system. The version that holds up in front of an auditor is the one where the model proposes, the ERP only accepts writes through doors built for them, and each write carries a person’s name.

The Asio Services way

Start read-only, and prove the read-only state by searching for write actions rather than trusting the switch. Keep write paths in their own configuration, apart from the one used for questions. Then open writes one door at a time: a staging page, an explicit action, a check on the target company, a named user. The custom pieces, buffers, actions and API pages, are Business Central development in the plain sense, not an AI product.

If you want to know what an agent could safely do on your own tenant before anyone connects one, start with a clarity session.

FAQ

Is the Business Central MCP server read-only by default?

Yes. Microsoft’s documentation states that by default the MCP server gives agents read-only access to all exposed API pages. Create, modify, delete and bound actions must be allowed in a configuration, with Unblock Edit Tools turned on.

Can I give an AI client a read-only permission in Entra ID?

Not that we found. Microsoft’s setup guide has you grant the delegated permission Financials.ReadWrite.All, and we found no read-only delegated scope for Business Central. Read-only is enforced in Business Central, through the MCP configuration and the user’s own permissions.

Does an AI agent bypass Business Central permissions?

No. Every operation runs with the signed-in user’s identity and permissions, so the agent can do exactly what its user can do, and the audit trail shows that user. This is why the agent should never run under a shared account.

Which AI clients can connect to Business Central through MCP?

Microsoft lists Visual Studio Code with GitHub Copilot, Copilot Studio, and other clients that follow the MCP specification, such as Claude and ChatGPT. Microsoft clients use a preregistered application; the others need your own app registration in Entra ID.