Dynamics 365 MCP Actions: What 650,000 Means for Agent Governance

TL;DR

Microsoft states that Dynamics 365 now exposes over 650,000 MCP actions across sales, finance, supply chain, human resources, field service, customer service and project operations (Microsoft Dynamics 365 Blog, 23 July 2026).

On 5 August 2026 Microsoft published two distinct agent control points: the Agent 365 CLI, which scores an MCP server before an agent uses it, and the Agent Governance Toolkit, which evaluates sensitive tool calls while the agent runs (Microsoft Security Community Blog).

Microsoft's own framing of the gap: "access control can tell you which service an agent may reach, but it does not always tell you whether a particular action is sensible, safe, or permitted."

The CLI evaluation runs a five-step pipeline and scores tools on a bring-your-own-LLM basis using GitHub Copilot CLI or Claude Code. Microsoft states the command does not send tool-schema data to Microsoft.

Partner evidence is early but specific: proMX reports its Project Operations Activity Approvals Agent went from preview to full internal rollout in weeks, reaching 50% adoption in its own PMO.

What did Microsoft actually announce?

Dynamics 365 exposes 650,000 Model Context Protocol actions to AI agents as of 23 July 2026, and 2 governance control points shipped on 5 August. Those agents run inside the transaction layer using the same data models, rules, permissions and audit trails as a human user. That is Microsoft's own number and its own description, published on the Dynamics 365 blog on 23 July 2026. Two weeks later, on 5 August, Microsoft's security team published the governance half: two tools that sit at different points in the MCP lifecycle.

The two announcements are usually read separately. Read together they describe a single decision every Dynamics operator now has to make.

The direction is not new. We covered MCP becoming the front door into Dynamics 365 when the protocol first landed, and the agent management cockpit that followed it. What changed in August is that the governance layer caught up with the surface.

Why is 650,000 the number that matters?

Because it is not a feature count. It is a surface count.

An MCP action is something an agent can invoke. Six hundred and fifty thousand of them means the question "what can an agent do in our ERP" no longer has a short answer. Some arithmetic makes the scale concrete:

If one person reviewed one action per minute, eight hours a day, five days a week, a full pass over 650,000 actions would take roughly 52 person-weeks. A full manual review of the surface is not a thing a team does.

Spread across the seven product areas Microsoft names, that averages about 93,000 actions per area. There is no module small enough to review by hand either.

Microsoft's Business Central 2026 wave 1 shipped 4 named finance agents (Payables, Sales Order, Expense, and the Agent Designer). The gap between 4 agents and 650,000 available actions is the entire governance problem in one comparison: a ratio of 162,500 to 1.

The number is not a criticism. A large action surface is what makes agents useful inside an ERP rather than bolted alongside it. But a surface that cannot be reviewed by reading it has to be governed by policy, and policy is what the August tools are for.

What do the two control points actually do?

They answer different questions at different times. This is the part most coverage collapses, and collapsing it is how teams end up buying one and assuming they have both.

Agent 365 CLI. Agent Governance Toolkit

**When it runs**. Before an agent uses the server. While the agent is running

**What it judges**. The MCP server's tool definitions. An individual tool call

**The question it answers**. Is this server fit to be used at all?. Should this specific action proceed?

**Output**. A per-tool score, a prioritised improvement list, an overall maturity score, JSON and HTML reports. A decision against policy, with each decision recorded

**What it cannot tell you**. Whether any given call at runtime is appropriate. Whether the server was well built in the first place

Microsoft puts it in one line: "One improves what the agent sees. The other governs what the agent does."

The CLI's evaluation is a five-step pipeline. It connects to the server and collects tool schemas, generates a checklist, scores the semantic checks with a coding agent, calculates a maturity level and action priorities, then writes JSON and HTML reports. Two kinds of check run inside it. Deterministic checks apply exact rules, such as a tool name cannot be empty. Semantic checks use a coding agent to score clarity and meaning, and each result carries a reason for its score.

Where does the scoring model run?

Locally, and that detail deserves more attention than it is getting.

Microsoft states the semantic scoring uses a coding-agent CLI under your own account and AI subscription, naming GitHub Copilot CLI and Claude Code, and that the command does not send tool-schema data to Microsoft. Microsoft calls this a bring-your-own-LLM model and says it is useful when model calls must remain inside an approved deployment.

For a regulated Dynamics customer that is the difference between being able to run the evaluation and not. An MCP server's tool schema describes what a system can do and often how it is structured internally. Shipping that to a vendor endpoint for scoring is a data-governance conversation on its own. Keeping it local removes the conversation.

The prerequisites are modest: the Agent 365 CLI, Node.js 18 or later for GitHub Copilot CLI, and a supported coding-agent CLI for semantic scoring.

Is there evidence any of this works in production?

Some, and it is worth reading precisely rather than generously.

Microsoft's partner examples are named and specific. Cegeka built a Quality Impact Recall Agent for manufacturing and life sciences, anchored in ERP data with a traceability add-in that maps batch and lot relationships, tracing from a defect signal back to affected batches and forward to affected customers. Cegeka says the manual version of that process can take hours or days. Their AI ERP architect, Thomas Van Dorpe, frames the constraint better than any vendor deck: "How do you introduce AI into a business process where 99% accuracy is considered a failure?"

proMX, working in Dynamics 365 Project Operations, served as customer zero for the Activity Approvals Agent. They started with time-entry approvals, where high volumes of short-duration entries were stalling billing preparation and slowing month-end close. The agent went from preview to full internal rollout in weeks and reached 50% adoption across proMX's internal PMO. Approvers stay in the loop, thresholds are defined up front, and approvers see what the agent recommends before anything posts.

Read the caveats honestly. Both are partners of the vendor, describing their own deployments. proMX's 50% is adoption inside its own organisation, not a customer outcome, and adoption is not the same as measured benefit. What these examples do establish is that the pattern runs in real workflows with humans holding the thresholds, which is a more useful claim than a percentage would be.

What should a Dynamics operator do about it this quarter?

Three things, in order.

Decide the surface before you decide the agents. The governance question is not "which agents do we want". It is "which of the 650,000 actions is any agent permitted to reach". Least-privilege role binding is the lever, and it is set once and inherited by every agent afterwards.

Run the evaluation on any MCP server you did not write. The CLI turns "is this server ready" into a prioritised list. A third-party or partner-built MCP server is the case it exists for, and the local scoring model means running it costs you a terminal session rather than a data-governance review.

Separate the two control points in your own plan. Evaluating a server does not govern runtime behaviour, and governing runtime behaviour does not tell you the server was well built. Teams that treat them as one thing will have covered half the lifecycle and will not know which half.

FAQ

Does the 650,000 figure mean agents can do 650,000 things in our tenant?

No. It is the platform surface Microsoft exposes. What any agent in your tenant may reach is set by the role it is bound to, and those permissions and audit trails are the same ones that govern human users.

Is MCP support in Dynamics 365 a lock-in move?

Microsoft says the opposite: because Dynamics 365 is MCP compliant, it can connect to compatible agents across supported platforms, which it frames as multi-agent interoperability and customer choice.

Do we need both tools, or is one enough?

They cover different phases. The CLI is build-time and evaluates the server. The toolkit is runtime and evaluates individual calls. Neither substitutes for the other.

Does running the CLI evaluation send our schema to Microsoft?

Microsoft states it does not. Semantic scoring runs through a coding-agent CLI under your own account and subscription.

The last mile

Microsoft automates the step. That is real, and 650,000 actions is a serious piece of platform engineering. But an action surface is capability, not judgment, and the value shows up at the last mile, where a permitted action still has to be the optimal one for this business, on this order, at this margin, on this day.

That is the gap between a system of record and a system of intelligence. The ERP records the state and now lets an agent act on it. Deciding which action is the right one, inside the system a team already runs on, is the layer Cognilium works in.