For most of its history, testing Dynamics 365 meant one thing: confirming that a human clicking through a screen got the right result. Wave 1 2026 quietly ended that era. With the rollout of Model Context Protocol (MCP) support across Dynamics 365 Finance, Supply Chain, and Business Central, the ERP is no longer just a system a person operates, it is a system that autonomous AI agents now operate on their own, executing payment runs, reconciling ledgers, and performing data operations without a human touching a form.
That shift creates a testing problem the industry has barely named, let alone solved. When an AI agent inside your ERP makes a financial decision, what exactly are you testing, the screen it never used, or the decision it actually made? This is the question behind D365 MCP testing, and getting it wrong means shipping autonomous agents into your financial system with no real validation behind them.
This article explains what MCP changed in Dynamics 365, why testing these agents is a genuinely new problem rather than old testing scaled up, exactly what D365 MCP testing has to validate, and how Sofy’s outcome-based, MCP-native agents do it.
What MCP actually changed in Dynamics 365
The Model Context Protocol is an open standard, originally developed by Anthropic, which defines a common way for AI agents to access an application’s data and business logic. Instead of building custom, point-to-point APIs for every integration, MCP gives agents a standardized, self-describing set of tools they can discover and call. Microsoft’s Dynamics 365 ERP MCP server brings that capability directly into Finance and Supply Chain.
From assistant to actor
The Copilot of 2024 was an assistant: it answered questions and drafted text, but a human still did the work. Wave 1 2026 moved Copilot into an agentic operating layer that acts. The Account Reconciliation Agent matches sub ledger balances to the general ledger and flags exceptions. The Pay flow Agent executes vendor payment runs within configured parameters. These agents do not suggest, they do. The thing being tested is no longer a user interaction; it is an autonomous decision with a financial consequence.
What the D365 ERP MCP server exposes
Microsoft’s MCP server gives connected agents tools in a few distinct categories, and each one is a surface that has to be validated:
- Data tools, let an agent perform create, read, update, and delete operations directly against D365 data entities. A wrong call here writes bad data straight into your system of record.
- Form tools, let an agent navigate server forms and complete tasks the way a human would, through server APIs that hand the agent the form’s view model as context. This is where multi-step business processes get executed.
- Business-logic access, exposes ERP operations and rules to any MCP-compatible agent, including custom agents built by your own team or partners. Every exposed operation is something an agent can now trigger autonomously.
The practical effect is that any MCP-compatible agent, Microsoft’s own, an ISV’s, or one your team builds in Copilot Studio, can now reach into D365 and act. That is powerful. It is also a large new surface where things can silently go wrong.
Why D365 MCP testing is a genuinely new problem
It is tempting to treat this as more of the same, just point your existing test suite at the new features. That fails, because testing an autonomous agent is structurally different from testing a deterministic UI. Four things make it new.
- The behavior is non-deterministic. A script always does the same thing. An LLM-driven agent given the same goal may reason its way down a different path on different runs. You cannot validate it by asserting on a fixed sequence of clicks, there is no fixed sequence.
- You are testing decisions, not screens. A passing UI test confirms a button worked. It says nothing about whether the Payflow agent paid the right vendor the right amount, or whether the reconciliation agent matched the correct entries. The decision is the thing that matters, and it lives below the interface.
- The blast radius is financial. An agent with CRUD access to data entities and the ability to execute payment runs can cause real, immediate financial damage if it acts incorrectly. The cost of an untested agent error is measured in money moved, not pixels misaligned.
- Guardrails are now part of the system under test. Microsoft built in confirmation steps and permission boundaries so high-risk actions require human approval. Those guardrails are only protective if they actually fire, which means the guardrails themselves have to be tested, not assumed.
The shift in one line Traditional D365 testing asks “did the screen work when a human used it?” D365 MCP testing asks “did the autonomous agent make the correct decision, stay inside its guardrails, and produce the right financial outcome?” Those are different questions, and only one of them is answered by clicking through a UI.
What D365 MCP testing actually has to validate
Concretely, validating an MCP-connected D365 agent means checking five things that a conventional test suite never touched:
| What to validate | The question it answers | Why it matters |
| Tool-call correctness | Did the agent call the right MCP tool with the right parameters? | A wrong data-tool call writes bad data; a wrong form action triggers the wrong process |
| Decision outcome | Did the action produce the correct financial result at the data layer? | The whole point, a paid invoice, a matched ledger, a correct posting |
| Guardrail enforcement | Did high-risk actions stop for human approval as configured? | Confirms the safety boundary actually holds under real conditions |
| Permission scope | Did the agent act only within its allowed operations? | An over-permissioned agent is a financial and compliance risk |
| Audit & explain ability | Is there a field-level record of what the agent did and why? | “The AI said it passed” is not an audit trail auditors will accept |
Notice that none of these are UI assertions. Everyone is about the outcome and the reasoning behind it, which is exactly where script-based and record-and-replay tools have nothing to say.
Why traditional and script-based tools cannot test MCP agents
Record-and-replay tools, including RSAT and the bulk of legacy D365 automation, work by capturing a fixed path through the UI and replaying it. That model has three fatal flaws against an MCP agent. There is no fixed UI path to record, because the agent acts through MCP server tools, not clicks. There is no deterministic sequence to assert against, because the agent reasons its way to the goal differently each time. And there is no outcome validation, because these tools check screen states, not the financial results that MCP agents produce. Pointing a UI-recording tool at an autonomous agent is testing the one layer the agent does not even use.
How Sofy tests D365 MCP workflows
Validating autonomous agents requires a testing approach that is itself built around outcomes and agents, which is precisely how Sofy works. Four capabilities make Sofy fit for D365 MCP testing.
It validates the decision, not the click
Sofy’s D365 agents validate outcomes at the data layer, not UI states. For an MCP-connected workflow, that means confirming the actual result, that the payment run paid the correct vendor the correct amount, that the reconciliation matched the right entries, that a data-tool call wrote the right values to the right entity. Sofy produces field-level assertion logs for each decision an agent makes, which is exactly the artifact that turns an opaque AI action into something an auditor can trust.
It is MCP-native by design
Sofy is not retrofitting MCP support after the fact. Sofy’s own agentic testing platform coordinates its specialist agents through a shared MCP hub, the same standard Microsoft adopted for Dynamics 365. That means Sofy speaks the protocol your D365 test agents now run on, and can validate MCP-driven workflows as a first-class case rather than approximating them through the UI.
It tests the guardrails, not just the happy path
Because Microsoft’s agentic model relies on confirmation steps and permission boundaries for high-risk actions, those boundaries have to be exercised. Sofy’s graduated-autonomy approach maps directly onto this: low-risk validations run and self-report, while high-risk financial steps are explicitly checked to confirm the human-in-the-loop gate fires and the agent cannot act beyond its allowed scope. The safety net gets tested as rigorously as the function.
It self-heals through the waves that keep changing the agents
These MCP capabilities are arriving in preview and will keep evolving across release waves. Sofy’s agents heal at the workflow level, so when Microsoft reshapes an agent, a form, or a tool definition, validation re-routes to the same intended outcome instead of breaking. Your D365 MCP testing keeps pace with a target that is changing every six months, without a maintenance team chasing it.
How to get started with Dynamics 365 MCP Testing?
You do not need to validate every agent on day one. A sensible sequence for teams adopting MCP-connected D365 agents:
- Inventory what your agents can do. List every MCP tool and operation each agent is permitted to call, this defines your true test surface.
- Start with the highest-blast-radius agent. Payment and reconciliation agents move money and touch the GL; validate those decisions and their guardrails first.
- Assert on outcomes, not paths. Define the correct financial result for each scenario and validate against it at the data layer, so non-deterministic reasoning does not produce false failures.
- Test the guardrails explicitly. Confirm high-risk actions stop for approval and that agents cannot exceed their permitted scope.
Done this way, D365 MCP testing stops being a blind spot and becomes what it should be, the control that lets you deploy autonomous agents into your ERP with confidence rather than hope.
Frequently asked questions
What is D365 MCP testing?
D365 MCP testing is the practice of validating the AI agents that interact with Dynamics 365 through the Model Context Protocol (MCP). Rather than testing UI screens, it validates the decisions and actions these autonomous agents take, confirming they call the right tools, produce the correct financial outcomes at the data layer, stay within their permitted scope, and respect human-approval guardrails.
What is the Model Context Protocol in Dynamics 365?
The Model Context Protocol is an open standard that gives AI agents a common, self-describing way to access an application’s data and business logic without custom APIs. Microsoft’s Dynamics 365 ERP MCP server uses it to expose data tools (CRUD on data entities), form tools (navigating server forms), and business-logic operations to MCP-compatible agents in Finance and Supply Chain.
Why can’t I test D365 AI agents with RSAT or my existing automation?
Record-and-replay tools like RSAT capture and replay a fixed path through the UI. MCP agents do not use a fixed UI path, they act through MCP server tools, reason their way to a goal differently on each run, and produce outcomes below the interface. There is no deterministic click sequence to record and no UI assertion that confirms a financial decision was correct, so UI-recording tools cannot meaningfully validate them.
What does an autonomous D365 agent actually do that needs testing?
Wave 1 2026 agents act rather than advise. The Account Reconciliation Agent matches subledger balances to the general ledger and flags exceptions; the Payflow Agent executes vendor payment runs within configured parameters; data tools let agents create, read, update, and delete D365 records. Each of these is an autonomous action with a financial consequence that must be validated for correctness, scope, and guardrail compliance.
How does Sofy test MCP-connected D365 agents?
Sofy validates outcomes at the data layer rather than UI states, producing field-level assertion logs for each agent decision, confirming the correct vendor was paid, the right entries were reconciled, or the right data was written. Sofy is MCP-native (its own testing agents coordinate through a shared MCP hub), tests guardrails and permission scope explicitly through a graduated-autonomy model, and self-heals at the workflow level so validation keeps pace as Microsoft updates the agents across release waves.
Validate the AI Agents Running Inside Your D365
Sofy’s MCP-native agents test the decisions your Dynamics 365 agents make, at the data layer, with field-level audit logs and guardrail checks. Not the screens. The outcomes.
