The Business Central MCP server: what it does and what you decide

Microsoft ships an MCP server for Business Central. It gives AI clients a single endpoint into your environment, and it is read-only until an administrator changes that. This page explains what the server does, which switches grant write access, and which risks stay with you after you turn it on.

Every statement here comes from Microsoft Learn, with the source and the date at the foot of the page.

What is the Business Central MCP server?

The Model Context Protocol is an open standard for how an AI application talks to data sources and tools. The Business Central MCP server implements that standard. It exposes your Business Central API pages to AI clients as tools.

Microsoft lists Visual Studio Code with GitHub Copilot, Copilot Studio, and other clients that comply with the specification, for example Claude, ChatGPT and MCP Inspector. The server applies to Business Central online.

All hosts connect to the same endpoint:

https://mcp.businesscentral.dynamics.com

Four HTTP headers select the target: TenantId, EnvironmentName, Company and the optional ConfigurationName. If the company name or the configuration name contains a non-ASCII character such as ø, æ or å, you must encode the value as Base64 in the form =?base64?<value>?=. Copilot Studio does the encoding for you. A Danish company name is the most common cause of a first connection that fails.

Is the MCP server read-only by default?

Yes. Microsoft states that the MCP server gives agents read-only access to all exposed Business Central API pages. No extra setup is needed for an agent maker to read the data those APIs expose.

To let an agent create, modify or delete data, an administrator must configure the operations. The administrator needs the MCP - ADMIN permission set or equivalent permissions.

Which switches change that?

Configuration happens on the Model Context Protocol (MCP) Server Configurations page. Each configuration carries three general switches, and each API page inside it carries its own permissions.

Each API page you add as a tool carries five permissions: Allow Read, Allow Create, Allow Modify, Allow Delete and Allow Bound Actions.

Allow Bound Actions deserves separate thought. A bound action is an OData action attached to a record, and Microsoft gives posting a document and changing a status as examples. A bound action is therefore not a small write. It can post.

API pages of subtype ListPart and CardPart are not supported as MCP tools. Only top-level API pages can be added.

How does an API page become a tool?

Each allowed operation becomes one tool. With Dynamic Tool Mode off, the names follow a fixed pattern, and the agent maker selects them by hand:

ListAPIV2 - Customer_PAG30009
CreateAPIV2 - Customer_PAG30009
ListUpdateAPIV2 - Customer_PAG30009
DeleteAPIV2 - Customer_PAG30009

With Dynamic Tool Mode on, the agent does not see those names. It uses three system tools instead: bc_actions_search, bc_actions_describe and bc_actions_invoke. The agent searches for what it needs at run time.

This is convenient and it changes your review problem. With the mode off, you can read an agent's tool list and know what it can do. With the mode on, the tool list is a search space, and what the agent can do is the whole configuration.

You can export a configuration as JSON and import it into another environment. Use that to review a configuration as a file, and to keep the same configuration across sandbox and production.

Which identity does an action run as?

Your own. Microsoft states that authentication follows the MCP authentication specification, with OAuth 2.0 Authorization Code flow, Proof Key for Code Exchange, and Microsoft Entra ID as the authorization server. Microsoft states that all operations are performed with your user identity and permissions, and that audit trails show who performed each action.

Microsoft hosts such as Visual Studio Code and Copilot Studio use a preregistered application. A non-Microsoft client requires you to register your own application in Microsoft Entra ID. That registration is yours to scope, and it is where most of the risk below starts.

Which risks stay with you?

The protocol is sound. The configuration around it is where mistakes happen.

The confused deputy. A confused deputy performs an action with its own privileges instead of the privileges of the person who asked. Security guidance on MCP names this as a central risk of the pattern. It reaches Business Central through the application registration: if you grant the connecting application broader rights than the person it acts for, the user identity on the audit record no longer describes the permission that was used.

Over-scoped tokens. Use audience-bound tokens, so a token issued for one server cannot be replayed against another. Use per-client consent and strict redirect URI matching.

Write access that is wider than the job. Unblock Edit Tools is one switch for the configuration. The per-page permissions are the place to be narrow. Give Allow Modify to the two pages that need it, not to the list you added with Add All Standard APIs as Tools.

Discovery that outruns the review. Discover Additional Objects grants read access to every API page object in the environment. That may be what you want. It must not be what you got by accident.

A checklist before you allow writes

1. Create one configuration for each job. Do not reuse a broad configuration.
2. Leave Unblock Edit Tools off until a named process needs a write.
3. Add API pages one at a time. Set Allow Read only, then add what the process proves it needs.
4. Treat Allow Bound Actions as a posting permission, because it is one.
5. Decide about Discover Additional Objects on purpose, and write down the decision.
6. Export the configuration as JSON and keep it under review with your other configuration.
7. Register your own Entra application for non-Microsoft clients, and scope it to the person, not to the department.
8. Test with a user who holds narrow permissions, not with an administrator.

What the MCP server does not solve

The MCP server answers the access question well. It leaves three questions open, and they are the questions a finance team asks.

Is the figure real? The server returns rows. The model writes the sentence. Nothing in the protocol checks that a number in that sentence came from a row.

Did the read finish? A page of results looks complete. The reader needs the record count and a statement that rows remain.

What did the model understand by the question? "Overdue" means something specific in your company. An API page does not carry that definition.

Those three are the work that sits above a connector. You can build it, or you can use a platform that has it. Either way, the connection is the start of the problem and not the end of it.