What I Found When I Built My Own MCP Server Against D365

Why I Built It

In May 2026 I watched Patrick Mouwen, our Principal Architect at 365Connect, present a live demo of an AI agent taking real actions inside a D365 Commerce environment at DynamicsMinds in Slovenia.

Not a chatbot. Not a suggestion engine. An agent completing actual B2B commerce workflows - pricing, orders, master data - through a governed API layer our team had built.

The room was engaged. I was engaged. And I left with a question I could not answer from watching: what does it actually feel like to build one of these, and what do you find when you do?

I am a Programme Manager. I am not a developer. I have never written production code in a professional capacity. But I have spent eighteen years inside technology programmes, and I have learned that there is a category of understanding that only comes from doing - from sitting in front of a blank terminal and making something work, rather than reading about it or watching someone else.

So when I got home from Slovenia, I built one myself.

Not to publish a tutorial. Not to claim technical credit alongside the people who build these things professionally. To understand, from the inside, what the barriers actually are - because my job is to help organisations navigate those barriers, and I wanted to know what I was talking about.

What I Built

The project is called APEX. It is a TypeScript MCP server with seven tools, exposing Dynamics 365 Finance and Operations data through OData APIs.

It runs on Azure Container Apps in West Europe, authenticated via Azure Entra ID OAuth2 with two separate service principals - one for reading, one for writing - and it connects to Claude Desktop.

The seven tools cover the operations a finance or supply chain team would actually use: searching vendors, querying open purchase orders, checking inventory levels by site, pulling a financial summary from general ledger journals, surfacing overdue vendor invoices, retrieving customer balances, and creating draft purchase orders.

The constraint on that last one is deliberate: the server can create a draft purchase order, but it cannot submit one for approval. That was a governance decision, not a technical limitation. I will come back to why.

I built on Microsoft's Contoso USMF sandbox - the standard pre-seeded demo environment that comes with D365. Every vendor record is clean. Every price line exists. Every field is correctly populated. I chose it precisely because I wanted to start with the best possible data before introducing any real-world complexity.

It took a week.

TypeScript / Node.js v24 MCP SDK v1.29.0 D365 F&O v10.0.46 Azure Entra ID OAuth2 Claude Desktop

What I Actually Encountered

I want to be specific here, because the generalities about AI being "hard to implement" are not very useful.

What is useful is knowing exactly where it gets hard and why.

01

The field names were not what I expected

D365 Finance and Operations uses specific OData entity names and field names that do not always match what you would assume from the D365 user interface or documentation. The entity for inventory on-hand is not called InventoryOnHand. It is called InventoryOnHandForAI in the form I needed, and the field names within it do not match the labels visible in the D365 interface.

Every time I called an OData entity with the wrong name, the API returned a 400 error. The AI would attempt the query, get back an error, and have nothing useful to return. The AI was not wrong. My tool definitions were pointing at fields that did not exist.

I had to build a separate discovery utility - a script that queries the D365 OData metadata endpoint directly and returns the real entity and field names - before I could correctly define what the AI had access to. Without it I would have been guessing indefinitely.

This was on clean, fully populated, Microsoft-provided demo data. Every record correct. The problem was not data quality. It was the gap between what the documentation implied the fields were called and what they were actually called in the environment.

02

The data types were not what I assumed

The purchase order status field in D365 is not a string. It is an enum type. When I wrote a tool that filtered purchase orders by status using string logic, the API rejected the filter. The AI was applying logic that would be correct in most contexts. The D365 data model had a specific requirement that was not obvious from the field name alone.

The result was that queries which should have returned a filtered set of purchase orders returned nothing, or returned an error. Again: not an AI failure. A data model assumption that was wrong.

03

The data existed but was invisible in the wrong scope

When I built the tool to create a draft purchase order, the vendor could not be found. The vendor account I was querying existed in D365. But the cross-company OData query was returning results from a different legal entity - a different dataAreaId - and in that context, the vendor did not exist.

Adding the company scope explicitly to the query - specifying dataAreaId: 'usmf' in the POST body - resolved it immediately. The data was there the whole time. The context was wrong.

"Three data-layer failures. On Microsoft's own demo data, with every record clean, every field populated, every entity pre-configured."

What This Told Me About Readiness

Three data-layer failures. The failures were not about data quality in the conventional sense - dirty records, missing values, inconsistent entry.

They were about field naming conventions, data type specifics, and company scope logic that only became visible when something outside the system tried to act on the data.

A human user of D365 navigates these things invisibly. The interface handles the translation. The filter is applied through a dropdown, not a programmatic enum call. The company context is set by the session, not specified in a query body.

When the AI tries to do the same things, it has to specify everything explicitly, based on descriptions that someone has written. If those descriptions are incomplete, ambiguous, or wrong, the AI does not guess. It acts on what it has been told, and it returns whatever that produces.

Only around 7 percent of enterprises say their data is fully ready for AI. I read that figure before I built APEX. After building it, I understand what it means more concretely. The readiness question is not just whether your records are complete. It is whether the structure, the naming, the types, and the context of your data have been described accurately enough for a machine to act on them correctly - and in a live D365 estate with years of customisation, configuration changes, and process evolution behind it, that is a genuinely significant amount of work.

The Governance Decision I Had to Make

I want to return to the draft purchase order constraint, because it is the most interesting thing I built.

The tool creates a purchase order in draft status. It will not submit it for approval. That is not because the MCP protocol cannot do it, or because D365 does not have an API for workflow submission. It is because I decided it should not.

A draft purchase order is visible in D365. A human can review it, change it, approve it, or delete it. Nothing commits until a person looks at it. The AI's action is reversible.

A submitted purchase order has entered the approval workflow. It may trigger notifications, update demand planning, create downstream records. Unwinding a submitted order requires deliberate human action. The cost of a wrong submission is higher than the cost of a wrong draft.

When I was building the write governance for APEX, I had to think through what a non-human actor should be permitted to do in a live ERP system - not as a compliance exercise, but as a real design question. Where is the line between what the AI can do autonomously and what requires a human in the loop? What are the consequences if it does the wrong thing on either side of that line?

These are not questions that have obvious answers. They depend on the business process, the data quality, the audit requirements, and the organisation's tolerance for automated action at different stages of a workflow. The interesting thing is that most AI readiness conversations I observe do not get to these questions at all. They are focused on which model to use, which vendor to select, which use case to pilot.

"The governance layer - who controls what the AI can and cannot do - is treated as something to design later. It is not something you can design later. It has to exist before the AI acts, not after."

What the Build Produced

By the end of the week, six of six Postman endpoint tests were passing.

The AI was querying live D365 data and returning accurate results. The $select optimisation on the purchase order query reduced response time by 20 percent. The draft purchase order tool was creating correctly scoped records in the USMF entity.

The carousel below shows the actual output - real queries against a live D365 F&O environment, the responses as Claude returned them. The vendor list, the open purchase orders, the inventory levels, the financial summary, the overdue invoices, the customer balances, the draft PO creation. And the final slide: what happens when you ask the AI to submit the PO for approval.

APEX MCP · D365 F&O · Live Output

I typed plain English.
D365 answered.

Natural language queries against a live D365 F&O environment via a custom MCP server.

Step through to see every query and the real D365 response.

What vendors do we have?

What vendors do we have in the system?

Loaded tools, used APEX MCP integration

Here's a full list of the vendors currently in the system (50 returned):

Commercial Suppliers (Group 10)

Account	Name	Currency
US_SI_000043	Guaranteed Sales and Service	USD
US_SI_000044	Hardware Components	USD
US_SI_000045	Industrial Supplies	USD
US_SI_000046	Local Hardware Factory	USD
US_SI_000048	Margle's Travel	USD
US_SI_000049	Parcel Express Delivery Service	USD
US-101	Fabrikam Electronics	USD
US-104	Fabrikam Supplier	USD
US-105	Datum Receivers	USD
DE-001	Opal Audio	EUR
JP-001	Contoso Chemicals Japan	JPY

What purchase orders are open?

GetOpenPurchaseOrders

Here's a summary of the open purchase orders. The ones that need the most attention are those still on Backorder — meaning goods haven't been fully received yet:

Backorder POs (action may be required)

PO Number	Vendor	Approval Status	Req. Delivery	Ccy
JPMF-000007	JPMF-000003	Confirmed	1 Feb 2013	JPY
JPMF-000008	JPMF-000005	Confirmed	1 Feb 2013	JPY
JPMF-000001	JPMF-000001	Approved	7 Feb 2013	JPY
JPMF-000002	JPMF-000002	Approved	7 Feb 2013	JPY
JPMF-000011	JPMF-000001	Confirmed	25 Feb 2013	JPY

Invoiced POs (awaiting final processing)

The remaining 45 orders are in Invoiced status — confirmed and invoiced but still technically open. The bulk of these are USD orders (000273–000313) from 2015, alongside a few JPY orders. Worth noting: the backorder POs are quite old (2013) — it may be worth reviewing whether these should be closed or followed up on.

50 vendors returned, live. Open POs flagged by status. One question each. Zero SQL.

Which items are low on stock?

Which items are running low on stock at site 1

Loaded tools, used APEX MCP integration

Here's the stock situation at Site 1, focusing on items with actual warehouse stock. I've grouped them by concern level:

â— Out of Stock (0 units in all warehouses)

Item	Warehouse
T0002, T0003, T0004, T0005	WH 11
M0008, M0021	WH 11
P2000, P3000–P3005, P4000–P4002, P5006–P5009	WH 14

â— Very Low Stock (under 25 units)

Item	Warehouse	Qty
D0004	WH 13	1
D0001	WH 13	6
D0003	WH 13	9
L0001	WH 13	21

â— Low-ish Stock (under 100 units)

M0026 and additional items in WH 13 and WH 14 — scroll for full list.

Give me a financial summary

Loaded tools, used APEX MCP integration

General Journals (Operating Activity)

The three core general journal batches each balanced at $3,090,830.29 in debits and credits, indicating fully reconciled postings.

Payroll Summary (Jan–Jul 2025)

Month	Amount
January	$483,600.00
February	$480,168.00
March	$478,486.32
April	$475,156.61
May	$475,156.61
June	$475,156.61
July	$470,250.90
Total YTD	$3,337,975.05

Payroll has been on a gradual downward trend since January, dropping about $13,350 over 7 months — this could reflect headcount reductions, contract changes, or shift adjustments. All entries are fully balanced (debits = credits), which is healthy from a bookkeeping standpoint.

Inventory risk ranked by concern level. YTD payroll of $3.3M with declining trend flagged.

Any overdue vendor invoices?

Are there any overdue vendor invoices?

GetVendorInvoices

Yes, there are quite a few overdue vendor invoices — all sitting in Draft status, which means none have been formally approved or posted yet. Here's a breakdown by vendor:

Most Recent / Closest to Now

Invoice	Vendor	Due Date	Currency	Status
(blank)	Acme Office Supplies	11 Apr 2026	USD	Draft
D-Mt-I00014	Nestle	11 Mar 2026	INR	Draft
(blank)	Nestle	11 Mar 2026	INR	Draft
D-Mt-INV00013	Amul	11 Mar 2026	INR	Draft

Older Overdue (2016–2017)

Vendor	Invoice(s)	Due Date	Currency
General Associates	00000047_Inv, 00000159_Inv, others	Dec 2016	USD
Exconomics Part Supply	00000056_Inv, 00000168_Inv, #12	Dec 2016	USD
The Phone Company	2000007	Feb 2015/Dec 2016	USD
Accessories Network (FR)	(blank)	Dec 2017	EUR
Distant Inn	(blank)	Dec 2017	USD

Which customers owe us money?

GetCustomerBalances

Here's a summary of all customers with outstanding balances, using the most recent balance date figures. I've flagged those who are over their credit limit âš :

Account	Latest Balance	Credit Limit	Status
US-008	$1,448,350.65	$400,000	âš Over limit
US-009	$746,040.00	$1,000,000	Within limit
US-011	$690,243.57	$400,000	âš Over limit
US-012	$688,209.60	$400,000	âš Over limit
US-013	$685,911.20	$500,000	âš Over limit
US-001	$455,153.66	$570,000	Within limit
US-003	$392,523.01	$400,000	âš Near/over limit
US-002	$365,464.02	$665,500	Within limit
US-010	$330,721.19	$400,000	Within limit
US-023	$312,937.62	$500,000	Within limit
US-006	$218,215.00	$100,000,000	Within limit
US-004	$210,491.70	$700,000	Within limit

Overdue invoices grouped by urgency. Customer balances with credit limit breaches surfaced automatically.

Then the data pushed back.

Even on clean, pre-seeded sandbox data.

OData field names (400 error)

Root cause: D365 field names differ from what you assume

The AI called fields that did not exist in this environment. It had to be taught the real names via a metadata discovery script. Example: InventoryOnHandEntries, not InventoryOnHandForAI.

Enum type filter errors

Root cause: PurchaseOrderStatus is an enum, not a string

The AI filtered using string logic. D365 stores status as an enum type. Same field, different data type assumption — wrong results returned every time.

Vendor not found on PO creation

Root cause: Cross-company query returned wrong dataAreaId

The vendor existed in D365. The AI simply could not see it — because the company scope (dataAreaId) was not explicitly set. Data correct; context wrong.

APEX MCP · D365 F&O

This was Microsoft's own clean,
pre-seeded demo data.

Every vendor record complete.
Every field correctly typed.
Every company scope pre-configured.

And we still hit three data-layer failures before a single query worked correctly.

Now think about your live D365 estate.

Fields used inconsistently across legal entities.
Custom fields with no OData description.
Master data entered differently by different teams.

If the AI cannot trust what it reads, it cannot act correctly.

1 / 6

Live queries against a D365 F&O environment via the APEX MCP server. Step through to see each query and the real response — including what the data did when it pushed back.

The data in these outputs is Microsoft's demo data, not a real client estate. But the mechanism is real. The queries are real. The errors I encountered before getting to these outputs were real.

What I Took From It

I went into this build to understand the gap between watching an AI agent work and knowing what it actually requires.

I came out of it with something more specific than I expected.

The gap is not technical, in the sense that the tools are not difficult to use or the code is not achievable. The gap is descriptive. It is the work of accurately describing your systems - the entities, the fields, the types, the contexts, the rules, the constraints - in enough detail that a machine can act on them correctly and safely.

That work does not currently exist in most D365 estates. Not because anyone made a bad decision, but because it was never needed before. Humans can navigate D365 without it. Machines cannot.

The organisations that will get the most from agentic AI on their ERP estates are the ones that treat this descriptive work as a genuine investment - not a configuration task that happens alongside the AI deployment, but a prerequisite that happens before it. Field naming conventions documented. Data types mapped. Company scope logic explicit. Governance boundaries defined.

That is a different kind of readiness from what most AI readiness conversations address. And it is, in my experience of building APEX and of running delivery programmes for the past eighteen years, the part that gets skipped.

"The gap is not technical. It is descriptive. It is the work of accurately describing your systems in enough detail that a machine can act on them correctly and safely."

APEX Build Specifications

Component	Detail
Server	TypeScript / Node.js v24
MCP SDK	`@modelcontextprotocol/sdk` v1.29.0
D365 environment	Microsoft Dynamics 365 F&O v10.0.46 (PU70)
Legal entity	USMF - Contoso Entertainment System USA
Tools	7 (read: 6, write: 1)
Authentication	Azure Entra ID OAuth2 - two service principals (read/write separation)
Hosting	Azure Container Apps - West Europe
AI interface	Claude Desktop v1.5354.0 - custom connector
Write governance	Draft-only - `createDraftPurchaseOrder` enforces Draft status, cannot submit or approve
Full case study	Available on request

What I found when I built my own MCP server against D365

The field names were not what I expected

The data types were not what I assumed

The data existed but was invisible in the wrong scope

I typed plain English.
D365 answered.

Open to comparing notes on what
this actually involves

The field names were not what I expected

The data types were not what I assumed

The data existed but was invisible in the wrong scope

I typed plain English.D365 answered.

Open to comparing notes on whatthis actually involves

I typed plain English.
D365 answered.

Open to comparing notes on what
this actually involves