What Shipped

Business Central 2026 wave 1 introduced the Troubleshooting MCP Server for AL, an AI-powered debugging tool that’s generally available for Business Central 2026 release wave 1 and later. It’s a narrow, well-scoped feature: while a debug session in Visual Studio Code is paused at a breakpoint or a runtime error, GitHub Copilot can query the live execution state through four dedicated tools instead of a developer manually clicking through the Locals panel frame by frame.

Microsoft’s own framing is precise about what this is and isn’t. It’s not static code analysis — the server only activates during an active, paused debug session, and it has no visibility into anything before or after that pause point.

The Four Tools

Per the official documentation, the Troubleshooting MCP Server exposes:

  • Get Stack Frames — the complete call chain: method names, object IDs and types (Codeunit, Page, and so on), line numbers, and which app each frame belongs to.
  • Get variables — local and global variables for a specific frame, including nested Record and DotNet children, taking a frame ID as parameter (0 = current frame, 1 = direct caller, and so on up the stack).
  • Get source code — the source for a given frame, including system or framework codeunits, without leaving the chat to hunt for the file.
  • Add breakpoint — programmatic breakpoint placement by object ID, object type, and line number, letting Copilot act on a hypothesis it just formed from the other three tools.

The prerequisites are minimal and explicit: an active VS Code debug session paused at a breakpoint or error, the AL Language extension installed, and GitHub Copilot Chat enabled. No additional configuration — the server activates automatically the moment execution pauses.

What It’s Built For, According to Microsoft’s Own Guidance

The documentation is unusually direct about scope. It recommends the Troubleshooting MCP Server for complex call stack analysis, correlating variables across multiple frames, pattern detection in error scenarios, and test failure analysis — and explicitly recommends against it for simple single-step investigations, or as a replacement for interactive step-through debugging when a developer is still learning a code path for the first time.

That distinction matters more than it might look. A shallow bug — one frame, one obviously wrong value — doesn’t benefit from natural-language querying; describing the problem to Copilot takes longer than just reading the Locals panel. The stated sweet spot is deeper: call stacks five or more frames deep, or a value that gets transformed across several codeunits before it’s wrong, where manually tracking state across frames is where debugging time actually goes.

The comparison table Microsoft publishes alongside the feature is worth reading directly rather than summarizing, because the gaps are as informative as the capabilities: the server can retrieve variables and stack frames and set breakpoints programmatically, but it cannot step through code, cannot watch expressions, and — critically — cannot go back in time. It’s frame-based and session-bound. If the corrupting write happened three calls before the current pause point, the Troubleshooting MCP Server has no way to reconstruct it; Microsoft’s own related-information links point to snapshot debugging for that class of problem instead, which captures execution traces (including from production) for offline replay.

Reading the Documentation as an AL Developer

What’s notable here isn’t that Copilot can read variables — any debugger can show a variable’s value. It’s that a coding agent can now correlate state across frames on request, in natural language, without a developer manually re-deriving the call sequence each time. For a bug shape most AL developers will recognize — a loop over Sales Line records where one iteration behaves differently from the others — that’s the tedious part of debugging: not spotting that something’s wrong, but tracking exactly which call, on exactly which iteration, produced the value that made it wrong.

The tool most likely to get underused here is Add breakpoint. Most “AI debugging” framing stops at “the AI explains your error.” This one closes the loop: once Copilot has formed a hypothesis from the stack and variable data, it can act on it by placing a breakpoint further up or down the chain — without the developer leaving the chat to click in the gutter.

Microsoft’s guidance also includes an explicit caution worth repeating rather than glossing over: verify the findings. The server returns raw data — variable values, frame sequences, source snippets — and Copilot’s interpretation of that data is not guaranteed correct just because the retrieval was programmatic. Treating its output as ground truth without checking that the frame sequence makes sense and the source matches the actual repository version is exactly the failure mode the documentation warns against.

Where This Fits

This isn’t a replacement for knowing how to read a call stack — nothing here changes what AL debugging fundamentally requires. What it changes is who does the bookkeeping: instead of a developer manually noting variable values across six frames to confirm a hypothesis, that retrieval is now something Copilot can be asked to do directly, scoped to exactly the frames in question.

For teams migrating complex NAV customizations or maintaining extensions with deep call chains across multiple published apps, that’s a meaningful reduction in the mechanical part of debugging — not the diagnostic part, which still requires understanding the domain and the code. Worth reading the full documentation before reaching for it on the next multi-codeunit bug, particularly the frame ID model and the limitations section — both are easy to misread from a feature announcement alone.

Questions or a different reading of this feature? Reach out via LinkedIn or X.