# Business Central MCP server: query data with no API page

> Business Central 29.0 lets agents define, validate and run data queries against tables with no API page. What it does, how to enable it, where it stops.

Published: 2026-10-08 · Updated: 2026-10-08
Author: Preetham Reddy
Tags: Dynamics 365, AI/ML, Databricks
Canonical: https://www.techfabric.com/blog/business-central-mcp-server-data-queries-no-api

---

Business Central 2026 release wave 2 adds MCP tools that let an AI agent define, validate and run its own data queries, so it can reach data for which no existing APIs exist. That removes the step that has gated every agent project on Business Central so far. Somebody had to write an API page in AL and deploy an extension before an agent could read a table at all.

Microsoft lists the feature as [Run data queries with MCP Server](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/whatsnew/whatsnew-update-29-0) in the update 29.0 what's new table under Copilot and agents, roadmap ID 573312. The [Microsoft 365 roadmap entry](https://mc.merill.net/message/RM573312) gives the status as launched, general availability, October CY2026, worldwide standard multi-tenant. Inside the product the switch itself is labelled differently, and that difference matters when you plan a rollout. More on that below.

## What actually changed

The Business Central MCP server has been around since the 2025 wave 2 release, and its model was API pages. An agent connected, discovered the API pages and API queries the signed-in user was allowed to see, and worked through them. Read, create, modify, delete and bound OData actions all flowed through objects a developer had published. [Microsoft's own documentation](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/) is blunt about the ceiling there, noting that extending APIs with additional fields isn't currently possible and that if you need it you must copy the AL code for the API and create a custom API based on it.

So the practical shape of an agent project went like this. You'd scope the questions the agent should answer, work out which tables hold the answers, find out that three of them have no API page, write the AL, get it through a deployment cycle, then start building the agent. The data access work came first and it was the slow part.

Data Query Tools inverts that. [The MCP overview](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/ai/mcp-overview) describes the feature in one line. It enables agents to run queries directly against your Business Central database. The agent composes the query itself, Business Central validates it, and the result comes back. No new object, no deployment, no AL developer in the loop for a question nobody anticipated.

## Turning it on

The configuration lives on the Model Context Protocol (MCP) Server Configurations page in Business Central. You need at least the **MCP - Admin** permission set or equivalent, per [the configuration guide](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/ai/configure-mcp-server). On environments where the server isn't yet exposed, there's also a Feature Management toggle, `Feature: Enable MCP Server access`, [as walked through by Vladimir Drakonian](https://vld-bc.com/blog/cli-agents-part3-business-central-mcp-server).

Create a configuration, give it a name and description, and leave **Active** switched off while you work. An active configuration is read-only and its settings aren't editable until you deactivate it, which is a small detail that will catch you out once and never again.

Then the Server Features section. There are three:

- **API Tools** exposes the list of API pages and API queries your agents can access, curated by an admin.
- **Dynamic Tool Mode** lets agents discover tools dynamically instead of requiring manual configuration. It depends on API Tools, and disabling API Tools automatically turns it off. The docs give the reason you'd want it: client tool limits, such as Copilot Studio's 70-tool limit.
- **Data Query Tools (Preview)** enables agents to run queries directly against your database. Select Activate to turn it on. No additional configuration needed.

That last sentence is the whole setup. There's no allow-list of tables to curate and no per-object read flag, nothing like the Allow Read, Allow Create, Allow Modify, Allow Delete and Allow Actions permissions you set on individual API objects. You activate the feature and the agent can query the database.

This is the part to be deliberate about. The permission model doesn't disappear, because [authentication](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/ai/mcp-overview) runs OAuth 2.0 authorization code flow with PKCE against Microsoft Entra ID, and all operations are performed with your user identity and permissions, so audit trails show who performed each action. The agent is the user. But the per-object gate that an admin curated by hand is replaced by whatever that user's Business Central permission sets allow. If your permission sets are loose because historically the only things reading tables were pages a developer had reviewed, this feature is the moment that assumption stops holding.

## What the agent is writing

The queries are AL query objects, the same construct developers have used for years. A [query object](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-query-object) retrieves records from one or more tables and combines them into rows and columns in a single dataset, and can perform calculations such as sums or averages over a column. It's built from two main element types, dataitems, which specify the table to retrieve records from, and columns, which specify a field to include in the result.

As an illustration of the shape, a query joining customers to their ledger entries looks roughly like this:

```al
query 50100 "Customer Balances"
{
    QueryType = Normal;

    elements
    {
        dataitem(Customer; Customer)
        {
            column(No_; "No.") { }
            column(Name; Name) { }

            dataitem(CustLedgerEntry; "Cust. Ledger Entry")
            {
                DataItemLink = "Customer No." = Customer."No.";

                column(Amount; Amount)
                {
                    Method = Sum;
                }
            }
        }
    }
}
```

That snippet is an illustration of query object structure, not output captured from the MCP tools. The point of showing it is that the thing the agent produces is a known, compiled, typed artifact. It isn't free-text SQL against your tenant. Business Central compiles it, and the [AL diagnostics](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/diagnostics/diagnostics-overview) that constrain a human developer constrain the agent too. Queries must define a top-level DataItem (AL0343), the DataItemLink property must be set for nested data items (AL0344), and the source of a Column or Filter must be a field (AL0345). A malformed query fails to compile and the agent gets an error it can act on, which is a far better failure mode than a syntactically valid query returning the wrong rows.

```mermaid
%% caption: With Data Query Tools activated, an agent composes an AL query that Business Central compiles and runs, instead of waiting on a developer to publish an API page.
flowchart TD
    A["MCP host asks a question"] --> B{"Does a published API page exist"}
    B -->|"Yes"| C["API Tools read the page"]
    B -->|"No, old path"| D["Developer writes and deploys AL"]
    B -->|"No, new path"| E["Agent defines an AL query"]
    E --> F["Business Central compiles and validates"]
    F --> G["Query runs under the user identity"]
    class E accent
    class D legacy
```

## Connecting a client

Every MCP host connects to the same endpoint, `https://mcp.businesscentral.dynamics.com`. Four HTTP headers select the context, `TenantId`, `EnvironmentName`, `Company` and the optional `ConfigurationName`. Visual Studio Code with GitHub Copilot and GitHub Copilot CLI can omit all four; Copilot Studio currently requires tenant, environment and company, though the docs note headerless support is coming. Other hosts depend on host support.

One encoding rule is worth knowing before it bites you. If the Company or ConfigurationName values contain non-ASCII characters such as ø, æ or å, encode them Base64 UTF-8 in the format `=?base64?<encodedvalue>?=`. So `CRONUS Århus A/S` becomes `=?base64?Q3JvbnVzIMOFcmh1cyBBL1M=?=`. Copilot Studio handles the encoding for you.

Microsoft hosts use a preregistered application. Non-Microsoft clients, Claude and ChatGPT among the supported MCP-compliant options, require you to register your own application.

## Where the limits sit

It's read-only analysis. The overview lists running read-only queries directly against your database for advanced analysis as a distinct capability from viewing and managing records or executing business processes. If you want an agent to post a document or change a status, that's still API Tools with Unblock Edit Tools on and the specific Allow Actions permission set. Data Query Tools doesn't give you writes and shouldn't.

It's a live production database. Every query the agent runs is load on the system your warehouse staff are using. An agent that reasons its way to the answer by trying six variations of a join across the item ledger is doing that against the same tenant that's trying to post shipments. There is no documented throttle, cost control or result cap for this feature, which means your controls are the ones you impose, so think about a sandbox for development and take a hard look at whether exploratory agent traffic belongs on production at all.

And there is the preview label. The Learn what's-new table lists the feature at general availability and the roadmap says launched, GA, October 2026. The server feature in the configuration page is called Data Query Tools **(Preview)**. Treat the in-product label as the operative one, because that's the surface you're switching on. Preview features change. Build an internal agent on it now, and keep it out of the path of a customer-facing commitment this quarter.

Finally, it answers questions about one company in one environment at one moment. It has no history beyond what your tables retain, no data from your CRM or your warehouse management system, and no cheap way to scan three years of ledger entries for a trend.

## Where the lakehouse picks up

That last limitation is the dividing line, and it's a useful one. Conversational questions about current state belong on MCP. Questions that span years, span systems, or feed a model belong somewhere the data has been landed and shaped.

Getting Business Central into Databricks takes more work than the conversational side, because there's no managed connector for it. The [Lakeflow Connect Dynamics 365 connector](https://learn.microsoft.com/en-us/azure/databricks/ingestion/lakeflow-connect/d365) reads data that Azure Synapse Link exports from Dataverse, and Business Central doesn't keep its data in Dataverse. Two routes work:

- **The API, incrementally.** A Databricks job pulls the standard API pages with a `lastModifiedDateTime` filter, so each run reads only what changed. Run it under its own account, so the reporting load doesn't spend a person's request quota.
- **bc2adls.** It exports Business Central tables incrementally to Azure Data Lake Storage or Microsoft Fabric, where Databricks picks them up. Microsoft [archived its own repository](https://github.com/microsoft/bc2adls) in September 2023; the [community fork](https://github.com/Bertverbeek4PS/bc2adls) is the one still being released.

So the pattern falls out cleanly. MCP handles the question a controller asks on a Tuesday afternoon about an open order, and the lakehouse handles the forecast, the margin trend and anything an ML model trains on. We wrote about choosing between those layers in [Business Central reporting: built-in, Power BI or lakehouse](/blog/business-central-reporting-built-in-power-bi-or-a-lakehouse), and this feature doesn't change that calculus so much as sharpen it. Data Query Tools makes the conversational layer genuinely useful without a developer, which means the lakehouse no longer has to carry the "somebody wants to ask an odd question" workload. It can be the analytical platform it's good at being.

## If you are starting this week

Stand up a Business Central sandbox on 29.0 and create a named MCP configuration instead of modifying the built-in default, which has dynamic tool mode and read-only object discovery on and is used whenever a connection doesn't specify `ConfigurationName`. Activate Data Query Tools there and connect Visual Studio Code with GitHub Copilot first, because it can omit all four headers and you'll find out whether the feature does what you need in minutes instead of after an app registration.

Then go and read your permission sets. The feature has no per-table configuration, so a user's permission sets are the entire access boundary. Pick the account the agent will authenticate as and enumerate what it can actually see, before you point anything at a production environment.

If you're already landing Business Central data in Databricks, nothing here replaces that; the API's request budget and the export schedule still shape that architecture. Our [Databricks work](/databricks) tends to start exactly there. What changes is that the question "does this table have an API page?" stops being the first thing that blocks an agent, and that was a question nobody enjoyed answering.

## Frequently asked questions

### What is Data Query Tools in the Business Central MCP server?

Data Query Tools is a server feature on the Business Central MCP server that enables agents to run queries directly against your Business Central database, letting them reach data for which no existing API page exists. It's activated per MCP server configuration from the Model Context Protocol (MCP) Server Configurations page and requires no additional configuration once turned on.

### Do I still need API pages for Business Central agents?

You need API pages for anything that writes, because create, modify, delete and bound OData actions still run through API Tools with the relevant Allow permissions on each object. Data Query Tools covers read-only analysis, so the pattern is API pages for the operations an agent performs and data queries for the questions it answers.

### Is Run data queries with MCP Server generally available or in preview?

Microsoft's update 29.0 what's new table lists it at general availability and the Microsoft 365 roadmap gives an October CY2026 GA date with status launched, while the server feature in the Business Central configuration page is labelled Data Query Tools (Preview). Plan against the preview label, since that's the switch you're actually enabling and preview features can change.

### How do I get Business Central data into Databricks?

There's no managed connector for Business Central, so it's one of two routes: a Databricks job that reads the Business Central APIs incrementally with a `lastModifiedDateTime` filter, or the bc2adls extension, which exports tables to Azure Data Lake Storage or Microsoft Fabric for Databricks to read. We compare them in [Business Central reporting: built-in, Power BI or lakehouse](/blog/business-central-reporting-built-in-power-bi-or-a-lakehouse).