How to build an MCP server for Microsoft Dynamics NAV
Short answer
An MCP server for NAV is a small service that wraps NAV web services or a read-only SQL replica as named tools, such as item lookup, order status and BOM where-used. Any MCP client, including Claude and ChatGPT, can call them. Start read-only, authenticate with a scoped service account, and log every call.
The Model Context Protocol gives AI clients a standard way to call tools. For Dynamics NAV, this is attractive because NAV integration knowledge is scarce: one team builds the NAV-facing tools once, and any compliant client can use them.
NAV does not provide an MCP endpoint itself, and many installs are older than the oldest web service features you might hope for. So the MCP server is where you absorb version differences, per-company table quirks, and your own customizations, presenting clean tools upstream.
This page is a design guide: what to expose, how to authenticate, how to choose transport, and how to keep it safe.
What teams use it for
Item and availability lookup
A tool takes an item number and a company, and returns description, unit of measure, inventory by location, reserved quantity and next expected receipt.
Sales and purchase order status
Tools return headers, lines, shipment and invoice status for a document number, including who last modified it.
BOM explosion and where-used
Walks Production BOM Header and Line tables, respecting certification status and version dates.
Open production order summary
Returns status, due date, routing progress and component shortages for a production order or a date range.
Vendor delivery performance
Computes on-time rate from receipt dates versus promised dates over a chosen window, with the underlying receipt numbers.
Customer credit and open balance
Returns balance, overdue amount and credit limit from Customer and Detailed Cust. Ledger Entry data for authorized roles only.
Microsoft Dynamics NAV integration surface
- Published web services: pages and codeunits exposed via the Web Services page. NAV 2013 and later support OData and SOAP; later releases also offer newer API styles. Check your version.
- SQL Server tables: Company$Item, Company$Sales Header, Company$Item Ledger Entry and so on. Good for aggregates, but only through a read-only login on a replica.
- Codeunit entry points: the safe write path when you eventually add actions, because they run NAV validation.
- Authentication modes: Windows, NavUserPassword and, in later versions, Azure Active Directory. The MCP server holds its own identity and maps callers.
- Multi-company: every tool needs an explicit company parameter or a default, since service URLs and table names are company specific.
How it works
- 1
Inventory questions and customizations
Interview planners, buyers and finance. Note extra fields and custom tables, since tools must surface them.
- 2
Design the tool contract
Each tool has a clear name, typed inputs, a short description for the model, and a bounded output size. Prefer many small tools over one query-anything tool.
- 3
Implement the NAV adapter
One module talks to NAV (web services first, SQL replica second). Everything above it is NAV-version agnostic, which eases a later move to Business Central.
- 4
Choose transport
stdio for local single-user use; streamable HTTP for a shared deployment. For HTTP, add TLS, authentication and request limits.
- 5
Add authorization
Map each caller to a NAV user or role. Check permission before returning rows, so the assistant never reveals more than NAV would.
- 6
Add audit and tests
Log tool, arguments, caller, row counts and duration. Write tests with a scrubbed copy of your database.
Example flows
Order status through any MCP client
Trigger: A user asks any connected assistant about sales order 1043.
- The client picks the get_sales_order tool and sends the order number and company.
- The server checks the caller's role and queries the sales order page service.
- It returns header, lines and shipment status as compact JSON.
- The assistant turns that into a plain answer and cites the document numbers.
Result: The same tool works in Claude, ChatGPT or an in-house chat window.
Shortage report on demand
Trigger: Production manager asks which orders are blocked this week.
- Client calls list_shortages with a date window.
- Server reads released Prod. Order Components with remaining quantity above available inventory.
- It groups by order and ranks by due date.
- Result returns with a note that availability ignores inbound supply unless requested.
Result: A quick, scoped answer with a clear stated assumption.
Keeping data on-prem
Because MCP is just a protocol, the server can sit on a host beside your NAV service tier and never touch the internet. Pair it with an on-prem model served by vLLM or Ollama and a local MCP-capable client or chat front end, and the whole loop stays inside your network. For clients that live in the cloud, expose only the HTTP endpoint through a gateway you control, and consider returning less detailed data from that path than from the internal one.
Security checklist
- Start with read-only tools and no codeunit writes; add writes later as proposals needing approval.
- Use least privilege NAV and SQL accounts, and a replica for SQL-based tools.
- Authenticate every HTTP call and tie it to a user identity, not a shared token.
- Return only needed fields, redact sensitive ones, and cap rows per call.
- Keep an immutable audit log of all tool calls.
Ways to get it done
Write your own MCP server
Effort: About 2 to 6 weeks for a dozen read-only tools.
In-house developers with NAV and Python or TypeScript skills.
Adapt an open-source MCP template or a generic OData MCP server
Effort: Days to configure, but expect to add custom logic for BOMs and permissions.
Simple needs and modern OData support in your NAV version.
Have a partner like Netray build and operate it
Effort: Scoped project over several weeks.
You want a tested toolset, audit, and an on-prem model to go with it.
Pitfalls
- !A generic run-any-SQL tool is a data breach waiting to happen. Use named, bounded tools.
- !Ignoring permissions because the server uses one service account.
- !Tools that return thousands of rows make assistants slow and wrong.
- !Hardcoding company names or table prefixes.
- !Not versioning the tool contract, so client prompts break after changes.
Frequently asked questions
Does Dynamics NAV have a built-in MCP server?
No, not that I know of. NAV predates MCP. You build a server that sits in front of NAV web services or a read-only replica. For Business Central there may be more ready-made options, so check current vendor offerings.
Which tools should we build first?
Item availability, order status, BOM where-used and open PO lines. They are read-only, widely useful, and easy to verify against the NAV client, which builds trust before you consider actions.
Should we use stdio or HTTP?
Use stdio for a developer testing on one machine. Use HTTP for shared production use, with TLS and authentication. HTTP also lets you centralize logging and permission mapping.
Can the same server work with ChatGPT and Claude?
Generally yes, if the client supports MCP. Client support and connector rules change, so verify each client's current requirements. The tools themselves stay the same.
How do we handle old NAV versions?
Put version differences inside the adapter layer. For older releases, rely on SQL replica reads and a few SOAP codeunits. The tool contract exposed to clients should not change when you upgrade NAV later.
More for Microsoft Dynamics NAV
Want MCP server working on your Microsoft Dynamics NAV?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment