How to Use the Business Central MCP Server to Automate Your Shop Floor

 

Introduction

Business Central have a lot of data about manufacturing operations - production orders, capacity, routings, quality, everything is there. The problem is that to get useful information out of it, you need to know exactly where to look. Which page, which filter, which report. For users that are not BC experts this is not easy.

 

The MCP Server for Business Central, released in BC 27.1 (2025 Wave 2), change this situation. MCP stands for Model Context Protocol and it allow AI agents to connect directly to BC and query the data using natural language. Instead of navigate to a page and set filters, the user just type a question and the agent find the answer.

 

This article explain how MCP work in practice for manufacturing scenarios. The focus is on what API pages you need to build in AL to expose production data to an AI agent, and what kind of actions the agent can perform. Pseudocode is used throughout to keep the focus on the logic rather than the syntax. Full AL source code is available on GitHub, the link appear in the green boxes.

 

This article is for BC developers, manufacturing consultants and anyone who want to understand how AI agents can connect to Business Central. Some knowledge of BC and AL is helpful but not required to follow the concepts.

 

What Is MCP and Why Should You Care?

MCP means Model Context Protocol. Its a open standard, was created originally by Anthropic (the company behind Claude AI) and now Microsoft adopt it in Business Central. The idea is simple: give AI agents a standard way to connect to external systems and get data from them.

 

Before MCP, if you want to connect an AI to BC you need to build custom connectors, or use Power Automate flows, or write some middleware. It was possible but take a lot of time and effort. MCP make this much simpler because its a standard protocol, so any AI that support MCP can talk to BC directly.

 

Think it like this. Before MCP, every AI agent speak a different language and you need to translate. With MCP, everybody speak the same language.

 

IMPORTANT: MCP Server don't replace your existing BC configuration. It just expose the API pages that you already publish. If you create a Production Order API page and publish it, the AI agent can query it. Simple as that.

 

What BC Expose by Default

Out of the box, the BC MCP Server expose the standard API pages like Customers, Items, Sales Orders and similar things. For manufacturing this is not enough. You need to create your own API pages for things like:

•        Production Orders (with status, quantities, dates)

•        Work Centers and Machine Centers with their capacity

•        Routing Lines to see which operations are blocking

•        Capacity Ledger Entries for historical data

•        Quality checkpoints if you use them

 

The good news is that creating API pages in AL is not so difficult, and once you deploy them they are automatically discoverable by any MCP-connected agent. Let me show you the logic.

 

 

Example 1 - Production Order API Page

The most important thing to expose for manufacturing is Production Orders. This allow the agent to answer questions like "what orders are late this week" or "which order have less than 50% completion" without the user need to open any page in BC.

 

The standard Production Order table have all the fields we need, but by itself its not very useful for an AI agent because the agent need to do calculations to understand the situation. So I add two calculated fields that make the agent's job much more easy:

 

•        Completion % - so the agent know immediately how far the order is

•        Is Overdue - a simple yes/no flag so the agent don't need to compare dates itself

 

This is a small thing but make a big difference. Instead of sending the agent a bunch of numbers and dates, you send it signals it can use directly.

 

Pseudocode - Production Order API

 

// API Page: productionOrders

// Publisher: insideBC  |  Group: manufacturing  |  Version: v1.0

// Source: Production Order table

 

EXPOSE FIELDS:

  id              <- SystemId (unique identifier for MCP)

  no              <- Production Order No.

  status          <- Planned / Firm Planned / Released / Finished

  description     <- Order description

  itemNo          <- The item we are producing

  quantity        <- Total quantity to produce

  finishedQty     <- How much is already done

  remainingQty    <- quantity minus finishedQty

  dueDate         <- When the order must be ready

  startingDate    <- When production start

  endingDate      <- When production should end

  locationCode    <- Warehouse location

 

CALCULATED FIELDS (we compute this for each record):

  completionPct:

    IF quantity > 0 THEN

      completionPct = ROUND((finishedQty / quantity) * 100, 2 decimals)

    ELSE

      completionPct = 0

 

  isOverdue:

    isOverdue = (dueDate < TODAY)

             AND (status is Released or Firm Planned)

 

// Why this is useful: the agent receive completionPct and isOverdue

// as ready-to-use fields. No extra calculation needed.

 

➤ Full AL source code on GitHub: https://github.com/GmsoftLtd/MCP-Manufacturing-Examples-

 

Small tip: always think about what question the agent will need to answer, and then add calculated fields that make those answers easier to get. Its much better than let the agent figure out everything from raw data.

 

Example 2 - Work Center Capacity API

The second thing you need for a good manufacturing AI is capacity information. Without this, the agent can tell you that orders are late but cannot tell you why or what to do about it. When you add capacity data, suddenly the agent can say things like "Assembly Line 2 is overloaded, thats probably why order PO-001042 is delayed".

 

The logic here is to calculate how much of each work center capacity is already allocated to released production orders, and then express this as a percentage. We also add a bottleneck flag that fire when utilisation go above 90%.

 

Pseudocode - Work Center Capacity API

 

// API Page: workCenterCapacities

// Publisher: insideBC  |  Group: manufacturing  |  Version: v1.0

// Source: Work Center table

 

EXPOSE FIELDS:

  id                   <- SystemId

  no                   <- Work Center No.

  name                 <- Work Center Name

  workCenterGroupCode  <- Department or group

  capacity             <- Total available capacity

  efficiency           <- Efficiency factor (%)

  unitOfMeasureCode    <- Hours, minutes, etc.

  directUnitCost       <- Cost per unit

 

CALCULATED FIELDS:

  allocatedCapacityNeed:

    // Go through all open capacity needs for this work center

    // from Released production orders only

    FOR EACH entry IN ProdOrderCapacityNeed

      WHERE WorkCenterNo = this.no

        AND Status = Released

    DO

      allocatedCapacityNeed += entry.AllocatedTime

 

  capacityUtilisationPct:

    IF capacity > 0 THEN

      capacityUtilisationPct = ROUND((allocatedCapacityNeed / capacity) * 100, 2)

    ELSE

      capacityUtilisationPct = 0

 

  isBottleneck:

    isBottleneck = (capacityUtilisationPct > 90)

 

// The isBottleneck flag let the agent say directly:

// 'Work Center W002 is a bottleneck this week'

// without need to interpret numbers.

 

➤ Full AL source code on GitHub: https://github.com/GmsoftLtd/MCP-Manufacturing-Examples-

 

I choose 90% as the bottleneck threshold but you can adjust this for your client. Some manufacturers consider 85% already critical. Its just a number in the code, easy to change.

 

 

Example 3 - Agent Actions (Create, Release, Summarise)

Reading data is nice but the real power come when the agent can also do things. In our scenario we want the agent to be able to create a production order, release it, and also give summaries on demand. For this we use a codeunit with several procedures that the MCP agent can call as actions.

 

The key thing to remember here: every action must return a plain text message that the agent can show directly to the user. Don't return codes or record IDs, return a sentence that make sense to a human. This is what make the experience feel natural.

 

Pseudocode - MCP Agent Actions

 

// Codeunit: MCP Prod. Order Actions

// Procedures that AI agents can call as MCP actions

 

// ── ACTION 1: Create Firm Planned Order ──────────────────────

PROCEDURE CreateFirmPlannedOrder(itemNo, quantity, dueDate, locationCode)

  // First validate the inputs, don't trust the agent to send good data

  CHECK: itemNo is not empty

  CHECK: quantity > 0

  CHECK: dueDate is not in the past

 

  CREATE new Production Order

  SET Status = Firm Planned

  SET Item = itemNo, Quantity = quantity, DueDate = dueDate

  IF locationCode provided THEN SET Location = locationCode

  SAVE the order

  EXPLODE BOM -> fill in production order lines automatically

 

  RETURN 'Production order [No.] was created for [qty] units

          of [item], due on [date].'

 

// ── ACTION 2: Overdue Orders Summary ─────────────────────────

PROCEDURE GetOverdueOrderSummary()

  FIND all Production Orders WHERE:

    Status = Released AND DueDate < TODAY

 

  IF none found THEN

    RETURN 'No overdue orders, everything is on track.'

  ELSE

    BUILD text with each overdue order:

      -> Order No., what item, remaining quantity, due date

    RETURN the summary text

 

// ── ACTION 3: Bottleneck Summary ─────────────────────────────

PROCEDURE GetBottleneckSummary()

  FOR EACH work center in BC:

    Calculate utilisation % (same logic as Example 2)

    IF utilisation > 90% THEN add to the list

 

  IF list is empty THEN

    RETURN 'No bottlenecks found, all work centers under 90%.'

  ELSE

    RETURN list with each bottleneck and its utilisation %

 

// ── ACTION 4: Release a Firm Planned Order ────────────────────

PROCEDURE ReleaseFirmPlannedOrder(productionOrderNo)

  FIND order WHERE Status = Firm Planned AND No. = productionOrderNo

  IF not found THEN ERROR 'Order [No.] not found or already released'

 

  CHANGE status to Released using BC standard status management

  RETURN 'Production Order [No.] is now released.'

 

➤ Full AL source code on GitHub: https://github.com/GmsoftLtd/MCP-Manufacturing-Examples-

 

Important: always validate inputs in your actions before doing anything. The AI agent can sometimes send unexpected values, for example a quantity of zero or a date in wrong format. Better to catch this early and return a clear error message.

 

 

How to Connect Your Agent to BC

Once you deploy the API pages and the codeunit, you need to connect your AI agent to BC through the MCP endpoint. There is few different ways to do this and I explain the most common ones.

 

Option 1: Copilot Studio (easiest for most people)

If your client already use Microsoft 365, Copilot Studio is probably the easiest option. You add a new MCP connection, point it to your BC tenant endpoint URL, authenticate with OAuth 2.0, and Copilot Studio will automatically discover all your published API pages. Then you can build a agent on top of that. No coding needed for the connection part.

 

Option 2: Claude with MCP

You can also connect Claude directly to your BC MCP server. I use this myself when I want to quickly test things or explore data without building a full agent. You ask Claude a question, it query BC in real time, and give you the answer. Very useful for development and for technical users.

 

Option 3: Azure OpenAI with Custom Agent

If you need more control or if your client have enterprise requirements, you can build a custom agent with Azure OpenAI and the Agent SDK. You define exactly which BC operations the agent can do, write your own system prompt, and have full control over everything. More work but more flexibility.

 

A Practical Example - How the Process Work

To understand how all the pieces work together, is useful to look at a typical manufacturing scenario: the weekly shop floor review. In most companies this happen every Monday morning and require the planner to open multiple reports in BC, check production order statuses, compare due dates, look at capacity loads. With a MCP-connected agent, this entire process become a single query.

 

The process work like this. The user send a request to the AI agent asking for the current shop floor situation. The agent then make several calls to BC through MCP: first to the Production Order API to identify overdue or delayed orders, then to the Work Center Capacity API to check for bottlenecks. It combine all this information and return a structured summary that include the late orders with their completion percentage, the work centers that are above 90% utilisation, and the total workload planned for the week.

 

Based on this summary, the user can decide to take action. For example if a production order is late and the related work center is overloaded, the planner may decide to create a new firm planned order to replenish stock from a different source, or to expedite part of the work. This action can be done directly through the agent by providing item number, quantity, due date and location. The agent call the CreateFirmPlannedOrder action in BC, the order is created with BOM lines exploded automatically, and a confirmation is returned.

 

The result is that a process that normally require 30 to 40 minutes of navigation across different BC pages can be completed in few minutes, without the user need to know where to find the data or how to filter it. The agent handle all the data retrieval and the user focus only on the decisions.

 

Final Thoughts

I know that when you first hear about MCP and AI agents it can sound very complicated or maybe not relevant for a small BC implementation. But honestly once you build the first API page and connect it to an agent, you realise its not that difficult and the value for the client is very clear.

 

Manufacturing clients especially they love this because they deal every day with the stress of production delays, capacity problems, quality issues. If you can give them a tool where they just type a question and get an answer... that's something they will use.

 

The pseudocode in this article show you the logic and the design patterns. The actual AL code with everything ready to compile and deploy is on GitHub, please check the link below. I try to comment the code well so its easy to understand and modify for your specific requirements.

 

Next article I will cover how to integrate this with Microsoft Teams for real time alerts from the shop floor. Subscribe at insidebusinesscentral.com if you want to get notified.

 

➤ Full AL source code on GitHub: https://github.com/GmsoftLtd/MCP-Manufacturing-Examples-

 

Comments

Post a Comment

Popular posts from this blog

Understanding Database Indexes in Business Central (and How They Can Help You)

Image
When I first started working with Business Central, the word “indexes” felt too technical for me — like something only developers or database admins cared about. But then I discovered the Database Missing Indexes page . At first, I thought it listed all the indexes that exist in the database. Later, I realized it’s even more interesting: it actually shows the indexes that don’t exist yet, but SQL thinks should be there . That page became a game-changer for me in understanding why some reports and pages are slow, and how I can help point my team toward performance fixes. What Are Indexes, Anyway?  Indexes are like shortcuts. Imagine a giant cookbook with 1,000 recipes. If I want to find every recipe with “chicken,” I don’t flip through each page — I go to the index in the back. Databases work the same way. If I filter a table by Posting Date , an index lets the system jump straight to those rows instead of scanning everything. When no index exists for the filter, the system has to ...
Read more
Image
Dynamics 365 Business Central · Manufacturing · APICS/ASCM Business Central & APICS/ASCM for Manufacturers: A Practical, No‑Nonsense Guide for Consultants, IT Leaders, and Plant Managers By Grigorios Mavrogeorgis · Approx. 15–20 min read Who this is for Business Central consultants who need precise setup guidance. IT decision-makers evaluating ERP fit for manufacturing. Manufacturing managers who want to understand how BC will run their shop—today, not in theory. Table of contents APICS (now ASCM): What It Is and Why It Matters How Closely Business Central Aligns to APICS/ASCM The Three Primary Manufacturing Types—With Real Examples Configuring Business Central for Each Manufacturing Type JIT Manufacturing: Principles and Benefits Implementing JIT in Business Central: A Step‑by‑Step Blueprint End-to-End Configuration Recipes Practical Navigation & Setup Pointers Key Takeaways References 1) APICS (now ASCM): What It Is and Why It Matters APICS...
Read more
  Business Central Costing for Manufacturing — User Manual   Applies to: Microsoft Dynamics 365 Business Central (SaaS & On‑Prem). Screens and labels may vary slightly by version. The concepts are stable across recent versions. Suggested Blogger Labels: Business Central, Dynamics 365, Manufacturing, Costing, Standard Costing, FIFO, Average Costing, Work Centers, Machine Centers, WIP, Variances, Subcontracting, Month-end Close, Reporting 1) What this guide covers A practical, end‑to‑end playbook for setting up costing in Business Central (BC) for manufacturing and allocating costs to work centers and items. It includes: Costing concepts in BC (item costs, capacity costs, overheads, variances) Master data you need (Items, BOMs, Routings, Work/Machine Centers) The minimum viable setup for accurate costing How to allocate costs to work centers and roll them into item costs Posting flows, WIP, and G/L integration Day‑...
Read more