Blog
The Business Central MCP server: plugging AI agents into your ERP
In June we sorted Business Central’s AI features into two camps: turn on now, and pilot carefully. A month on, the most interesting development in that space is not another Copilot button. It is plumbing. Business Central now has a Model Context Protocol (MCP) server, and it changes how every future agent, Microsoft’s or anyone else’s, will talk to your ERP.
The plug, not the appliance
MCP is an open standard, published by Anthropic in late 2024 and since adopted across the industry, for connecting AI agents to systems that hold data and actions. The idea is deliberately boring: instead of a hand-built integration for every agent-and-system pair, the system describes what it offers in a machine-readable way, and any agent that speaks the protocol can discover those capabilities and call them. A useful mental model is a USB port for AI. The port does not decide what gets plugged in; it just makes plugging in standard.
That framing matters because the agent landscape is moving fast. Whichever agent platform wins in your organisation, whether Copilot Studio, Microsoft 365 Copilot or something that does not exist yet, an MCP server on the ERP side means you do not rebuild the connection each time.
What Microsoft actually shipped
Business Central online now includes an MCP server, in preview since the 2025 release wave 2. It exposes the environment’s API pages: the standard v2.0 APIs for customers, items, sales orders and the rest, plus any custom API pages you have published yourself. Every Business Central tenant reaches it through the same endpoint, mcp.businesscentral.dynamics.com, and a small connection string (tenant, environment, company, configuration name) that you copy straight from a page inside Business Central.
On the other end of the wire you can put Copilot Studio, Microsoft 365 Copilot and Teams, Visual Studio Code, or any other MCP-capable client. That last category is the point: the same server that feeds a Copilot Studio agent also lets a developer’s coding assistant query a sandbox in natural language.
Read-only until you say otherwise
The default posture is the best design decision in the whole feature. Out of the box, agents get read-only access to the exposed API pages and nothing more. An agent can answer “what did this customer order last quarter” on day one, and it cannot touch a single record.
Writes are opt-in, and the opt-in is granular. On the MCP Server Configurations page you create a named configuration, add specific API page objects to it, and tick per object what is allowed: read, create, modify, delete, and bound actions. Bound actions deserve respect, because that is where posting a document lives. A separate configuration-level switch, Unblock Edit Tools, has to be on before any of the write permissions take effect at all. Configurations export and import as JSON files, so the setup you tested in the sandbox is the setup you promote to production, not a hand-rebuilt approximation of it.
Two guardrails sit underneath. Configuring any of this requires the MCP - ADMIN permission set. And an agent can never do more than the Business Central account it connects with is allowed to do; the configuration narrows access, it never widens it.
The 70-tool ceiling
One practical wrinkle is worth knowing before it costs you an afternoon. Every allowed operation on every API page becomes a separate MCP tool, and Copilot Studio currently caps an agent at 70 tools. Add all standard APIs to a configuration and the ceiling arrives quickly, with the tools beyond it silently unavailable. The fix is Dynamic Tool Mode: instead of a fixed tool list, the agent gets three system tools to search, describe and invoke operations at runtime, so the whole surface stays reachable. A companion switch, Discover Additional Objects, extends read-only reach to API pages you never listed. Broad read access with narrow, explicit write access is a sensible shape for most first deployments.
The admin centre gets one too
The 2026 release wave 1 adds a second, separate MCP server, this one in front of the admin centre APIs. It is aimed at the operational side of running environments: copying a sandbox, checking update windows, inspecting environment status, the tasks that today mean the admin centre UI or a PowerShell module. Expressed as MCP tools, they become things you can ask for in plain language. For partners managing dozens of tenants this is the less flashy but arguably more immediately useful of the two servers.
What we would do with it this month
Start where the defaults already are. Connect a Copilot Studio or Teams agent to a sandbox, leave it read-only, and let a few real users ask it real questions about customers, stock and orders. That pilot needs no integration budget and produces an evidence base instead of an opinion.
Keep the discipline from our June post on Copilot and agents when you graduate to writes: one process, a person reviewing every action, consumption modelled before rollout, since agent traffic is still metered through Copilot Studio. And remember the whole feature is in preview; build the pilot expecting details to shift before general availability.
The pattern behind this release is bigger than the release itself. Your ERP is becoming something agents query and act on directly, with the governance living in Business Central rather than in each agent. Getting the configuration habits right now, while the stakes are a sandbox, is cheap. Retrofitting governance after five departments have wired up their own agents is not.
Curious what an agent wired to your own data could take off your team’s plate? Tell us your story and we will sketch the pilot with you.