Show notes
This one comes to you from a sunny morning on the floor at DynamicsMinds, where we're joined for the second time by Patrick Mouwen — a man much of the Commerce community would happily call a "commerce hero" for doing what Microsoft arguably should have from the start: properly documenting the Dynamics 365 Commerce CSU APIs.
Patrick's session was on Commerce and MCP, and he opened with a reality check on Microsoft's own [Dynamics 365 Commerce MCP server](Dynamics 365 Commerce Model Context Protocol (MCP) server (preview) - Commerce | Dynamics 365) (in preview): in the V48 preview he counted roughly nine tools against some 650 Commerce operations. His answer to that gap is to put **Azure API Management** in front of the estate — Commerce, F&O, Dataverse, Inventory Visibility, even non-Microsoft systems — and use its ability to [expose a managed REST API as an MCP server](Expose REST API as MCP server - Azure API Management) through the [AI gateway](AI gateway capabilities in Azure API Management). For his demo he wrapped ~40 Commerce operations plus a few F&O address APIs into one API, converted it to MCP, and drove it from Claude Desktop. Copilot Studio with its GPT engine struggled on multi-step workflows — stalling or calling APIs out of sequence — which he put down to the model.
Much of the value, he stressed, lives in metadata. The full instruction set is consumed on every action, so long system prompts get slow and expensive; pushing metadata down into the MCP tool definitions improved both performance and token use. He also flagged **skills** as a further layer — loaded only when the agent needs them rather than on every call, and far more efficient for it.
The demos brought it home. A call-center employee acting on behalf of a B2B customer could feed the agent a 50-line quotation, have it build the cart, and turn that into quote-to-order conversion — fixing master data issues like a bad address along the way through the Dynamics ERP connectors (updated synchronously, deliberately). Crucially, the Commerce framework is context-sensitive by design: a customer role is baked into every supporting API and automatically filters data to that customer's context. Adding an MCP layer doesn't loosen any of that, so the guardrails stay put. The horror stories of agents being talked into discounts they shouldn't give aren't agent problems — they're configuration problems.
The catch is documentation. Those 650 operations aren't documented in a way an LLM can reason about; the descriptive labels actually sit inside the entities DLL but aren't surfaced as metadata. Microsoft is now hard-coding metadata into the CSU for Commerce MCP, but as SaaS that limits customer iteration — whereas in API Management you own the OpenAPI spec, write your own tool descriptions, and version them in CI/CD.
On architecture, Patrick's tip was to think in **domains, not systems** — separate MCP servers for cart, payments, customer management — agnostic of what's underneath. He capped his demo at 30–40 tools per server; push past 30 and it starts to hallucinate and slow down. The same instinct applies to agents: split work into focused sub-agents so one isn't tempted to reach for the wrong server. One honest caveat: the API Management route is "MCP light" — tools only, no prompts or resources — but for most customers that's the better business case today.
On governance, he pointed to **Microsoft Agent 365**, now positioned as the bridge for securing agents and tackling "shadow AI" via Defender and Intune. And looking ahead, he sees agentic commerce breaking out of the corporate boundary toward standards like the **Agentic Commerce Protocol (ACP)** from OpenAI and Stripe, where a personal-shopper agent buys on your behalf and is largely brand-agnostic — making exposed product APIs more important than ever. The closing anecdote captured both the promise and the peril: someone running OpenClaw at home overheard a remark about a broken sink and promptly booked a handyman to show up at the door. Build on the stable Commerce framework, keep the guardrails in place, and you only need that flexible topping on top.
Thanks again to Patrick for joining us — and given how fast this moves, the next chapter is probably only a couple of weeks away.
**Links**
- Dynamics 365 Commerce MCP server (preview): https://learn.microsoft.com/dynamics365/commerce/commerce-mcp?WT.mc_id=DX-MVP-5004702
- Expose a REST API in API Management as an MCP server: https://learn.microsoft.com/azure/api-management/export-rest-mcp-server?WT.mc_id=DX-MVP-5004702
- AI gateway in Azure API Management: https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities?WT.mc_id=DX-MVP-5004702
Patrick Mouwen | LinkedIn