Business Central MCP Custom Data Queries Let AI Agents Access Data Without APIs

That one sentence matters a lot for anyone who has built a Business Central integration and then found out the field they needed wasn't on any API page.

What Microsoft has actually announced​

Here is what the record and Microsoft Learn show:

• Feature: New MCP tools for defining, validating, and running custom data queries against Business Central.
• Stated purpose: Let MCP applications query data that no existing API exposes.
• Product and platform: Dynamics 365 Business Central, Web.
• Cloud instance: Worldwide (Standard Multi-Tenant).
• Roadmap status: Listed as "Launched," with a general availability target of October 2026.

Two different labels are in play here. Microsoft Learn's "What's new" page for Business Central 2026 release wave 2, update 29.0 lists the same feature with the same description. That page calls 29.0 a public preview that applies only to online sandbox environments, not production or on-premises. Microsoft says the preview runs from the first week of September until 29.0 reaches general availability in the first week of October 2026. It also says more on-premises information will be added at GA.

October has only just started. The roadmap's "Launched" label and its month-level GA target do not confirm that the feature has reached every production tenant. Until Microsoft publishes the 29.0 GA documentation, treat this as a sandbox preview capability on its way to production. Microsoft's own preview terms say preview features aren't meant for production use, may have restricted functionality, and can change.

Section summary: The feature is real and documented. In the 29.0 preview it runs only in online sandboxes, and Microsoft targets general availability for October 2026.

Why "no existing API" is the key phrase​

Business Central's MCP server has always been limited by the APIs behind it. Microsoft's MCP overview says that, by default, the server gives read-only access to all exposed Business Central API pages. Write operations need an administrator to configure create, modify, delete, and bound-action permissions on specific API page objects. If the data isn't on an API page, the agent can't see it.

Partners hit this limit early. Stoneridge Software, writing about extending MCP with custom API pages, put it this way: MCP can only reason over what API pages expose. The firm also warned that when key relationships, intent, or constraints are missing or weakly described, the agent produces answers that reflect that partial view. Until now, the fix was to write a custom AL API page or API query, ship it as an extension, then expose it through an MCP configuration.

The new tools appear to shorten that route. The MCP application defines a query, validates it, and runs it, without waiting for a developer to publish a new API object first.

How this differs from earlier MCP changes​

This feature is easy to mix up with earlier ones, so here is the timeline:

The middle row is the one most likely to cause confusion. In wave 1, Microsoft added API queries to MCP configurations and described them as access to "pre-aggregated and optimized datasets" for reporting and analytics. Those are still query objects that a developer has already published. The wave 2 item is different because the MCP application supplies the query itself.

That wave 1 change closed a gap people had noticed. When the MCP configuration page first appeared in BC27.1, Business Central MVP Yun Zhu observed that the Object Type only shows Page, not Query. Does this mean it doesn't support the Query API? Wave 1 added that support. Wave 2 goes further, from running queries someone already published to defining new ones.

Section summary: Wave 1 let agents run published API queries. Wave 2 lets MCP applications write and run their own queries for data that has no API.

What Microsoft hasn't said yet​

Microsoft's preview entry is a single line, so these questions are still open:

• Query format: It doesn't say what language or syntax a custom query uses. It could resemble AL query objects, OData-style expressions, or something new. The documentation doesn't specify.
• Tool names: No tool names are documented.
• Scope: It doesn't say which tables can be queried, or whether system, sensitive, or extension tables are included or excluded.
• Permissions: It doesn't say whether custom queries need their own MCP configuration setting or new permission sets.
• Limits: Row limits, paging, timeouts, and throttling aren't documented.
• What "validate" checks: Probably syntax and maybe permissions, but Microsoft hasn't said.

Microsoft's MCP documentation does describe the security model for the server overall. Hosts connect to the single endpoint [url]https://mcp.businesscentral.dynamics.com[/url]. They choose the target with HTTP headers: TenantId, EnvironmentName, Company, and an optional ConfigurationName. Authentication uses Microsoft Entra ID with OAuth 2.0 Authorization Code flow and PKCE. All operations run under the signed-in user's identity and permissions, so audit trails show who did what.

It's reasonable to hope the new query tools follow the same rules. Microsoft hasn't confirmed it, and with query tools that's worth checking, not assuming.

The governance question​

Here is the uncomfortable part. Custom API pages took effort to build, and that effort acted as a filter. Each one forced someone to decide what to expose, write descriptions for fields, and review the result. Stoneridge called that choice a boundary decision that limits which data the agent can reason over.

Ad hoc queries remove that review step. That is the convenience, and it is also the risk. If the new tools respect the user's Business Central permissions, as the rest of the MCP server does, the agent can't see anything the user couldn't already see. But user permissions are often broader than anyone would deliberately give an agent. An accountant with wide read access is a different risk once a language model is writing queries on their behalf.

There is also a quality problem, separate from security. Curated API pages carry meaning: captions, descriptions, and joins that reflect how the business works. A query an agent writes from raw tables may return accurate rows and still give the wrong answer, for example by missing a dimension filter or mixing posted and open documents.

Then there is the ecosystem. Community projects already fill the gap from outside. Several open-source MCP servers wrap Business Central's OData endpoints. One describes itself as reaching any entity reachable through the standard v2.0 API or a custom AL API, but it still depends on APIs existing. A native query capability from Microsoft could make some of those wrappers unnecessary.

How to evaluate it​

This is practical guidance based on Microsoft's preview rules, not a test of the feature itself:

1. Use a sandbox. Create a new sandbox on 29.0 preview, or update an existing one, choosing version 29.0 preview in the admin center. Microsoft says preview sandboxes are deleted automatically 30 days after 29.0 reaches GA, in early November 2026. They also can't be moved to another version, so don't rely on one long term.
2. Connect a supported MCP host. Microsoft supports Visual Studio Code with GitHub Copilot, Copilot Studio, and other spec-compliant clients. VS Code and Copilot Studio use a preregistered Entra app. Other clients need their own app registration.
3. Check which tools appear. Note the names and descriptions of the query tools your MCP configuration actually exposes, and whether a configuration setting controls them.
4. Test permissions on purpose. Sign in as users with limited permission sets and confirm that the query tools return only what those users can already see.
5. Look at validation and failures. Try malformed and overly broad queries, and see what validation rejects and what errors come back.
6. Compare with your existing integrations. List the custom API pages you built only to unblock agents, and decide which you would still keep for documentation and governance reasons.
7. Wait for GA docs before using production. Microsoft says preview features aren't production-ready, and on-premises details aren't out yet.

Where this fits​

This feature is part of a larger push. The same 29.0 preview list includes AI agents that profile slow sessions, debug recorded failures, and allocate AL object IDs. It also includes a report inbox API that can be automated through MCP. Microsoft is also moving Business Central announcements from Release Plans to the AI at Work roadmap starting in September 2026. Business Central is clearly being rebuilt with agents as first-class clients.

For partners and in-house developers, the takeaway is simple. Being able to query data with no API attached could save weeks of extension work, but it also turns API design into more of a governance decision than a delivery bottleneck. Test it in a sandbox now, decide your access rules before GA, and keep your audit logs.