A client’s IT director asked us a version of the same question three times in the last two months: can we let an AI agent look up sales order status without giving the BI team another integration to maintain? Until this year, the honest answer involved a scoping conversation about which client needed access, whether Copilot Studio, a custom GPT, or something built in-house, followed by a separate OData or API wiring job for each one. The Business Central MCP server, now generally available, removes most of that repeated integration work. What it does not remove is the need to think carefully about what you are actually authorizing, because the place where access gets decided is narrower and more consequential than most admins realize the first time they open the configuration page.
What the MCP Server Actually Replaces
The Model Context Protocol is an open standard for connecting AI applications to external systems through a single, predictable interface rather than a bespoke integration per client. Business Central’s implementation exposes a hosted endpoint at mcp.businesscentral.dynamics.com that any MCP-compliant tool can call once it authenticates. Microsoft’s own clients, Visual Studio Code with GitHub Copilot and Copilot Studio, are pre-registered and require no extra setup on the Entra side. Claude, ChatGPT, and other third-party or custom agents can connect too, though they require a one-time Entra ID app registration performed by someone with Application Developer rights in the tenant. The practical effect is that a solution architect no longer has to build and maintain a separate connector for every AI tool the business wants to try. One configuration, applied once inside Business Central, governs how every one of those clients sees the environment, and that consolidation matters more than the fact that an AI tool can now query an ERP system at all.
It is worth noting this applies to Business Central Online only. On-premises deployments are not in scope, which is consistent with how Microsoft has handled most of its recent Copilot and agent investments across the Dynamics 365 portfolio.
Read Access Is the Easy Part, and It’s Already On
By default, the Business Central MCP server exposes read-only access to every API page already published in the environment, and this requires no configuration at all. For a reporting agent or a Copilot Studio bot meant to answer “what’s our open AR balance for this customer,” that default is genuinely useful out of the box. It also means that the moment the MCP server is enabled for a tenant, every exposed API page becomes queryable by whatever client successfully authenticates, so the meaningful early decision is not whether to allow reads, but which identity gets to authenticate and what that identity’s permission set already restricts. The MCP layer inherits Business Central’s existing role-based security, so a user whose permission set excludes payroll data will not see payroll data through an agent either. That inheritance is reassuring, but a poorly scoped Business Central user account handed to an agent is just as risky through MCP as through the web client itself.
Where the Business Central MCP Server’s Governance Boundary Lives
Write access is a different story, and this is where the configuration work actually matters. Administrators manage it through the Model Context Protocol (MCP) Server Configurations page, where each configuration record lists specific API page objects and, for each one, individual toggles for Allow Read, Allow Create, Allow Modify, Allow Delete, and Allow Bound Actions. Bound actions matter more than the name suggests: they let an agent trigger real business logic, such as posting a sales invoice or releasing a purchase order, rather than just editing a field. There is also a shortcut labeled “Add All Standard APIs as Tools,” genuinely convenient for standing up broad read access quickly. The trap is treating it as a shortcut for write access too. Flipping create, modify, or delete permissions across every standard API in one pass means an agent misinterpreting a prompt, or a poorly written custom skill, now has a blast radius spanning the entire ledger instead of the two or three record types the business case actually called for.
Environments with many exposed APIs can also turn on Dynamic Tool Mode, which discovers tools at runtime instead of registering all of them up front, paired with Discover Additional Objects to give agents read-only access to API pages that were not explicitly configured. That combination is sensible for read scenarios at scale. It becomes a governance question the moment someone also enables Unblock Edit Tools on that same broad configuration, since it is easy to lose track of exactly which of dozens of auto-discovered objects now also permit writes. The cleanest pattern we have used with clients keeps broad discovery strictly read-only, and adds write-enabled API pages one at a time, by object, as a named and reviewed decision rather than a blanket setting.
The OAuth Scope Doesn’t Match the MCP Permission Model
There is a nuance here worth flagging explicitly for anyone doing the Entra ID side of this setup. When a non-Microsoft client like Claude or a custom agent registers its application in Entra ID, the delegated permission it requests against Business Central is Financials.ReadWrite.All, granted once at admin consent. That is a broad grant at the identity and OAuth layer, and it does not change when someone later tightens or loosens the per-object CRUD flags on the MCP Server Configuration page back in Business Central. The actual restriction a business relies on day to day lives entirely in that configuration record, not in the OAuth consent granted months earlier, which will not prompt the user again. If a configuration is later expanded from read-only reporting to include modify rights on the customer API, for instance, nothing at the identity layer flags that expansion. That makes the MCP configuration closer to a firewall rule than a one-time setup step, and it argues for reviewing these configurations on the same cadence as any other integration user’s permission set, not just at go-live.
A Practical Rollout Pattern
For clients asking how to approach this without over-restricting the agent into uselessness or over-provisioning it into a risk, the pattern that has worked well starts narrow and expands deliberately. Begin with a configuration that leaves Unblock Edit Tools off entirely, relying on default read-only behavior across whatever API pages the business wants an agent to query, whether that is sales orders, item availability, or open AR. Name the configuration for its actual business purpose, such as SalesTeamConfig, rather than something generic, since that name is what shows up in Copilot Studio and in any audit trail. Once a specific write use case is identified and tested, such as letting an agent update expected ship dates on an open sales order, add only that API page with only the Modify flag enabled, leaving Create, Delete, and Bound Actions off unless there is a tested reason to need them. Treat bound actions, especially anything that posts a document or changes a financial status, as requiring a human approval step inside the agent’s own workflow logic before that permission is ever granted, since the MCP server itself has no concept of an approval gate. It simply executes what it is authorized to execute.
A Few Practical Limits to Plan Around
API pages of the ListPart and CardPart subtypes are not supported as MCP tools, so only top-level API pages can be exposed, which occasionally requires a small amount of extension work if the data an agent needs lives behind a part page rather than a standalone API. Copilot Studio also caps agents at seventy tools, which is the practical reason Dynamic Tool Mode exists for larger environments. And if a company or configuration name contains non-ASCII characters, most clients require that value to be Base64-encoded in the connection headers, with Copilot Studio being the one client that handles this automatically. None of these are dealbreakers, but they are the kind of detail that turns a quick proof of concept into a half-day debugging session if nobody catches them up front.
Where This Leaves Solution Architects
The interesting part of this release is not that an AI agent can now talk to an ERP system, since that capability has existed in various bespoke forms for a while. It is that Microsoft put a single, inspectable governance surface between every possible AI client and the underlying ledger, one that any admin can open and audit without understanding the internals of whatever agent is calling it. That is a meaningfully better starting position than trusting each client’s own integration code to enforce the right boundaries. We have started treating the MCP Server Configuration record the same way we would treat a new integration user’s permission set during a Business Central implementation: an artifact that gets documented, reviewed at go-live, and revisited whenever a new agent use case gets added. Firms that skip that step are not doing anything wrong on day one. They are just deferring a governance conversation that will eventually happen anyway, usually right after someone asks why an agent was able to do something nobody remembers explicitly approving.
Routeget Technologies has been helping clients scope these MCP configurations as part of broader Copilot and agentic AI rollouts across Dynamics 365, and the lesson so far is consistent: the technology is ready faster than most internal governance processes are, so the configuration discipline matters more than the initial setup.
#BusinessCentralMCP #DynamicsFinanceOps #AgenticAI #CopilotStudio #ERPGovernance #EnterpriseAI #DynamicsBusinessCentral