Business Central AI Snapshot Debugging: Capture Production Errors Through MCP

The roadmap entry says the item is Launched for General Availability on the Web platform in the Worldwide (Standard Multi-Tenant) cloud, with a GA date of October 2026. Microsoft's own technical documentation tells a more cautious story, which is covered below.

What the feature actually does​

Microsoft Learn puts it simply: instead of using the keyboard-shortcut workflow, you can use an AI agent to capture a snapshot through the Snapshot Debugging MCP server. You describe the failing scenario, the agent initializes a snapshot session, you reproduce the problem, and the agent collects the recorded snapshot. You don't need to press F7/Alt+F7 or edit a snapshot launch configuration.

This is not a new debugger, and the AI doesn't diagnose anything at this stage. The MCP server uses the same snapshot engine described earlier in this article, so how snapshots are initialized, recorded, and finalized is unchanged. The agent drives the existing tool. It doesn't replace it.

The server gives the agent three tools, and each one matches a step in the manual workflow:

Microsoft's documentation explains why the arming step matters: there's usually no session yet - the server records the next session that reproduces the scenario. After the agent says the recording is armed, you reproduce the problem yourself, or the affected user does. If a relevant session is already running, you can give the agent its session ID and it attaches directly instead of waiting.

In short: you get the familiar snapshot debugger, now operated by an agent. You still have to reproduce the problem and read the trace.

Telling the agent what to record​

Every input to the initialize tool is optional. The agent turns your plain-English request into these settings:

• Snappoints: specific AL lines to record. Each snappoint names an object type (for example Codeunit, Page, Table or Report), the object's ID or its name, and a line number counted from the start of the object. Microsoft's example puts a snappoint on line 100 of codeunit 80, "Sales-Post." AL runtime errors are always captured automatically. You only add snappoints when you also want to record lines that don't throw an error.
• Client type: WebClient is the default. The alternatives are WebServiceClient, Background and ClientService. If you tell the agent the error happens through a web service, it should arm the recording for WebServiceClient.
• Target user: the user's security ID (a GUID). Leave it out and the agent records your own next session.

A minimal prompt works. Something like "Snapshot-debug why posting a sales order fails" falls back to your own next web client session and relies on the automatic error capture. A fully specified prompt names the client type, the user's security ID, the codeunit and line, and asks the agent to say when it's ready for you to reproduce the problem. The more specific the prompt, the better the chance of recording the right session on the first try.

Setting it up​

The snapshot tools are part of the Business Central MCP server, the same server that exposes API pages to agents. They run through ALTool's launchsnapshotmcpproxy command. ALTool is a .NET tool, so it's a one-time install:

dotnet tool install --global Microsoft.Dynamics.BusinessCentral.Development.Tools

The setup depends on your MCP host:

1. Visual Studio Code (agent mode): nothing to configure. The AL extension registers the Business Central Snapshot MCP Server automatically and takes the connection from your launch.json. Run AL: Sign in to Business Central Snapshot MCP when prompted, then ask the agent to capture a snapshot.
2. Claude CLI or GitHub Copilot CLI: register ALTool as a stdio MCP server and pass the target (cloud environment type and name, plus tenant, or on-premises server details) as arguments. For the Copilot CLI, the entry goes in ~/.copilot/mcp-config.json.
3. Cloud authentication: Microsoft recommends signing in interactively with altool auth login, which caches a token and a refresh token that the proxy reuses automatically. For headless or CI/CD use, you can supply a Microsoft Entra access token through BC_ACCESS_TOKEN. That token lasts about an hour. Microsoft also warns that BC_ACCESS_TOKEN overrides the cached sign-in, so an old value left in the environment will break the connection.
4. On-premises: UserPassword authentication reads BC_SERVER_USERNAME and BC_SERVER_PASSWORD from the environment. Windows authentication uses the current Windows identity.

The proxy has no command-line options for credentials, so secrets can't leak into arguments. Reference environment variables rather than hard-coding values into config files.

Permissions: the extra requirement​

Microsoft states that the agent connects by using your Business Central identity and acts entirely within your permissions. Every action is audited under your user, just like the manual workflow. The checklist:

• The Business Central MCP server must be enabled for the environment.
• You need the D365 Snapshot Debug permission set, the same one the manual workflow uses.
• You also need D365 ATTACH DEBUG for every snapshot, including your own session. The manual workflow only requires it when you target another user. Without it, the request is denied.

That last point is the most likely cause of a first-day "access denied." Admins who assign permission sets should plan for it before developers start testing.

Time limits and lost recordings​

The agent workflow has the same time limits as the manual one:

• An armed session closes if nothing attaches within 30 minutes.
• A started snapshot must be finished within 10 minutes.
• If the environment moves or restarts before the recording stops, the recording is lost. The fix is to arm a new snapshot and reproduce the problem again.

In practice, have the person who will reproduce the problem ready before you arm the recording. Getting someone to reproduce a bug can take a while, and 30 minutes goes quickly.

Privacy: snapshots contain real data​

The snapshot the agent collects is the same recording you would produce manually, and it can contain customer privacy data. Handle it according to your privacy and compliance policies and delete it when it's no longer needed. Capturing production failures is the whole point of the feature, so treat these archives as sensitive data from the start. Decide who can open them, where they're stored and when they're deleted.

There's also a long-standing caveat that applies to snapshot debugging in general. Your local symbols must match what's deployed on the server, or the source lines you see can be wrong. Any code that contains snappoints must also be deployed. An agent can't fix either problem for you.

Preview or GA?​

The roadmap entry says Launched, with GA in October 2026. The Microsoft Learn page says the feature applies to Business Central 2026 release wave 2 and later, but its note adds that this feature is available in preview with a prerelease of runtime 18 and Business Central Server version 29. The two statements may simply reflect documentation trailing the release, but they don't match yet. Check your environment's server version and AL runtime before promising stakeholders a production workflow this month.

How this fits with Microsoft's other AL debugging tools​

This feature fills a gap between two tools Microsoft already ships:

• Troubleshooting MCP Server (2026 release wave 1): works inside an active debugging session. Microsoft documents that it enables GitHub Copilot to programmatically access stack frames, variables, source code, and breakpoints to help diagnose issues, but it needs a live Visual Studio Code debug session to work with.
• The al_snapshotdebugging agent tool: in AL Language extension 17.0 and later, it runs in Visual Studio Code only. Microsoft notes that the related debugging tools are available only in Visual Studio Code (not in the AL MCP Server), because they interact directly with the Visual Studio Code debugger and Problems panel.
• The new snapshot MCP path: runs through ALTool as a standalone stdio server. It works from Visual Studio Code, the Claude CLI or the GitHub Copilot CLI, and Microsoft documents a token-based option for CI/CD.

Community coverage sees the bigger pattern. Writing about the Business Central 29 preview, Sulav Raj Thapaliya noted that through ALTool and MCP, an AI agent can work with performance profiling and snapshot debugging information. He described a likely support loop of capturing the snapshot, letting AI analyze it, and having a developer confirm the root cause. He also offered a fair warning: giving an AI agent broad Business Central permissions simply because it is technically possible would be a poor architecture.

Who benefits, and the limits​

The clearest winners are partner support teams and ISVs that deal with failures they can't reproduce outside a customer's tenant. Being able to say "arm a recording for this user's next web service call" without opening a launch configuration lowers the bar for using snapshot debugging. Many AL developers have avoided it because setup was fiddly.

It does have limits. It won't fix code, it won't guarantee you find the root cause, and it won't reproduce the bug for you. Its D365 ATTACH DEBUG requirement is actually stricter than the manual path. It also gives an agent, acting under a human's identity, the ability to record production sessions full of business data. That's reasonable if the permissions are scoped carefully, and risky if they're handed out broadly.

Bottom line: Microsoft has turned a three-step snapshot procedure that relied on keyboard shortcuts into a conversation with an agent, without changing the underlying engine. Before rolling it out:

• Confirm your version is supported.
• Assign both permission sets.
• Enable MCP for the environment.
• Line up whoever will reproduce the problem before the 30-minute window starts.
• Delete snapshots once the investigation is done.