How to Use AI and MCP to Automate Your Shop Floor in Business Central

Reading Time: 3 minutes

After 15 years on Business Central and NAV (and 30 in ERP overall) across factories in Greece, the UK, and Europe, I see the exact same frustration everywhere. There is a goldmine of data sitting inside BC: production orders, routing times, capacity logs. But the people on the shop floor can’t get to it fast enough. Planners are forced to click through five different screens, set up complex filters, and run heavy reports just to answer a simple question like, “Which machine is our bottleneck today?”

Recently, I started solving this using AI agents connected via the Model Context Protocol (MCP).

If you haven’t heard of MCP, it’s an open standard that gives AI agents (like Claude) a clean way to securely query external databases. Instead of teaching a planner how to navigate BC, they just type, “Show me the late orders for Work Center 2,” and the AI pulls the exact data.

But here is the catch: BC doesn’t just magically talk to MCP out of the box. You have to build the bridge. The AI needs custom API pages written in AL to understand your manufacturing reality. Standard BC APIs for Customers or Sales Orders won’t cut it for the shop floor.

Building the Right API Pages

If you just expose the raw Production Order table to an AI, it will struggle. The secret to a fast, smart AI agent is doing the heavy lifting inside Business Central before the data ever reaches the LLM.

For example, I never just send the Starting Date and Due Date. I write a custom API page that calculates real-time signals. I add a boolean for IsOverdue and a decimal for CompletionPercentage.

Here is how the AL actually looks for the API page:

page 50100 "MCP Prod. Order API"
{
    PageType = API;
    EntityName = 'mcpProductionOrder';
    EntitySetName = 'mcpProductionOrders';
    SourceTable = "Production Order";
    DelayedInsert = true;

    layout
    {
        area(Content)
        {
            repeater(Group)
            {
                field(no; Rec."No.") {}
                field(status; Rec.Status) {}
                field(itemNo; Rec."Source No.") {}
                field(quantity; Rec.Quantity) {}
                field(finishedQty; Rec."Finished Quantity") {}

                // Calculated fields so the AI doesn't have to guess
                field(isOverdue; IsOrderOverdue) {}
                field(completionPct; CalcCompletion) {}
            }
        }
    }

    trigger OnAfterGetRecord()
    begin
        IsOrderOverdue := (Rec."Due Date" < Today) and
            (Rec.Status in [Rec.Status::Released, Rec.Status::"Firm Planned"]);

        if Rec.Quantity > 0 then
            CalcCompletion := Round((Rec."Finished Quantity" / Rec.Quantity) * 100, 2)
        else
            CalcCompletion := 0;
    end;

    var
        IsOrderOverdue: Boolean;
        CalcCompletion: Decimal;
}

When the AI agent reads this, it doesn’t need to do any math. It just looks for isOverdue = true and immediately answers the user.

Exposing Capacity and Bottlenecks

You have to do the exact same thing for your Work Centers. If an agent tells a planner that an order is late, the very next question will be “Why?”.

I build a secondary API page for Work Center. In the OnAfterGetRecord trigger, I sum up the allocated times from the routing lines of all Released orders. If the utilization goes above 90%, I flip a custom IsBottleneck boolean to true. When the AI sees that flag, it can proactively warn the planner: “Work Center W002 is currently a bottleneck at 94% capacity, which is delaying your order.”

Letting the Agent Take Action

Reading data is great, but allowing the AI to execute tasks is where it gets really interesting. You can expose AL Codeunits as unbound OData actions.

I usually create a specific Codeunit that allows the AI to change a Firm Planned order to Released. The critical rule here is validation. Never trust the AI to blindly update status fields. Your Codeunit must verify that the inventory is actually available and the routing is certified before it allows the Status change. If it fails, return a clear text error so the AI can explain the problem to the user.

Get the Code

I’ve published a working example of these manufacturing API pages on GitHub: github.com/GmsoftLtd/MCP-Manufacturing-Examples

It contains AL API pages and agent actions to connect Business Central manufacturing data to MCP-compatible AI agents (Copilot Studio, Claude, Azure OpenAI). Free to use, modify, and learn from. Star the repo if you find it useful.

The Reality on the Floor

I know putting “AI” and “Shop Floor” in the same sentence sounds like a science fiction project that will take six months to fail. But the reality is that writing these API pages takes a competent BC developer a few hours.

Once you connect an MCP server to those APIs, the dynamic completely changes. I’ve seen planners in Greek factories who used to spend 40 minutes every morning hunting down delayed orders in BC, now get their full daily briefing in 10 seconds just by asking a chat window.

The standard BC interface isn’t going anywhere, but for fast, operational answers, this is exactly where the industry is heading.