Data tools, form tools or action tools — which does your ERP agent need?

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:

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:

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.

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/

Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.

More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.

If you are mapping a specific operation to a tool family and the answer is not obvious, that is a 15-minute call. Bring the operation.

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