Skip to content

Step 1 — Add Base BC Code

Before your agent can make good design decisions, it needs to see how Business Central actually works. Not guess. Not hallucinate. Read the source code.

When you ask an agent "how should we implement cars for rental in BC?", the quality of the answer depends on whether the agent can actually look at how BC handles assets, items, and service objects under the hood. There are two ways to give it that access.

Give the agent the actual AL source of the entire Business Central codebase — Base Application, System Application, and all modules. Implementation, events, triggers, the whole working code.

Microsoft publishes the full BC application source on GitHub as BCApps — System Application, Business Foundation, Base Application, first-party apps, and the developer tools. Same code Microsoft builds from.

We'll mount it into your workspace as a git submodule.

There are symbol-based MCPs — Stefan Maron's AL Dependency MCP and Microsoft's AL MCP — that point the agent at the .alpackages/ symbol files. Symbols give the agent object names, field lists, procedure signatures, and return types. But they don't give source code. You can see what exists in BC, not how it works.

We'll wire these up later in the workshop. They're useful for fast lookup, compilation and testing, but for high-level architectural design they're not enough on their own.

What's a git submodule?

A submodule is a way to embed one git repository inside another, without copying its files into your repo's history.

  • The base BC code lives in its own repo on GitHub. You don't fork it. You just point at it.
  • Locally, the files appear in external/BCApps/ so your agent (and your IDE) can read them like any other folder.
  • In your repo, all that's tracked is a small pointer: "this folder is repo X at commit Y on branch Z". A few hundred bytes.
  • Your remote stays small. Other people who clone your repo can pull the submodule on demand.

The base BC code is huge. A submodule lets you have it locally for your agent without bloating your project repo or git push-ing thousands of files you didn't write.

One-time setup

You only do this once. The submodule sticks with the repo from now on.

Add the submodule

Run these commands from the repo root.

1) Clone shallow (latest main only)

git clone --depth 1 https://github.com/microsoft/BCApps external/BCApps

2) Register the folder as a submodule

git submodule add --force https://github.com/microsoft/BCApps external/BCApps

3) Persist shallow behaviour

git config -f .gitmodules submodule.external/BCApps.branch main
git config -f .gitmodules submodule.external/BCApps.shallow true

4) Commit

git add .gitmodules external/BCApps
git commit -m "Add BCApps submodule (main, shallow)"

5) Verify

git submodule status
git config -f .gitmodules --get-regexp submodule.external/BCApps

6) If you need to clean a previous failed attempt

git submodule deinit -f -- external/BCApps 2>$null
git rm -f external/BCApps 2>$null
Remove-Item -Recurse -Force ".git\modules\external\BCApps" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "external\BCApps" -ErrorAction SilentlyContinue
Remove-Item ".gitmodules" -ErrorAction SilentlyContinue

If you cloned the repo and the submodule folder is empty

Submodules are not downloaded automatically on git clone. Run this once after cloning:

git submodule update --init --recursive

This pulls the BC source at the exact commit the submodule points to.

Add it to your workspace

Open workshop.code-workspace and add the new folder so your IDE and agent see it side-by-side with app/ and test/:

{
    "path": "external/BCApps"
}

Watch it in action

Once the submodule is in place and visible in your workspace, the agent has eyes on real BC code. You're ready to use that to design the extension.

Step 2 — Add Microsoft Learn MCP →