For years, connecting AI to D365 F&O meant one of two things: building a custom REST API on top of OData, or accepting that your AI assistant could only read data but never act on it.
The Dynamics 365 ERP MCP Server changes both of those constraints simultaneously. It exposes hundreds of thousands of ERP functions — including your custom X++ extensions and data entities — to AI agents through a single, standardised protocol. No new APIs to write. No custom connectors to maintain.
This article covers everything a D365 F&O developer needs to understand about MCP: what it is, how the three tool categories work, how to configure it, how security is enforced, what it costs, and where its current limitations are.
What is Model Context Protocol?
Model Context Protocol (MCP) is an open standard originally developed by Anthropic that defines how AI agents communicate with external data systems and business applications. Instead of every AI tool building its own custom connector to every business system, MCP provides a common language that any agent can use to discover and invoke capabilities in any MCP-compatible server.
In the Microsoft ecosystem, MCP is the protocol that bridges AI agents — whether built in Copilot Studio, Azure AI Foundry, VS Code, or any other compatible client — with Dynamics 365 F&O business logic and data. The key shift it enables is this:
Static vs Dynamic MCP server — understand the difference
The dynamic server exposes three categories of tools that together give agents access to virtually everything a human user can do in D365 F&O. The agent determines at runtime which tools to use and in what sequence based on the user's natural language prompt.
Architecture — how an agent call flows through MCP
The important architectural point: the MCP server does not open a browser session or interact with the D365 client. Form tools work through server APIs that expose the application view model — the same model the client uses to render forms. The agent receives this view model as context, navigates it, and invokes actions through the server. This is why it respects security roles exactly as a human user would.
The three tool categories explained
Data tools are the most efficient path when the agent needs to create, read, update, or delete records. They work through data entities — the same OData-exposed entities available via the standard F&O API layer. If you have published custom data entities, they are automatically discoverable here.
Data tools require fewer tool calls and perform better for standard CRUD operations. If your agent is defaulting to form tools for simple reads or creates, add explicit guidance in your agent instructions to steer it toward data tools for those scenarios.
Form tools are the most powerful category. They let the agent interact with D365 F&O exactly as a human would — opening forms, setting field values, clicking buttons, applying filters, and saving records. Any action available to a human user through the application interface is available to the agent through form tools, including custom forms and buttons you have added through extensions.
This is not Computer Use (screen scraping). The agent works through server-side view model APIs — it receives structured data about what is on the form and invokes server-side methods directly. This is both faster and more reliable than UI-based automation.
This is one of the most common reasons an agent fails to find a field. FastTabs in D365 F&O are collapsed by default. The agent must call form_open_or_close_tab to expand the tab before it can read or set values on controls inside it. Build this awareness into your agent instructions for forms with multiple FastTabs.
Calling form_set_control_values on a lookup field (like Vendor Account or Item Number) does not trigger the lookup validation and will result in an unresolved or incorrect value. Always use form_open_lookup for fields that require a lookup selection.
Action tools bridge the gap between the standard data/form layer and your custom X++ code. Any class you write that implements ICustomAPI and is correctly secured becomes automatically discoverable and invocable through MCP — without any additional connector or API work.
For a class to appear in api_find_actions, it must:
- Implement the
ICustomAPIinterface - Be decorated with the
[CustomAPI]and[AIPluginOperationAttribute]attributes - Have an associated Action Menu Item in a deployed security privilege assigned to the agent's role
- Be registered via System Administration → Setup → Synchronize Dataverse Custom APIs
Once registered, the same class is also accessible through Copilot Studio as a tool and through the Dataverse Custom API layer — three surfaces from one X++ class.
Alongside the operational MCP server, Microsoft has released a separate Dynamics 365 ERP Analytics MCP Server (currently in preview). This server connects agents to the Business Performance Analytics layer — the pre-aggregated dimensional model built on top of F&O transactional data.
It exposes three analytical value chains:
- Record-to-Report — financial data, P&L, budgets
- Procure-to-Pay — purchase orders, vendor management
- Order-to-Cash — sales orders, invoicing, receivables
An agent can ask: "Show me budget variance for this fiscal year" or "Which vendors have the highest return rates?" — and the Analytics MCP server translates the question into a DAX query against the BPA model and returns structured JSON data.
The real power comes from combining both servers in one agent: use the Analytics MCP server to identify an issue (e.g. "Which purchase orders have been outstanding for more than 60 days?") and then use the operational MCP server to act on the result (e.g. send a reminder, update a status field, trigger an approval). This pattern — insight to action — is what Microsoft means by Agentic ERP.
Prerequisites and setup
Environment requirements
- D365 F&O version 10.0.47 or later (also available on 10.0.46 PQU-2 and 10.0.45 PQU-7)
- Tier 2 or above environment, or a Unified Developer Environment (UDE). The MCP server is not supported on Cloud Hosted Environments (CHE).
- The Dynamics 365 ERP Model Context Protocol server feature must be enabled in Feature Management — it is on by default in supported versions
Allowed MCP Clients
Before any agent platform can connect to your MCP server, it must be explicitly allowed. By default, only two platforms are permitted:
To allow additional agent platforms (e.g. Azure AI Foundry, a custom agent host, Claude Desktop):
- Register your agent application in Microsoft Entra ID and note the Application (Client) ID
- In D365 F&O, navigate to System Administration → Setup → Allowed MCP Clients
- Add a new row with the Client ID and set Allowed to
true
Agent security setup
The MCP server enforces D365 F&O security roles on every call. There is no elevated or bypass mode. The agent operates with exactly the same permissions as the user identity it is authenticated as. This means:
- Create a dedicated service account or Entra ID application for your agent in F&O
- Assign it the System agent security role (required to exempt it from user licensing — this role has no permissions of its own)
- Assign additional roles that grant only the permissions the agent needs for its tasks
- Do not assign System Administrator to your agent identity — the MCP server excludes security management forms, but least-privilege is still best practice
Agent identities assigned to the System agent role do not require a Dynamics 365 F&O user license. This applies to both interactive agents (where a human talks to the agent) and autonomous agents. The human users who interact with a chat-based agent still need their own F&O user license to access the underlying data.
Real-world use case scenarios
🧾 Scenario 1 — Vendor invoice processing agent
An AP clerk asks: "Create a vendor invoice for vendor US-001 for $5,000 against PO PO-00123, and submit it for approval." The agent uses data_find_entity_type to locate the VendorInvoiceHeaderEntity, data_get_entity_metadata to understand required fields, data_create_entities to create the invoice header and lines, then form_open_menu_item → form_click_control to submit it for workflow approval — all in one conversational turn.
📦 Scenario 2 — Purchase order status agent in Teams
A procurement manager in Microsoft Teams asks: "What is the status of all purchase orders from vendor GB-001 that are past their delivery date?" The agent uses data_find_entities_sql to query PurchTable with a date filter, aggregates the result, and returns a summary — without the manager opening D365 F&O at all. The same agent can then be asked to send reminders or escalate lines.
📊 Scenario 3 — Insight-to-action with Analytics MCP
A finance controller asks: "Show me vendors where our payment cycle time exceeds 45 days, then update their payment terms to Net 30." The agent queries the Analytics MCP server for payment cycle metrics, identifies the qualifying vendors, then uses the operational MCP server's data tools to update VendPaymTermId on each vendor record — an insight-to-action workflow completed in one agent conversation.
⚙️ Scenario 4 — Custom X++ logic via Action Tools
From a previous article on this blog, the CustomAPICalculateCustomerBalance class is registered as an AI tool. A credit controller asks: "What is the current balance for customer US-001?" The agent calls api_find_actions, identifies the registered class, invokes it via api_invoke_action, and returns the live calculated balance — the same value computed by custTable.balanceAllCurrency().
Licensing and cost model
MCP usage incurs cost at two levels: LLM orchestration (the AI thinking about what to call) and MCP tool execution (the actual calls to your F&O environment). The model differs depending on whether you use Copilot Studio or another agent client.
Premium license exemption: Users with Dynamics 365 Finance Premium or Dynamics 365 Supply Chain Management Premium licenses are exempt from the 0.1 credit per tool call charge when using agents built outside Copilot Studio. Copilot Studio agents still bill at the fixed Agent Action rate regardless of premium license.
Microsoft 365 Copilot users: If the agent is built in Copilot Studio and the user is licensed with Microsoft 365 Copilot, tool calls to the D365 ERP MCP server do not incur additional credit consumption — the cost is covered by the M365 Copilot license.
Current limitations you need to know
form_filter_grid tool supports only the "matches" operator. Date range operators (before, after, between) are not supported.What this means for D365 developers
The MCP server changes the calculus on two things that developers previously had to build manually.
First, custom integrations. The traditional pattern for exposing F&O business logic to external systems was: write a service class, expose it as a REST endpoint via the custom service framework, document it, and maintain it through upgrades. For scenarios that fit within the MCP server's tool categories, that entire layer is now unnecessary. The agent discovers and invokes the logic directly.
Second, the value of your existing customisations. Custom data entities you have built are automatically discoverable through Data Tools. Custom forms and buttons are automatically accessible through Form Tools. Custom X++ classes registered as AI tools are invocable through Action Tools. Every customisation you have built becomes part of the AI surface of the ERP without any rework.
The one area where custom development still adds value is the ICustomAPI / Action Tools layer — when you need to expose business logic that is not reachable through data entities or form navigation. That is where the X++ AI tool framework covered in the previous article on this blog fits.
Conclusion :-
The Dynamics 365 ERP MCP Server is not a copilot feature. It is a new extensibility surface for the entire platform — one that makes D365 F&O a first-class participant in the AI agent ecosystem rather than a passive data store that agents query around.
The three tool categories each serve a distinct purpose: Data Tools for efficient CRUD, Form Tools for complex business logic that lives in button-driven processes, and Action Tools for X++ code that needs to be AI-callable on demand. Understanding which tool category fits which scenario is the core skill for building effective agents on this platform.
The limitations are real and worth planning around — especially the FastTab behaviour, the lack of advanced grid filters, and the exclusion of system admin forms. But the capability floor is high enough today to automate a significant portion of routine finance and supply chain workflows without any custom integration code.
The question is no longer whether AI can interact with D365 F&O. It can. The question is which of your business processes should be next.
