How to connect Claude to Microsoft Dynamics AX 2012
Short answer
Claude reaches AX 2012 through a connector you build, typically an MCP server that wraps read-only SQL views and AIF services. Claude can then run through Anthropic, AWS Bedrock or Google Vertex, or you can substitute a local open-weight model if the data must stay on-prem.
Teams on AX 2012 who try Claude usually start with documents: contracts, vendor correspondence, long engineering change notes. Claude's long context handles these well. The harder step is connecting it to live AX data, because AX has no public REST API and sits on a private network.
The common modern route is a Model Context Protocol server. It presents AX questions as named tools that Claude can call, with parameters and typed results, while your code handles authentication and filters. The same server can later serve other MCP clients, so the work is not Claude-specific.
Where Claude runs is a separate decision from how it connects. You can call the Anthropic API directly, use a cloud provider route such as AWS Bedrock or Google Vertex AI if your organisation already contracts with them, or keep everything local with a different model. Each has different data-handling and residency implications that you should verify against current terms.
What teams use it for
Reading long vendor agreements against AX terms
Claude compares a supplier contract's payment terms and lead times with the vendor record and purchase history pulled from AX, and lists mismatches for procurement.
Engineering change impact summaries
Given an ECO document and BOM data pulled through a tool, Claude explains which open production orders and sales orders carry the affected item.
Plain-language answers about order status
A salesperson asks "where is Acme's order" and Claude uses an order-status tool to answer with line-level detail and a short explanation.
Cleaning item master descriptions
Claude reviews INVENTTABLE item names and descriptions in batches, proposes consistent wording and flags probable duplicates for a data steward to approve.
Drafting responses to customer quality queries
With lot, receipt and production order trace data supplied by tools, Claude drafts a factual reply that the quality engineer reviews before sending.
Microsoft Dynamics AX 2012 integration surface
- AIF services through inbound ports on IIS using WCF/SOAP, usable from a .NET or Python MCP server for document-level reads and controlled writes.
- AX 2012 query service and the .NET Business Connector, which go through AX business logic and security but open an AOS session per call.
- SQL Server read-only views over core tables with DATAAREAID and PARTITION handled in the view, the lowest-friction path for MCP read tools.
- SSRS reports and SSAS cubes shipped with AX, which can act as pre-aggregated sources for questions about totals and trends.
- File drops and SQL Server Agent jobs for exporting document attachments or reports to a store that Claude-based tools can read.
How it works
- 1
Choose where Claude will run
Compare the Anthropic API, AWS Bedrock and Google Vertex AI against your existing cloud contracts, data residency needs and logging requirements. Confirm current terms with each provider, since they change.
- 2
Stand up an MCP server inside your network
Write it in a language your team supports. It connects to SQL views and AIF, and exposes tools like get_purchase_order, list_late_lines and get_bom. Start with read-only tools.
- 3
Pick a transport
Use stdio for a local desktop client on the same machine. Use an authenticated HTTP transport for a shared server so several users connect without installing anything on their laptops.
- 4
Map identity
Authenticate the user to the MCP server, for example via your identity provider, and scope tools by role. Avoid one shared super-account for everyone.
- 5
Write tool descriptions carefully
Clear names, parameter descriptions, units and examples matter more than clever prompts. Include the legal entity as an explicit parameter.
- 6
Test on real questions
Collect twenty actual questions from planners and buyers, run them, and compare answers with AX inquiries before rolling out.
Example flows
Contract versus system check
Trigger: A buyer uploads a renewed supplier agreement and asks Claude to check it.
- Claude reads the PDF text supplied to it.
- It calls get_vendor_terms and get_recent_purchase_lines through the MCP server.
- It compares payment terms, price breaks and lead times.
- It lists differences and proposes which AX fields to update, without changing anything.
Result: The buyer spots a payment term mismatch before the first invoice, and updates AX through the normal vendor form.
ECO impact question
Trigger: Engineer asks which open orders use component X-4421.
- Claude calls a where-used tool against the BOM tables.
- It calls an open production orders tool for the parent items.
- It calls a sales order lines tool for committed deliveries.
- It summarises affected orders ordered by due date.
Result: The change board sees the real exposure in one answer, with the order numbers listed.
Keeping data on-prem
If policy or contract says data cannot go to a cloud model, keep the MCP server and the AX connectivity exactly as designed and replace the model with an open-weight one served by vLLM or Ollama on your own GPUs. Because MCP is an open protocol, the tool layer you built carries over. Expect to test carefully: smaller local models can be weaker at long documents and complex tool sequences than a frontier hosted model, so match the model to the question. A hybrid is also reasonable, with sensitive questions handled locally and general document work done through a cloud route you have approved.
Security checklist
- Keep AX credentials on the MCP server, never in the client or prompts, and use a least-privilege SQL login and service account.
- Scope tools by user role so a buyer cannot ask for payroll or customer pricing they would not see in AX.
- Log tool calls with user, parameters and row counts, and review them periodically.
- Treat text from documents and emails supplied to Claude as untrusted, because embedded instructions can try to trigger tool calls.
- Start with read-only tools and add any write tool only with an approval step in the flow.
Ways to get it done
Build an MCP server yourselves
Effort: Two to four weeks for a handful of read tools including security review.
You have a developer comfortable with SQL Server, AIF or the Business Connector and an MCP SDK.
Use a generic database or SQL MCP server against views
Effort: Days, but less control over parameters and weaker guardrails.
A quick prototype where raw SQL on curated views is acceptable internally.
Partner such as Netray for a governed, optionally on-prem build
Effort: A pilot over a few tools, then expansion by use case.
You need role scoping, audit logs and a local model option without building it all in-house.
Pitfalls
- !Giving a generic SQL tool to Claude over the raw database, which invites wrong joins and cross-company leakage.
- !Forgetting that AX enum fields are stored as integers, so answers show codes rather than meaning.
- !Returning huge result sets as tool output instead of summaries, which wastes context and degrades answers.
- !Using one shared service identity so audit trails cannot say who asked what.
- !Assuming a cloud route is automatically compliant with your customer contracts without checking the terms.
Frequently asked questions
Is there an official Claude connector for AX 2012?
I am not aware of one. AX 2012 is on-premises and out of active development, so the practical route is your own MCP server in front of AX data. MCP is an open protocol, so the server you build can be reused with other clients as well as Claude.
Should I use the Anthropic API, Bedrock or Vertex?
Pick the one that matches your existing cloud agreements, residency needs and logging. The model behaviour is similar across them, though features and availability can differ by route. Review each provider's current data-handling terms before sending any ERP-derived content.
Can Claude run entirely on-prem for AX?
Claude itself is a hosted model, so for a fully on-prem setup you would use a different, open-weight model with the same MCP tool layer. If your policy allows a private cloud route, that may be an intermediate option, but verify the terms for your situation.
Why MCP rather than a custom plugin?
MCP separates your AX knowledge from any one assistant. You define tools once, with authentication and logging in your own code, and any MCP-capable client can use them. A bespoke plugin tends to lock you to a single vendor's format.
How accurate will it be on AX data?
Accuracy depends mostly on your tool design. Well-named tools returning clean, labelled results give reliable answers; open-ended raw SQL gives unreliable ones. Always verify new tools against known AX inquiry results before staff rely on them.
Want Claude working on your Microsoft Dynamics AX 2012?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment