# How to build an MCP server for Dynamics 365 Finance and Supply Chain

> Source: https://netray.co/integrations/dynamics-365-fscm-mcp-server
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Integrations

## Short answer

An MCP server for FSCM is a small service that turns bounded OData and custom service calls into named tools. Start read-only, authenticate with an Entra app mapped to a least-privilege FSCM user, pick stdio for local use or streamable HTTP for shared use, and log every call.

## System

Microsoft Dynamics 365 Finance and Supply Chain

## Capability

mcp-server

## Intro

FSCM exposes an enormous surface: hundreds of data entities, custom services and security-controlled forms. Handing that to a language model raw is a mistake. The Model Context Protocol gives you a place to say exactly which parts of that surface a model may use, how arguments are validated and what is returned.

The server is the contract. Claude, ChatGPT and other MCP clients all discover its tools in the same way, so the work is done once. That also means the quality of your tool design decides whether the model picks the right action, so names, descriptions and argument schemas deserve the same care as a public API.

Microsoft has also been developing MCP access for Dynamics 365 ERP. If that covers your needs it may save effort, but many manufacturers still write their own for custom entities, extension fields, stricter auditing or on-premises reach. This page describes the build.

## Use Cases

### Item and inventory lookup

**Description:** Tools such as search_released_products and get_on_hand by site and warehouse let any client answer stock questions without the user opening inventory on-hand forms.

### Order status across purchase and sales

**Description:** get_purchase_order_lines and get_sales_order_status return confirmed dates, quantities received and delivery status in a compact shape.

### BOM and where-used exploration

**Description:** get_bom_explosion and where_used tools return multi-level structures with a depth limit so a deep BOM does not flood the model.

### Production floor visibility

**Description:** get_production_order and list_shortages let supervisors ask about jobs in plain language.

### Controlled draft creation

**Description:** Later, a create_draft_purchase_requisition tool writes a draft that a buyer reviews, rather than a posted document.

## System Surface

- OData v4 data entities under the environment /data endpoint, with $select, $filter, $top and cross-company controls that the server should set, never the model.
- Custom X++ services at the /api/services path for operations that need business logic, with request and response contracts you define.
- Microsoft Entra ID app registration; the FSCM side maps the application ID to a user in a system administration form and assigns security roles.
- The $metadata document, useful for generating tool argument schemas and verifying that entity and field names exist in your version.
- Service protection limits and throttling headers returned by the platform, which the server should honour with back-off.
- For on-premises (local business data) deployments, authentication through AD FS and a different base URL pattern; confirm entity coverage for your build.

## How It Works

### Write the tool catalogue

**Detail:** List each tool with a verb-first name, a plain description of when to use it, typed arguments and a fixed return shape. Start with eight to twelve read tools.

### Build the FSCM client layer

**Detail:** Implement token acquisition and caching with the Microsoft identity platform, retry with back-off on throttling, and a fixed row cap on every query.

### Map tools to bounded queries

**Detail:** Each tool builds its OData query from validated arguments with explicit $select lists. Reject unknown arguments and cross-company queries unless the tool allows them.

### Choose transport

**Detail:** Use stdio for a developer running a local client against their own credentials. Use streamable HTTP behind your gateway for shared use, with authentication on the MCP endpoint itself.

### Scope permissions

**Detail:** Create separate FSCM users and roles for read-only and draft-write tool groups, and expose them as separate servers or separately authorised toolsets.

### Add audit and metrics

**Detail:** Log caller, tool, arguments, entity keys returned, latency and throttling events to a store your security team can query.

### Test with multiple clients

**Detail:** Try the server in Claude, ChatGPT where supported, and an open-weight model client. Tool descriptions that work for one often need tuning for another.

## Example Flows

### Inventory question end to end

**Trigger:** A user asks a client, how many of item A-1042 are in warehouse 12?

**Steps:**

- Client lists tools and selects get_on_hand.
- The server validates item and warehouse, builds a bounded OData query.
- It returns physical, reserved and available quantities with the as-of time.

**Result:** A sourced answer, with the call visible in the audit log.

### Draft requisition with approval

**Trigger:** A planner approves an agent's suggestion to buy a shortage item.

**Steps:**

- The client calls create_draft_requisition with item, quantity and date.
- The server checks the write toolset is authorised for the caller.
- It creates a draft via a service and returns the identifier.
- The buyer reviews the draft in FSCM before submitting.

**Result:** Automation of the keystrokes, with a person still owning submission.

## On Prem

The MCP server is just a service, so it can sit in your network next to an on-premises FSCM deployment or in a private network peered to your cloud environment. Pair it with a model that also lives inside the boundary, such as an open-weight model served by vLLM or Ollama, and no prompt or extracted row leaves. For on-premises FSCM, use your identity provider (typically AD FS) for the token flow, check that the data entities you want are present in your build, and plan for a slower upgrade cadence than the cloud service.

## Security

- Never provide a generic query tool that accepts raw OData filter strings from the model.
- Use separate credentials and roles for read and write toolsets, and keep write tools off by default.
- Authenticate the MCP endpoint itself when using HTTP, and restrict network reach to the gateway.
- Enforce row caps and field allow lists so a single call cannot dump a table.
- Sanitise returned free-text fields and treat them as untrusted input that may contain injected instructions.

## Options

### Adopt a Microsoft-provided Dynamics 365 ERP MCP server if it fits

**Fit:** Good where standard entities are enough and your policies allow the hosted component.

**Effort:** Configuration and security review.

### Build and run your own server

**Fit:** Best for custom entities, strict auditing, on-premises reach, and consistent tool design across clients.

**Effort:** Two to four weeks for a read-only set, plus review.

### Have a partner such as Netray build it with an evaluation harness

**Fit:** Useful when you also need a private model and want measured tool-calling accuracy before rollout.

**Effort:** Scoped pilot, usually combined with a chosen agent or chat use case.

## Pitfalls

- Exposing too many tools; models pick worse when the list is long and overlapping.
- Returning wide rows with every field, which wastes context and leaks data you did not intend to share.
- Letting the model supply the company, so answers cross legal entity lines.
- Ignoring throttling and causing slowdowns for interactive FSCM users during a busy batch window.
- Hard-coding entity names that differ across versions instead of checking $metadata.

## Faq

### What is the minimum useful MCP toolset for FSCM?

**Answer:** Item search, on-hand by site and warehouse, purchase order lines with confirmed dates, sales order status, production order detail with BOM lines, and vendor or customer lookup. That covers most operational questions. Add write tools only after the read tools are measured and trusted.

### Which transport should we use?

**Answer:** Stdio suits a developer running a local client with their own credentials. For shared use by many people, run the server over HTTP behind your gateway, authenticate the endpoint, and map callers to scoped FSCM credentials. Avoid a single powerful shared secret.

### How does authentication to FSCM work?

**Answer:** In the cloud service you register an application in Microsoft Entra ID, map its client ID to a user inside FSCM, and assign security roles. The server uses client credentials or a delegated flow to get tokens. On-premises deployments typically use AD FS instead.

### Can the same server work with ChatGPT and Claude?

**Answer:** Yes, that is the purpose of MCP, although client support for remote servers and authentication differs by product and plan. Keep tool descriptions plain and schemas strict, and test each client. A private model that supports tool calling can use it too.

### Should we write tools over OData or custom services?

**Answer:** Use OData for lookups and lists because it is standard and easy to bound. Use custom X++ services when an action must run business logic or validation, such as creating a draft document. Mixing both is normal; keep the choice hidden behind the tool name.

## Search terms

dynamics 365 finance and supply chain mcp server, mcp server dynamics 365 f&o, model context protocol dynamics 365, d365 fscm mcp, build mcp server for erp odata, dynamics 365 erp mcp tools, mcp server dynamics 365 on premises, dynamics 365 mcp claude chatgpt, mcp odata data entities, dynamics 365 fscm ai tools api

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
