Dynamics 365 MCP Architecture

This Lab examines a controlled way to expose selected Dynamics 365 Finance and Supply Chain Management capabilities to AI agents through Model Context Protocol (MCP).

The key design point is deliberately conservative: Dynamics 365 is not assumed to be an MCP server. The MCP boundary sits outside the ERP application and translates approved agent tools into supported enterprise integration interfaces.

Problem

Agents increasingly need access to transactional context and business actions. A useful agent may need to retrieve a customer balance, inspect an order, check inventory availability or request a controlled business operation.

Giving an agent broad application access is not an acceptable architecture. The design needs a narrow tool surface, explicit identity, predictable business semantics, auditability and the ability to require human approval for sensitive actions.

Research hypothesis

An enterprise MCP server can act as an agent-facing anti-corruption layer around Dynamics 365.

Instead of exposing generic CRUD operations, the server should expose business-oriented tools such as:

• get_sales_order_status
• check_inventory_availability
• get_vendor_account_summary
• prepare_purchase_requisition

The MCP server then maps those tools to supported Dynamics 365 interfaces or to an intermediate enterprise API layer.

Reference architecture

Agent / Copilot
      |
      | MCP client
      v
Enterprise MCP Server
      |
      +-- Tool catalogue
      +-- Input validation
      +-- Authorization policy
      +-- Approval policy
      +-- Audit / telemetry
      |
      v
Enterprise API / Integration Layer
      |
      +-- OData data entities
      +-- Custom services where justified
      +-- Business events for outbound events
      +-- Other approved integration services
      |
      v
Dynamics 365 Finance & Supply Chain Management

The additional layer is intentional. It prevents the agent protocol from becoming the ERP integration contract.

Why not expose generic data operations?

A tool named update_record may be technically flexible, but it creates a weak enterprise contract. The agent has to understand internal data structures and the authorization boundary becomes difficult to reason about.

A business-oriented tool is narrower. Its input schema, permitted operation, validation and side effects can be reviewed explicitly.

For example, prepare_purchase_requisition can be designed to create a draft transaction that still follows normal approval controls. That is materially different from giving an agent a general-purpose write interface.

Dynamics 365 integration boundary

Finance and operations apps provide supported service and integration mechanisms including OData over data entities and custom services. Business events provide an event-driven mechanism for outbound scenarios.

The MCP server should use those supported boundaries directly or call an enterprise integration/API layer that already governs them.

This Lab does not propose bypassing Dynamics 365 business logic by accessing the application database directly.

Identity and authorization

Authentication to the MCP server and authorization to each tool are separate concerns.

A production design should make explicit:

1. who the user or calling workload is
2. which agent is acting
3. which MCP tools that identity may invoke
4. which downstream Dynamics 365 privileges are required
5. whether the operation requires human approval
6. which business transaction and audit record are produced

The downstream identity model must be selected according to the scenario. A service principal may be appropriate for tightly controlled system operations, while user-context scenarios may require a design that preserves user accountability through the integration chain.

The architecture should never assume that because an agent can see a tool, it is automatically authorised to execute that tool for every user.

Tool design principles

Prefer business verbs

Expose business intent rather than technical table operations.

Minimise write scope

Read-only tools should be the default starting point. Write tools should have narrower schemas, additional validation and stronger approval requirements.

Preserve normal controls

Agent-triggered operations should not become a path around workflow, segregation of duties, credit controls, posting controls or other application governance.

Make side effects explicit

A tool description should state whether it reads data, creates a draft, submits a transaction, posts a transaction or triggers another process.

Treat tool descriptions as part of the control surface

Agent runtimes use tool names and descriptions to decide when tools are appropriate. Ambiguous tool descriptions are therefore an architecture and safety issue, not only a documentation problem.

Read pattern

A low-risk first prototype is a read-only tool.

Agent
  -> MCP: get_sales_order_status(orderNumber)
  -> Policy check
  -> Enterprise integration boundary
  -> Dynamics 365 data entity / service
  <- Normalised business response
  <- MCP result
Agent response

The MCP server should return a deliberately shaped response rather than forwarding an entire Dynamics 365 payload to the model.

Write pattern

A write operation needs an additional control point.

Agent proposes action
      |
      v
MCP tool request
      |
      v
Validation + authorization
      |
      v
Approval required?
   /      \
 yes      no
  |        |
Human      |
approval   |
   \      /
      v
Enterprise API
      |
      v
Dynamics 365 transaction
      |
      v
Audit + result

For higher-impact processes, the preferred tool may create or prepare a transaction rather than complete the final posting action autonomously.

Observability

The useful audit chain should correlate:

• user or workload identity
• agent/run identifier
• MCP server
• tool name and version
• validated arguments
• approval outcome where applicable
• downstream request identifier
• Dynamics 365 business transaction identifier
• outcome and error details

Prompt text should not automatically be treated as the primary audit record. The durable audit unit is the business action and its validated parameters.

Failure handling

The MCP server should normalise downstream errors into tool-level outcomes that are useful to both the agent and operators.

It should distinguish at least:

• invalid tool input
• authentication failure
• authorization failure
• business validation failure
• downstream service unavailable
• duplicate/idempotency conflict
• approval rejected or expired

Retries must be designed around the semantics of each operation. A generic retry policy is dangerous for non-idempotent business actions.

Current status

Research.

The architecture pattern is defined, but no claim is made that the full reference implementation has been validated against a production Dynamics 365 environment. The next Lab stage is a read-only prototype with a deliberately small tool catalogue, followed by controlled write scenarios.

Production questions still to validate

• Which Dynamics 365 operations provide sufficient standard service coverage?
• Where are custom services justified rather than OData data entities?
• Which tool calls need user-context identity versus workload identity?
• Where should approval execute: agent platform, MCP layer, workflow engine or Dynamics 365?
• What telemetry correlation works across the agent, MCP server, integration layer and ERP transaction?
• What throttling and concurrency limits are appropriate for agent-driven workloads?

Microsoft references

• Service endpoints overview for finance and operations apps
• Custom service development for finance and operations apps
• Manage business event endpoints
• Using MCP tools with Microsoft Agent Framework

The reference architecture will be revised as the prototype produces implementation evidence.