MCP servers have radically changed how LLMs interact with resources outside their training data, and developers are already relying on them to get dramatically better results. But what if you are not a developer and still want to make use of them, but don’t want to install “developer stuff” on your machine? Or if you can’t or don’t want to install those MCP servers locally (and there are very good reasons for not doing that, more on that in a later blog post)? I’ll show you a setup which solves that problem. My scenario is that of a product manager working with Microsoft Dynamics 365 Business Central (BC). The code and user stories live in Azure DevOps, but that could easily also be GitHub and Jira or whatever you use. We will use the Azure DevOps MCP server as well as the AL Symbols MCP server.

The TL;DR

To just give it a try, go to https://github.com/tfenster/codespace-mcp, fork the repo and create a codespace through the “Code” action in the top right

Screenshot of the code action extended and the + action to create a codespace

Then you need to run az login in a terminal to connect to your Azure account. If you also want to interact with the structures of Business Central, you need to run the AL: Download symbols action or put other extensions you might want to reference into the .alpackages folder. Now all that is left to do is to start the MCP servers by opening the .vscode/mcp.json file and clicking on the “start” action. The Azure DevOps MCP will ask for the name of your organization, while the AL symbols MCP just starts.

screenshot of mcp.json showing the "start" action

With that in place, you can use GitHub Copilot to ask a question like “check work item 33 in project mcp-demo. Can you find any functionality in the AL symbols found in my workspace that would help me fulfill the requirement?” Work item 33 in my example is actually quite bad, it only has “We want the customers to be categorizable. The available categories shall be A, B and C” as description. Also the prompt isn’t great, but that’s not the point I want to make here. Copilot now does things like this:

I’ll help you check work item 33 and find relevant AL symbols in your workspace. Let me start by fetching the work item details.

Fetched work item 33 from mcp-demo project
Ran wit_get_work_item - azdo (MCP Server)
Searched for Customer-related objects in workspace

Now let me search your workspace for AL objects related to customers and categorization:

Ran al_packages - al-symbols-mcp (MCP Server)
 Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content from specified lines
Ran al_get_object_definition - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed 3 files
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content.json, lines 1 to 200
Ran al_search_objects - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content.json, lines 1 to 100

Summary: Work Item 33 Analysis

Requirement: “New customer categorization - We want the customers to be categorizable. The available categories shall be A, B and C”

Relevant AL Functionality Found in Your Workspace:

1. Customer Table (ID 18, Base Application)

  • Main table for customer data in your Dynamics 365 Business Central system
  • Currently has fields for classification, customer groups, and other metadata
  • This is the primary table you’ll need to extend to add categorization

2. Enum Pattern Examples Your workspace contains several enumeration patterns you can reference:

  • User Plan Experience (ID 9005) - Shows multi-value enum structure (Basic, Essentials, Premium, Other)
  • No. Series Implementation (ID 397) - Simpler two-value pattern
  • These demonstrate the standard syntax for creating choice fields

3. Table Extension Pattern

  • Serv. Customer Templ. (TableExtension ID 6451) shows how to extend the Customer Template table
  • Demonstrates field definitions with proper properties like Caption, DataClassification, and TableRelation
  • This pattern can be followed to add categorization functionality
  1. Create an Enum for customer categories with values A, B, and C
  2. Extend the Customer Table using a TableExtension to add a new field for the category
  3. Add UI controls (likely in a Customer page extension) to allow selection between the three categories
  4. Use standard properties: Caption, OptionString/OptionMembers, and DataClassification

The enumeration and table extension patterns already exist in your system, so you can follow those established conventions for a consistent implementation.

Is this the most astonishing use of AI or the best solution for the requirement? Both definitely not. The point is something different: Copilot interacted with Azure DevOps (e.g. Ran wit_get_work_item - azdo (MCP Server)) and the AL extensions in the folder (e.g. Ran al_get_object_definition - al-symbols-mcp (MCP Server) or Ran al_search_objects - al-symbols-mcp (MCP Server)) to find answers to the question we ask. Without having to install anything potentially harmful locally. So if you struggle to provide GitHub Copilot with the right context and information to work on your requirements, this might be an easy way to make you faster, more efficient and provide higher quality to whoever has to pick up your requirements.

The details: Other interactions you might like

Other interactions with your content could be the following:

“what are acceptance criteria I might want to add to that work item”
After a bit of back and forth you will probably get a suitable list. Now you could try “please directly add them to the work item” and a call like Ran wit_update_work_item - azdo (MCP Server) would improve your work item like this

Screenshot of acceptance criteria in the Azure DevOps work item

“what are other aspects i need to think about when validating this requirement”
This time, Copilot didn’t use any of the MCP tools, but came up with topics like business semantics, lifecycle rules, backward compatibility & migration, UI & usability, data quality controls, process impact, reporting & analytics, security & compliance, non-functional & operability and edge cases. Maybe not all of them are relevant, but certainly a good idea to think about those aspects briefly

“which standard features could I use to meet the requirement without coding”
Here Copilot again interacted with my local symbols

Ran al_search_objects - al-symbols-mcp (MCP Server) (did that 4 times)
Reviewed content.json, lines 1 to 80
Ran al_get_object_summary - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Now let me get the full list of Customer table fields to identify what grouping/classification fields already exist.
Ran al_get_object_definition - al-symbols-mcp (MCP Server)
Ran terminal command: cat "/home/codespace/.vscode-remote/data/User/works...
 Reviewed content from specified file

Good picture from the field list. Now I can give you a thorough, grounded answer based on what’s actually in your BC symbols.

Here are the standard BC features that could meet the requirement without any AL coding, ranked by fit:

Best fit — Dimensions

Global Dimension 1/2 Code (fields 16/17) or an additional dimension:

  • Create a new Dimension (e.g. CUST-CATEGORY) with Dimension Values A, B, C.
  • The Customer Card has a Dimensions action out of the box.
  • Filtering by dimension value works natively in Customer List, and in all standard reports.
  • Values are validated against the Dimension Values table, so only A/B/C are possible.
  • Limitation: the category doesn’t appear as a direct column on the Customer Card/List; it lives behind the Dimensions action, which may not match the business’s UX expectation.

Good fit — Customer Price Group (field 23, Customer Price Group table)

  • Create three Price Groups named A, B, C.
  • The field is already visible on the Customer Card (Invoicing FastTab).
  • Supports list filtering and look-up.
  • Limitation: semantically tied to pricing — if the business assigns it a non-price meaning it can cause confusion, and it may interfere with price calculation logic.

Reasonable fit — Territory Code (field 15, Territory table)

  • Create Territories A, B, C.
  • Already present on the Customer Card.
  • No strong semantic tie to other BC processes.
  • Limitation: Territory has its own reporting context (sales by territory) — reusing it for categorization pollutes that.

Possible fit — Customer Disc. Group (field 34, Customer Discount Group table)

  • Create discount groups A, B, C.
  • Visible on Customer Card.
  • Limitation: semantically tied to discount rules — same confusion risk as Price Group.

Limited fit — Statistics Group (field 26, Integer)

  • An integer field for segmenting customers in statistics.
  • Validated by being an integer — you could use 1=A, 2=B, 3=C.
  • Limitation: not user-friendly (shows numbers, not A/B/C labels), not directly filterable by label, and the field is often hidden in standard page layouts.

Summary recommendation

Option Label visible Direct card field Clean semantics Validated values
Dimension ✗ (behind action) ✗ ✓ ✓
Customer Price Group ✓ ✓ ✗ ✓
Territory Code ✓ ✓ ✓ (neutral) ✓
Customer Disc. Group ✓ ✓ ✗ ✓
Statistics Group ✗ (integer, hidden) ✓ (hidden) ✓ ✗

If the business can accept a slightly repurposed field: Territory Code is the cleanest no-code option — it’s neutral, already on the card, and supports A/B/C values with validation.

If UX purity matters (the field should be called “Customer Category”): none of these fully satisfy the requirement without at least a minor configuration step — you would need AL code to add and properly label a new field, or use Dimensions and accept the UX trade-off.

Do I agree with all of this or does it even all make sense? I would say there are very good arguments to immediately dismiss some of them and basic BC knowledge would probably get you further. But imagine you are in a situation where you have an ISV solution that you don’t fully know or have limited documentation, but only the symbols. Or you just want to validate that you haven’t missed anything obvious. Then this could be a very helpful starting point.

“do i have any conflicting requirements in my backlog”

For this, Copilot looked at my backlog and identified a conflicting requirement

Let me pull the full backlog to check all work items against this requirement.

Ran wit_list_backlogs - azdo (MCP Server)
Ran wit_list_backlog_work_items - azdo (MCP Server)
Ran wit_get_work_items_batch_by_ids - azdo (MCP Server)

Yes — there is a direct conflict. Your backlog has two work items that describe the same feature with incompatible specifications:

  Work Item 33 Work Item 34
Title New customer categorization New customer categories
Categories A, B, C Silver, Gold, Platinum
State New New

They are describing the same thing — a customer categorization field — but with different value sets. Implementing both would mean two overlapping classification fields on the customer, or one implementation that has to be changed right after the other is delivered.

This needs a decision before any code is written:

  1. Are these the same requirement? If so, one should be closed as duplicate and the surviving one updated with the agreed value set (A/B/C labels, or Silver/Gold/Platinum, or perhaps both — e.g. A=Silver, B=Gold, C=Platinum).
  2. Are these intentionally different fields? If the business wants both a tier label (Silver/Gold/Platinum) and a separate internal code (A/B/C), both IDs and field names need to be distinct and each work item should be clarified accordingly.

Would you like me to link them as duplicates, add a comment flagging the conflict, or update one of them?

This obviously was an easily identifiable one, but again, imagine yourself in a situation with a lot of requirements, potentially from a time when you weren’t working with a particular product where it might not be that easy to spot duplicates. Running it through Copilot could be highly valuable.

I hope this gave you some ideas about how to use the Azure DevOps and AL MCP servers to interact with and improve your requirements. And as mentioned in the beginning, even if you use a different toolset, by now chances are quite high that you can access it through an MCP server.

The details: Setup and configuration

If you are still following along and are techie enough to care about the technical setup, it is based on two files: devcontainer.json defines the container that makes up the Codespace:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "name": "MCP Codespace",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "20"
    },
    "ghcr.io/devcontainers/features/azure-cli:1": {}
  },
  "postCreateCommand": "npm install -g @azure-devops/mcp",
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-dynamics-smb.al"
      ]
    }
  }
}

You can see that Node.js is added as a feature (lines 4-6) because we need that for the MCP servers. You also see the Azure CLI (line 7) needed for the authentication against Azure DevOps. Next, the installation of the Azure DevOps MCP server happens after the container is created via line 9 and last but not least, the VS Code AL extension is added via lines 10-16.

The MCP servers are configured in mcp.json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "inputs": [
    {
      "id": "azdo_org",
      "type": "promptString",
      "description": "Azure DevOps organization name (e.g. 'contoso')"
    }
  ],
  "servers": {
    "azdo": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "${input:azdo_org}", "-d", "core", "work", "work-items", "test-plans"]
    },
    "al-symbols-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["al-mcp-server"]
    }
  }
}

Lines 2-8 define one input, in this case the Azure DevOps organization, which is later used in line 13 as part of the configuration of the Azure DevOps MCP Server (lines 9-14). Very similarly, the AL symbols MCP server is configured in 15-20. Pretty simple and straightforward, with the only exception maybe the configuration of the modules of Azure DevOps that you want to make available in line 13 as well. In this case, only the core, work, work-items and test-plans modules are activated.