What happens to my ERP agent on 1 October 2026?

If it is built on the original static Dynamics 365 ERP MCP server, Microsoft retires it that day. MCP (Model Context Protocol) is the open standard that lets an AI agent discover and call functions in an external system; ERP (enterprise resource planning) here means Dynamics 365 Finance and Supply Chain Management.

Microsoft's instruction is direct: use the dynamic server "to avoid disruption when the static server is retired". That move is not a configuration change or a connector swap. It is a rewrite of how the agent thinks about the ERP.

6 minute read.

The dated facts

What it is — The original static Dynamics 365 ERP MCP server, "built on the Dataverse connector framework", with 13 tools for specific Dynamics 365 Finance and Supply Chain Management functions (Microsoft Learn)
Where it came from — "At Microsoft Build 2025, the Dynamics 365 ERP Model Context Protocol (MCP) server was introduced" (Microsoft, 11 Nov 2025); public preview 19 May 2025 (2025 wave 2 plan)
Status — [DEPR] — deprecated: Microsoft has published a retirement date and tells you to move off it
**Retirement — 1 October 2026.** "This static server will be retired on October 1, 2026" (Microsoft Learn)
Microsoft's stated reason — "limitations in the server's scale and extensibility" (Microsoft Learn)
Where you go — The dynamic Dynamics 365 ERP MCP server, [GA] — generally available, safe to build on — since 27 January 2026 (2025 wave 2 plan)

We are deliberately not publishing the names of the tools the static server exposed. Microsoft documents that there are 13 and does not name them; the versions circulating in community posts are not something we will restate as fact. If you are on it, your own agent configuration tells you which ones you use.

Why this is a rewrite and not a port

It comes down to a difference in what a tool is.

The static server exposed named business functions — Microsoft's phrasing is 13 tools that "enable specific business functions". A tool corresponded to a recognisable ERP operation, and the agent's job was to pick the right one and fill its parameters. The vocabulary was small.

The dynamic server exposes generic primitives: find an entity type, get its metadata, query, create, update, delete, find a menu item, open it, find controls, set values, click, save, find an action, invoke it (Microsoft Learn).

Microsoft's own framing: "Rather than having static tools for specific actions […] the agent uses the tools to open forms, set field values, and select actions available on the form." The business function is now something the agent composes, guided by instructions.

That relocates the intelligence. On the static server it sat in a fixed catalogue — Microsoft's blog calls it "a static implementation with a curated set of 13 tools". On the dynamic server it sits in your agent instructions, which Microsoft tells you to update as you test.

The compensation is real. The dynamic server lets an agent "perform nearly any function that's available to a user through the application interface, without the need for custom code, connectors, or APIs", and extensions and personalisation are "automatically available for agents to access". Microsoft has also stated the direction — about the protocol, note, not that one server: "All new ERP agents will be built using MCP."

What actually has to be rebuilt

**Instructions** — From "call this named function" to a composed sequence over primitives, including the discovery step that finds the entity or menu item first. Microsoft ships a starter instruction block and tells you to update it as you test (Microsoft Learn)
**Failure handling** — The failure modes come with the abstraction. Microsoft's own starter instructions cap form state — "A tool call response can include up to 25 rows of data as form state. Generate a warning if the form state contains 25 rows of data" — and rule out the fallback read: "When instructed to create new data, and the creation fails, DO NOT retrieve existing data instead" (Microsoft Learn)
**Security scoping** — The security role is the API surface. "The security role of the authenticated user for the agent determines which objects are returned in the view model" (Microsoft Learn). A role that fitted a fixed function list is not automatically the right shape for a compositional agent
**Testing — Our position, not Microsoft's.** The agent's working contract is the form and entity layout it composes against, so agent regression tests belong in the release pipeline rather than in a one-off acceptance script

That last row is ours and we will own it. Microsoft does not say that a form change breaks an agent, and does not require agent regression testing anywhere we can cite.

Here is the documented ground it stands on. Of the static server, Microsoft says "the set of available tools was fixed, updates required code changes or redeployments". Of the dynamic server, Microsoft says it "dynamically updates the context it provides to the agent with each tool call based on the agent's security permissions and application configuration, extensions, and personalization".

Our inference — and it is an inference — is that the stability which used to live in a fixed catalogue now lives in your own change control. We treat agent regression testing as an application-lifecycle discipline rather than a project task.

How to tell whether you are affected

Two checks, both quick.

Look at your agent's tool list in Copilot Studio. Microsoft's steps are Tools → Add a tool → the Model Context Protocol filter → search for and select Dynamics 365 ERP MCP. The same page notes you can also select a server that "contains 13 static tools for specific actions in Dynamics 365 Finance and Supply Chain Management" — that is the retiring one.
Check when the agent was built. The release plan records public preview for building agents with MCP on 19 May 2025 and general availability of the expanded server on 27 January 2026 (2025 wave 2 plan). Anything wired up in between is a candidate.

If you built after general availability and selected the dynamic server deliberately, you are not affected. Confirm rather than assume: Microsoft's own build guidance has to warn about the second entry, which tells you how easy it is to pick.

The October dates — what is committed, and what is an example

The retirement is committed. Microsoft states it flatly: "This static server will be retired on October 1, 2026" (Microsoft Learn).

The release-wave dates around it are not. Microsoft's release schedule defines wave 2 as "features releasing from October through March", and presents October 1 in a table of example dates "for the two release waves in any given calendar year" (Microsoft Learn). The only key-dates section on that page is 2026 release wave 1, and Microsoft's note says the dates "vary across Dynamics 365 apps, and can also vary across capabilities".

The 2026 wave 2 plan is not published either — the release plans hub lists 2026 wave 1 as the latest wave (Microsoft Learn). Nobody can tell you today what else arrives that month, and anyone quoting a 2026 wave 2 feature is quoting a rumour.

Two practical consequences. Your change-freeze calendar probably already has early October marked, which argues for finishing well before it rather than into it. And an unpublished wave plan is not a reason to wait — it is a reason to be finished before it lands.

The counter-argument

"We will handle it when we upgrade. It is one platform change among several and we batch these."

That works for a configuration change. It works badly here, for a scheduling reason rather than a technical one.

The migration is a rewrite of instructions, plus failure handling, plus a review of the security role. That needs iteration time — the work is not "apply and verify", it is "rebuild, observe behaviour, correct, repeat". Batching it into an upgrade window means discovering that on the day.

There is a fairer version of the objection: if your agent is a low-stakes read-only assistant, the consequence of it degrading is small and waiting is rational. Make that decision explicitly rather than by default — and know that read-only agents are exactly the ones nobody remembers are running.

What to do this week

Open your agents in Copilot Studio, filter the tool list for Model Context Protocol, and record which entry each agent uses. It is a ten-minute inventory and it is the input to everything else here.
For any agent on the static server, put the rewrite in the plan with a date well before the retirement, not against it.
Read your current agent instructions with the composition question in mind: for each named function the agent calls today, what sequence of primitives replaces it? That list is the scope of the rewrite.

Where we would draw the line

We would not build anything new on the static server today, at any level of urgency. A dated retirement makes that a decision to throw work away.

We would not schedule this migration into the same window as a release-wave update. Both need attention, and one of them is a behavioural rewrite.

And we would not treat the migration as done when the agent runs. It is done when it has been observed handling the failure modes the abstraction introduces — a different and later milestone.

One more line, because it is the reason we work this way. Dynamics is your system of record and we do not touch its core. We build companion apps that optimize the decision the ERP records — the reorder point, the pick path, the price on the line — in tandem with the ERP and with whoever implements it, on the same Power Platform, Dataverse and Azure stack. An MCP agent is how that decision reaches the ERP.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you have an agent on the retiring server, book a 15-minute call and we will scope the rewrite with you — the instruction rebuild, the failure handling and the role review. https://cognilium.ai

What happens to my ERP agent on 1 October 2026?