Which environments can run the Dynamics 365 ERP MCP server?

Tier 2 or above, or a Unified Developer Environment — and explicitly not a Cloud Hosted Environment. That single exclusion is the one that catches teams out, because a Cloud Hosted Environment is often exactly where a developer would try this first.

There are four other prerequisites, all published, and none of them is a licence.

Which environment tier is required, and which is ruled out?

Microsoft states both halves in one sentence:

"Your environment is Tier 2 or above, or a Unified Developer Environment. The MCP server isn't supported on Cloud Hosted Environments (CHE)."

Read the exclusion as a hard stop rather than a performance note. A Cloud Hosted Environment is a legitimate, commonly used development environment, and it will not run this. If your proof-of-concept plan starts on a CHE, it needs to move before it starts.

The practical consequence is a sequencing one. Tier 2 environments are shared, governed and finite in most organisations, so access to a sandbox becomes a scheduling dependency for an agent project rather than something a developer arranges on the day.

Which product versions support it?

Three floors, and any one of them satisfies the requirement:

Microsoft's phrasing is "The product version of Dynamics 365 finance and operations apps must be at least" those three — so a proactive quality update on an older release qualifies you without a full version move.

That is worth checking before anyone schedules an upgrade for this. A PQU on 10.0.45 or 10.0.46 is a materially smaller change than moving to 10.0.47, and it reaches the same starting line.

One version note points the other way. The retiring static server "is still available in finance and operations apps environments with version 10.0.2263.17 and greater" — a different numbering series entirely, and a different server. What happens to that one on 1 October is its own question.

Is there anything to switch on?

Almost certainly not, and this is the prerequisite most people over-plan:

"Enable the Dynamics 365 ERP Model Context Protocol server feature in Feature Management if not already enabled. The MCP server is enabled by default."

Enabled by default means the feature-management step is a verification, not a task. Check it, and expect to change nothing.

Note the feature's full name as Microsoft writes it — Dynamics 365 ERP Model Context Protocol server, spelled out, not abbreviated. Feature Management is searched by string, so the abbreviation will not find it.

And Feature Management itself is one of the pages the server cannot reach, which is a deliberate boundary rather than an oversight — an agent cannot turn its own features on.

Does the agent platform need registering?

Yes, and this is the step with no default:

"Add the agent platform on which you're building your agent in the Allowed MCP Clients page."

An allow-list is an explicit, per-client decision. Copilot Studio, Microsoft Foundry and non-Microsoft clients each have to be added; nothing arrives permitted. It is also the natural governance point — the list of platforms that may reach your ERP is a short, reviewable artefact, which is a rare thing in an integration story.

Plan for it as an approval with an owner, not as a checkbox during a build sprint.

Can you put it behind the in-app Copilot?

Not yet — and the wording of this limit matters more than most, because nothing stops you trying:

"Adding the Dynamics 365 ERP MCP server as a tool in the Copilot for finance and operations apps agent, enabling it for use with the sidecar chat panel in the client, isn't yet supported. Although you're not blocked from adding the MCP server to the agent, you might experience errors in the execution."

Read the last clause twice. The platform permits the configuration and the documentation says it is unsupported, which is the most expensive combination available: it will appear to work in a demo and it carries no commitment.

Microsoft closes the door explicitly: "Microsoft support doesn't guarantee assistance for resolving errors or problems for these scenarios."

So the in-app sidecar is not a delivery target for an MCP agent today. If the requirement is a chat experience inside the client, that is a different architecture decision — and the honest answer is to make it deliberately rather than discover it after a build.

When is the server unavailable?

During servicing, and the failure is not graceful. It is limitation nine of ten:

"The MCP server is unavailable during environment downtime, such as servicing windows. Any MCP requests that agents make during these servicing windows fail."

"Fail" is the published word — not queue, not retry, not degrade. An autonomous agent running on a schedule will meet this eventually, so the retry and alerting behaviour belongs in the design rather than in a later hardening pass.

One more environmental constraint is worth knowing before you promise a rollout: the server "supports only US English (en-us)", and while form labels and values follow the authenticated user's locale, "the MCP responses always provide metadata and guidance in English."

If you are checking whether your environments can carry an agent project, that is a short conversation with a definite answer. Bring your tier and version. https://cognilium.ai

Sources

• Use Model Context Protocol for finance and operations apps
• Build an agent with Dynamics 365 ERP MCP

This article is part of our work on AI in tandem with Dynamics 365.