TL;DR
Three tool families on the Dynamics 365 ERP MCP server, in the priority order Microsoft publishes: data tools for CRUD, form tools for what the app decides.
Most likely all three, and Microsoft publishes the order to try them in. The Dynamics 365 ERP MCP server exposes three families, and they are not alternatives — they are layers, with a documented preference between them.
Getting the order wrong is the most common way an agent ends up slow and expensive while still technically working.
What are the three families?
Microsoft names them plainly:
"Data tools: These tools enable the agent to perform standard data operations to create, read, update, and delete data in your finance and operations apps environment. Form tools: These tools enable the agent to perform operations that are available on pages in the application. Action tools: Enable the agent to find and directly invoke classes in finance and operations apps code."
The counts matter for scoping: seven data tools, thirteen form tools, two action tools. All twenty-two are published with names and descriptions, so you can read the whole surface before you build against it.
The important structural point is what they have in common. All three are generic primitives, not named business functions. Microsoft is explicit that this replaced the older approach: rather than "having static tools for specific actions, like Find approved vendors or Release purchase requisition lines, the agent uses the tools to open forms, set field values, and select actions available on the form."
That is why migrating from the static server is a rewrite rather than a port.
Which family should the agent reach for first?
Data tools — and this is not a preference we invented. It is in the instruction block Microsoft ships:
"For create/read/update/delete operations - you MUST prefer using data tools before using form tools." "When explicitly instructed, or if proved impossible to complete the task using data tools, use the form or API tools."
Microsoft explains the reason in engineering terms: working through data entities "is more efficient for standard CRUD operations. It provides better performance and requires fewer tool calls to perform the operations than using the form tools."
Fewer tool calls is not only a latency argument. Outside Copilot Studio each call is billed, so tool selection is a cost decision as much as a design one — which is the running-cost question in a different form.
Microsoft even names the failure and its fix: "If you find that your agent is using form tools for operations that the agent could perform more optimally through data tools, you can improve performance by adding guidance in your agent instructions on which tools the agent should use for your scenarios."
So a slow agent is often an instruction problem, not a platform problem.
What are data tools actually good for?
Reading and writing records where the record is the whole job. The seven cover entity discovery, metadata, and then create, read, update and delete over OData.
Two of them exist purely to make the others usable: data_find_entity_type finds the entity, and data_get_entity_metadata returns the schema "needed for calling the `data_find_entities`, `data_create_entities`, `data_update_entities`, and `data_delete_entities` tools."
Three constraints decide whether this path works for your operation, all published:
| Constraint | Microsoft's words |
|---|---|
| No nested creates | "Deep inserts aren't supported for create." |
| Plural entity names | "You MUST use plural entity name in the OData path… For V2+ entities, use plural before V. E.g. SalesOrderHeadersV2." |
| Enum filter syntax | $filter=Style has Namespace.Pattern'Yellow' |
And one change is coming that affects reads: data_find_entities_sql "replaces the `data_find_entities` tool that uses OData in version 10.0.48 of finance and operations apps." Microsoft documents the dependency; it does not publish a date for 10.0.48, so do not build a plan around that version yet.
What are form tools for, if data tools are faster?
Everything the application calculates or decides rather than stores. Microsoft draws the line precisely:
"Form tools are optimal for enabling agents to perform operations that are available in the application that aren't standard Create, Read, Update, Delete (CRUD) operations. For example, actions in the application performed by clicking buttons that execute business logic through code are available to agents through these tools, or retrieving record values that the application calculates at runtime."
"Calculates at runtime" is the phrase to hold on to. A price after discount rules, an availability figure, a promise date — these are not columns you can read. They exist because the application computed them, so reaching them means going where the computation happens.
And the mechanism is server-side, not screen-driven:
"Although form tools are conceptually similar to Computer Use Agents (CUA), the tools don't work directly with the application client. Rather than opening a client session for the agent interaction, the tools work through server APIs that provide the agent with the application view model as context."
Microsoft's comparison is to a Computer Use Agent, and the answer is no — which is the question that deserves its own article.
What are action tools for?
The residue: business logic that neither entities nor pages expose. Microsoft frames it as a genuine minority case — entities and forms make "millions of actions available to agents", but
"there might be scenarios where the action or business logic isn't available through the entities or application client, or the agent needs direct access to the logic through code."
Then a developer writes it. The route is specific: a class "using the AI tool framework" that implements the `ICustomAPI` interface, with security defined for the associated menu action item, and correctly configured classes "appear in the list on the Synchronize Dataverse Custom APIs (CustomApiTable) form." The agent finds and calls them with api_find_actions and api_invoke_action.
Two tools, unlimited surface — which is why this family looks small and is not. Exposing your own X++ logic is the deep version of this.
How do you actually choose, per operation?
Ask what kind of thing the answer is. That routes it in one step:
| The operation | Family | Because |
|---|---|---|
| Read, create, update or delete a record | Data | Microsoft's instruction says you MUST prefer it for CRUD |
| Get a value the system computes — price after discounts, availability, a promise date | Form | It does not exist until the application calculates it |
| Press something that runs business logic — release, post, confirm | Form | Microsoft names button-driven logic explicitly |
| Logic that exists only in your X++ | Action | Nothing else reaches it |
| A nested create in one call | None of them | Deep inserts are unsupported; split the operation |
Write the routing into the agent's instructions rather than hoping orchestration finds it. That is Microsoft's own remedy for the wrong-family problem, and it is the cheapest lever in the whole build.
If you are mapping a specific operation to a tool family and the answer is not obvious, that is a 15-minute conversation. Bring the operation. https://cognilium.ai
Sources
- Use Model Context Protocol for finance and operations apps
- Build an agent with Dynamics 365 ERP MCP
- Create AI tools with finance and operations business logic
This article is part of our work on AI in tandem with Dynamics 365.
Share this article
What Microsoft ships, what it does not, and the layer we build where a general assistant runs out.
