TL;DR: There’s an open-source MCP server for D365 F&O that works directly over the native OData API — no minimum version requirement, no Cloud Hosted Environment restrictions, no Copilot Credits cost. This post covers both what the documentation says and what actually happened when we tried to set it up live with a client. Spoiler: it took a detour.
There’s been a lot of MCP hype in the Dynamics 365 community lately. My company’s owner heard about it and wanted a proof of concept — specifically connecting Finance & Operations to Claude for real-time financial and inventory queries. I took on the research, prepared two possible paths, and then got on a call with the client to make it happen. This post is the honest version of that story, including the parts that went sideways.
The two paths I found
Before the call, I had researched two options:
Option 1 — The official Microsoft MCP server. Looked familiar: create an App Registration in Azure, register it in F&O, enable a Feature Flag, configure the client. Very similar to what I’d already done for Business Central. The documentation seemed clean.
Option 2 — d365fo-client, an open-source server built on F&O’s native OData API. No version requirements, works on any environment type, no extra cost. Listed in the official MCP server directory.
I also had to explain upfront to the client that the official path had a potential cost implication — if you don’t have active Dynamics 365 Copilot licenses, Microsoft charges 0.1 Copilot Credits per tool call. Whether that matters depends on your license type and environment tier. That’s a question worth answering before committing to the official path. We didn’t know the answer for their tenant during the call, so we had that conversation in real time.
First attempt: the official server hit a wall immediately
I started walking through the official Microsoft path. We enabled the Feature Flag in F&O — “Dynamics 365 ERP Model Context Protocol server” — under Feature Management. We found the Allowed MCP Clients form under System Administration → Setup (it took a moment to locate it, it appeared only after the feature was enabled). We created a record with the App Registration’s Client ID.
One issue: Raúl, the person on the client side, didn’t have permission to grant admin consent for the API permissions in Azure. That required escalating to Juan, their IT contact, to grant it. Real-world projects always have this moment where you need someone else in the room.
Then came the actual blocker.
The claude_desktop_config.json snippet from Microsoft’s documentation uses this as the command:
Microsoft.PowerPlatform.D365ERP.MCP
What the documentation conveniently skips is that this executable doesn’t exist on your machine until you install it — and when I tried, it turned out it’s not available as a standard .NET global tool on NuGet:
microsoft.powerplatform.d365erp.mcp is not found in NuGet feeds
When Claude Desktop tried to launch it anyway, the result was immediate:
'Microsoft.PowerPlatform.D365ERP.MCP' is not recognized as an internal or external command
spawn Microsoft.PowerPlatform.D365ERP.MCP ENOENT
Server disconnected
I asked Claude itself about the error while on the call. The answer was quick: the executable simply isn’t on the machine, and the official server tooling is designed primarily for VS Code and Copilot Studio — not Claude Desktop. The path for Claude Desktop involves a remote proxy that isn’t published anywhere accessible. That’s a real gap in Microsoft’s documentation that cost us time on a live call.
Time to move to Option 2.
What actually worked: d365fo-client over OData
The open-source d365fo-client server takes a completely different approach. Instead of trying to invoke a Microsoft-hosted binary, it connects directly to F&O’s native OData API — which is active by default on every F&O environment, no Feature Flags needed.
The admin setup (App Registration in Azure + registering it in F&O) is identical to what we had already done. Those steps weren’t wasted. The only thing that changed was the client-side configuration.
Step-by-step setup
1 — App Registration in Microsoft Entra ID
(If you’ve already done this for the official server attempt, skip to Step 2.)
- Go to portal.azure.com → Azure Active Directory → App registrations → New registration
- Fill in:
- Name:
D365FO-MCP(or follow your org’s naming convention) - Supported account types: Accounts in this organizational directory only
- Redirect URI: leave empty
- Name:
- Click Register and copy:
- Application (client) ID
- Directory (tenant) ID
Create the client secret:
Certificates & secrets → New client secret → set expiration per your policy → Add
⚠️ Copy the secret value immediately — it won’t be shown again once you leave the page.
Add API permissions:
API permissions → Add a permission → search “Microsoft Dynamics ERP” under “APIs my organization uses” → Application permissions → add Ax.FullAccess and Odata.FullAccess → Grant admin consent
This last step requires Global Admin or Application Admin rights in Entra ID. On our call, Raúl didn’t have that permission and had to bring in Juan to complete it. Plan for this — it’s a common blocker on real projects.
2 — Register the app in F&O
System Administration → Setup → Microsoft Entra ID applications → New
| Field | Value |
|---|---|
| Client ID | Your Application (client) ID |
| Name | Claude MCP |
| User ID | A dedicated service account in F&O |
The User ID you pick determines what data the MCP server can actually reach inside F&O. Use a dedicated service account with read-only access to the relevant areas — not a System Administrator account.
This is the only step required inside F&O for the OData path. No Feature Flags, no Allowed MCP Clients list.
3 — Install uv on the end user’s machine
Open PowerShell and run:
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
Verify:
uvx --version
uvx is a modern Python package runner. Claude Desktop uses it to download and launch d365fo-client on demand — no manual package installation needed. On the call, Raúl was understandably cautious about running a PowerShell command he hadn’t seen before. It’s worth explaining what it does: it installs uv, a package manager, nothing more.
4 — Edit claude_desktop_config.json
File location:
| OS | Path |
|---|---|
| Windows | %APPDATA%\Claude\claude_desktop_config.json |
| macOS | ~/Library/Application Support/Claude/claude_desktop_config.json |
To open it from Claude Desktop: Settings → Developer → Edit Config
Add the D365FO server inside the mcpServers object:
{
"mcpServers": {
"D365FO": {
"command": "uvx",
"args": ["--from", "d365fo-client@latest", "d365fo-fastmcp-server"],
"env": {
"D365FO_BASE_URL": "https://{your-environment}.operations.dynamics.com",
"D365FO_CLIENT_ID": "{application-client-id}",
"D365FO_CLIENT_SECRET": "{client-secret-value}",
"D365FO_TENANT_ID": "{directory-tenant-id}",
"D365FO_LOG_LEVEL": "INFO"
}
}
}
}
If you already have other MCP servers configured (like Business Central), don’t replace the whole file — just add
D365FOas a sibling entry insidemcpServers. On the call, the client’s config already had a Business Central server, so we had to be careful to merge correctly rather than overwrite.
5 — Restart Claude Desktop and verify
Close Claude Desktop completely — from the system tray, not just the window. Reopen it.
Go to Settings → Developer and check that D365FO shows as connected (green). If it shows an error, the most common causes are:
| Error | Likely cause |
|---|---|
| Red / disconnected after pasting config | uv not yet installed — do Step 3 first |
401 Unauthorized | Admin consent not granted or app not registered in F&O |
403 Forbidden | The service account mapped in F&O doesn’t have sufficient roles |
| JSON parse error | Syntax issue in the config file — validate it at jsonlint.com |
Once connected, open a chat and type:
What tools do I have available from Finance & Operations?
Claude will list the 49 available tools. That’s your confirmation that the connection is live.
The 49 tools question
When we got connected, the client noticed something: 49 tools. Earlier in the research, I had seen mentions of the official Microsoft server potentially exposing thousands of dynamic tools through form navigation. The client asked, reasonably, why only 49.
The short answer: the 49 tools come from d365fo-client, which operates over OData. The “thousands of tools” capability belongs to the official Microsoft MCP server’s dynamic mode — which navigates the F&O UI like a user would, accessing forms, buttons, and calculated fields. That’s a fundamentally different approach and requires the official server setup (Tier 2+ environment, version 10.0.47+, Copilot licensing questions resolved).
For data queries, reports, and dashboards — which was the actual use case here — 49 OData tools cover everything you need. The dynamic server’s value shows up in automation scenarios where you need the AI to actually operate the ERP, not just read from it.
Key entities for the most common queries
Inventory:
InventorySiteOnHand → On-hand stock by site and item
ReleasedProductsV2 → Product catalog
SalesOrderHeadersV2 → Sales order status
PurchaseOrderHeadersV2 → Purchase orders
Finance:
GeneralJournalAccountEntries → Posted journal entries
TrialBalanceEntity → Trial balance
MainAccounts → Chart of accounts
LedgerJournalHeaders → Unposted journals
VendorInvoiceHeaders → Vendor invoices
For multi-company queries, add ?cross-company=true to any OData call, or filter by dataAreaId.
What I’d do differently next time
The session took longer than it needed to because I started with the official path without knowing upfront that the executable wasn’t available. A few things to confirm before the call:
- Ask about the F&O environment type and version — Cloud Hosted or Tier 2+, and what version is running. This determines immediately whether the official server is even an option.
- Ask about Copilot licensing — if the organization doesn’t have D365 Copilot licenses active, the official server has a per-call cost. That’s a business decision, not a technical one.
- Have the PowerShell command ready to share — and be ready to explain what it does. Not everyone is comfortable running a script they haven’t seen before.
- Confirm who has admin consent rights in Azure — this is almost always a different person from whoever manages F&O, and it’s a common blocker.
At the end of the call, the client was connected and could query F&O data from Claude in real time. The conclusion from their side: “It wasn’t that complicated.” That’s true once you know which path to take. Getting there, less so.
Resources
- GitHub: mafzaal/d365fo-client
- Official OData documentation for F&O
- Service protection API limits
- Official MCP server directory
If you want the version covering the official Microsoft MCP server — the one with form navigation and X++ action invocation — I have a separate post for that path. This one is for when you need to move fast without resolving licensing questions first.