# How to build an MCP server for Microsoft Dynamics AX 2012

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

## Short answer

An MCP server for AX 2012 is a small service that exposes a few read-only tools (item, order, inventory, BOM) backed by SQL views or AIF, with per-user auth and audit. Any MCP client, including Claude and ChatGPT where supported, can then query AX without custom integration each time.

## System

Microsoft Dynamics AX 2012

## Capability

mcp-server

## Intro

Model Context Protocol gives AI clients a standard way to call tools. For AX 2012 this is attractive because there is no REST API to point a client at, and every earlier integration was bespoke SOAP or SQL. Writing one MCP server turns your AX knowledge into a reusable asset instead of a one-off script.

The design question is not the protocol, which is simple, but the tool surface. Too few tools and users get nothing useful; too many, or one generic query tool, and the model picks wrong or leaks data across companies. This page is a design guide for choosing tools, authenticating to AX, and running the server in a way an IT security team will accept.

## Use Cases

### Item and availability lookup

**Description:** A get_item tool returns description, unit, product dimensions and on-hand by warehouse from INVENTTABLE and INVENTSUM, so any client can answer stock questions.

### Order status across sales and purchasing

**Description:** Tools for sales order and purchase order status return header, line state, quantities and dates, replacing a trip through several AX inquiry forms.

### BOM and where-used exploration

**Description:** get_bom and where_used tools let engineers and planners navigate product structures from a chat client without opening the BOM designer.

### Production order shop-floor view

**Description:** A list_production_orders tool filtered by status and date lets supervisors ask what is released, late or waiting on material.

### Controlled data access for new apps

**Description:** Internal dashboards and bots call the same MCP tools, so the permission and logging logic lives in one place.

## System Surface

- SQL Server read-only views over core tables, with DATAAREAID and PARTITION made explicit parameters, the simplest backing store for read tools.
- AIF document services through inbound ports over WCF/SOAP on IIS, appropriate where you want AX validation or to perform a controlled write.
- Custom X++ service classes added to a service group for logic that does not exist as a standard service, such as an available-to-promise calculation.
- The .NET Business Connector for session-based access that honours AX security roles when per-user fidelity matters more than speed.
- Windows authentication and Active Directory, which AX 2012 uses for user identity and which your server can use to map the caller to an AX user.

## How It Works

### List the questions, then the tools

**Detail:** Collect fifteen to twenty real questions. Group them into five to eight tools such as get_item, get_inventory, get_sales_order, get_purchase_order, get_bom, where_used and list_production_orders.

### Define strict input and output schemas

**Detail:** Every tool takes an explicit legal entity and typed parameters, and returns labelled fields (resolve enums to text), with a maximum row count and a truncation flag.

### Implement against views first

**Detail:** Create the views in a separate schema, grant the server's login SELECT on that schema only, and test each query against known AX inquiry results.

### Choose the transport

**Detail:** Use stdio for local single-user testing. For a team, use an authenticated HTTP transport behind your reverse proxy with TLS, so clients connect to one managed server.

### Add authentication and scoping

**Detail:** Validate the caller's token from your identity provider, map them to a role, and enforce which tools and which legal entities that role may use.

### Add audit and rate limits

**Detail:** Write each call, caller, parameters and row count to a log table or SIEM, and rate limit to protect the AOS and SQL Server during business hours.

### Then consider writes

**Detail:** Add a write tool only as a proposal-returning action that creates a pending change for a human to approve, executed through an AIF service afterwards.

## Example Flows

### Stock check from any MCP client

**Trigger:** A user asks a connected assistant if item 10442 is in stock for a quote.

**Steps:**

- Client calls get_inventory with item, company and warehouse filter.
- Server reads the inventory view, resolves warehouse names and returns available physical and reserved quantities.
- Server logs the call with the user's identity.
- Client answers with quantities and the next expected receipt if a tool for that exists.

**Result:** A sales rep gets an accurate availability answer in seconds, from the same source as the AX inquiry.

### Where-used for a supplier quality alert

**Trigger:** Quality receives a supplier notice about a component.

**Steps:**

- Engineer asks which products use the component.
- Client calls where_used with the item and a depth limit.
- Client calls list_production_orders for those parents with open status.
- Engineer gets a list of exposed orders to contain.

**Result:** Containment starts the same hour, with the order list traceable to tool calls in the audit log.

## On Prem

The MCP server belongs inside your network, on a host that can reach SQL Server and the AOS or IIS endpoints, with outbound access only to your chosen model or none at all. Pair it with a locally served open-weight model and an internal chat client, and no ERP data leaves the site. For HTTP transport, terminate TLS at an internal proxy and authenticate with your identity provider. If remote staff or cloud clients need access, publish through a gateway with strong auth rather than opening database or AOS ports. Keep the server stateless so you can run a second instance for resilience.

## Security

- Use a least-privilege SQL login limited to a dedicated view schema, and never reuse an AX admin or the AOS service account.
- Enforce legal entity and role checks in server code, not in prompts or client configuration.
- Cap result sizes and strip columns users should not see, such as bank accounts and cost prices, for roles that lack them in AX.
- Log every call and review unusual patterns such as bulk reads outside working hours.
- Validate all parameters as typed values and use parameterised queries to avoid injection through model-generated arguments.

## Options

### Build with an official MCP SDK in .NET or Python

**Fit:** A developer who knows AX data and wants full control of tools and auth.

**Effort:** Two to four weeks for a first set of read tools.

### Generic SQL or database MCP server against curated views

**Fit:** Internal prototype where free-form SQL on safe views is tolerable.

**Effort:** Days, with weaker guardrails and a higher chance of wrong answers.

### Partner such as Netray to design the tool surface and run it on-prem

**Fit:** You want audited, role-scoped tools and a local model without staffing the build.

**Effort:** A pilot of five to eight tools, extended by use case.

## Pitfalls

- A single run_sql tool. Models write plausible but wrong joins, and you lose the ability to scope or audit meaningfully.
- Forgetting that dimension and inventory transaction tables are large, so unindexed queries can hurt the live AOS and SQL instance.
- Returning internal field names and enum integers without translation.
- Mixing legal entities in one result because DATAAREAID was optional.
- Exposing the server to the internet before authentication and rate limiting exist.

## Faq

### What is an MCP server in this context?

**Answer:** It is a service that presents AX capabilities to AI clients as named tools with typed inputs and outputs, using the Model Context Protocol. The client asks the server to run a tool, the server queries AX, and returns structured results the model can use in its answer.

### Which tools should I build first?

**Answer:** Start with read-only lookups people ask for daily: item and inventory, sales order status, purchase order status, BOM and where-used. These are low risk and easy to verify. Add more only when real questions show a gap, and keep writes for last.

### SQL views or AIF for the backend?

**Answer:** Views are quicker and lighter for reads, and fine when you control access in the server. AIF and the Business Connector apply AX logic and security, which matters for writes and for per-user permissions. Many servers use views for reads and AIF for approved writes.

### Does it work with clients other than Claude?

**Answer:** Because MCP is an open protocol, any client that supports it can use the server. Support varies by product and plan, so check what your chosen clients allow, including whether they can reach a server on your private network.

### How do I audit what the AI did?

**Answer:** Log each tool call at the server with user, tool, parameters, row count and time. The server is the natural audit point because every access to AX passes through it, regardless of which client or model made the request.

## Search terms

dynamics ax mcp server, mcp server for dynamics ax 2012, model context protocol dynamics ax, build mcp server erp on-prem, dynamics ax 2012 mcp tools, mcp sql server erp read only, dynamics ax aif mcp, mcp server legacy erp, dynamics ax ai connector, mcp dynamics ax claude chatgpt

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