How to build an MCP server for Infor XA
Short answer
An MCP server for Infor XA is a small service that connects to Db2 for i with a read-only profile and exposes named tools such as item availability and PO status to any MCP client. Start read-only, keep tools narrow, authenticate users, and log every call. It then works with Claude, ChatGPT and local models alike.
If you only build one thing to make XA usable by AI, build this. A Model Context Protocol server is the adapter: it knows how to talk to your IBM i and describes what it can do in a form that AI clients understand. Once it exists, adding a new client is a configuration task rather than a new integration.
The design discipline matters more than the code. XA's data model is large and its field names are terse, so an MCP server that simply exposes SQL gives clients a loaded weapon. A good server exposes a dozen carefully named tools, each doing one business-meaningful thing, with the joins, unit conversions and status filters already handled inside.
This page covers tool selection, how to reach XA, transports, authentication and audit. It assumes read-only first, because that is where you learn what your data really looks like before anyone lets software change it.
What teams use it for
Item and availability lookup
A tool returning on-hand, allocated, on order and available by warehouse for an item, so any client can answer stock questions consistently.
Order and shipment status
Customer order header and line status, ship dates and carrier references for customer service questions, without giving access to cost data.
Purchase order and supplier status
Open PO lines by supplier, promise versus need date and receipts to date, supporting buyer chase workflows.
Bill of material and routing explosion
A tool that returns a multi-level BOM for an item as of a date, with quantity per and scrap, for engineering and planning questions.
Shop order progress
Released order status, operations completed and component issue status to answer where a job stands.
Data dictionary and definitions
A documentation tool that tells the client what a status code means at your site, which prevents wrong guesses about codes.
Infor XA (on IBM i) integration surface
- Db2 for i through the jt400 JDBC driver (Java, or via Python and other wrappers) or ODBC from IBM i Access. This is the main read path, and the one most MCP servers for XA will use.
- SQL views and user-defined table functions in a dedicated library hold the business logic: status filters, UOM conversion and date logic. The MCP tools call these, not raw files.
- Existing RPG or service programs can be wrapped as SQL stored procedures or published with IBM i Integrated Web Services so a tool can call the real business rule. File and field names differ by XA release and customisation, so map yours rather than relying on a generic guide.
- Authority: IBM i object authority and, where needed, row and column access control (RCAC) in Db2 for i, so database permissions back up the tool-level permissions.
- Change capture: journaling and data queues can drive resource subscriptions or cache invalidation if your client supports it.
How it works
- 1
Write the tool catalogue before code
List ten to fifteen questions users ask, and design one tool per question with explicit inputs and a compact response. Names should read like business verbs, such as get_item_availability, not query_table.
- 2
Build the SQL views
Create views for each tool in a dedicated library. Test them against known XA screens so the numbers match. Add indexes where the tool filters.
- 3
Pick the SDK and transport
Use an official MCP SDK in TypeScript, Python or Java. Use stdio for a developer's own desktop and streamable HTTP for a shared team server behind a gateway.
- 4
Implement connection and safety limits
Pool JDBC connections under a read-only profile, enforce row limits and query timeouts, and refuse any input that is not validated against a schema.
- 5
Add authentication and tool scoping
For HTTP, use OAuth or your identity provider, map users to roles, and hide tools a role should not see, such as cost-related ones.
- 6
Add audit logging and tests
Log user, tool, arguments and row count to a store outside the IBM i. Write regression tests that compare tool output with known results from XA.
- 7
Pilot with two clients
Connect one hosted client and one local-model client to confirm the tools behave sensibly across models, and tune descriptions where models misuse a tool.
Example flows
Stock question through any MCP client
Trigger: User asks: can we ship 200 of item 55-210 this week?
- Client calls get_item_availability with the item and warehouse.
- Server queries the availability view and returns on-hand, allocated and inbound by date.
- Client works out the answer and states which receipts it relied on.
Result: The same correct number appears in every client because the logic lives in the view, not the prompt.
Engineering BOM check
Trigger: Engineer asks which assemblies use component 77-014
- Client calls where_used with the component and effective date.
- Server runs a recursive query over the structure file with an upper limit on depth.
- Result lists parent items and quantity per, with a flag for obsolete parents.
Result: An impact list for an engineering change in seconds, with the depth limit visible so it is not mistaken for complete.
Keeping data on-prem
An MCP server is a natural fit for on-prem because it is just a process that talks to the IBM i on your network. Run it on a Linux or Windows host in the same segment, or on the IBM i itself under PASE if your team prefers, with no inbound internet. Local models connect over your internal network, and hosted clients, if you allow them at all, connect through a gateway that you control and can switch off. For air-gapped plants, package the server and its dependencies as an internal artifact and deploy with approved media.
Security checklist
- Run the server under a read-only IBM i profile with authority on views only; never reuse a human or admin profile.
- Validate every argument against a schema and use parameterised queries, so no client text becomes SQL.
- Scope tools by role and keep cost, margin and rate data in separate tools that most roles never see.
- Cap row counts, depth and runtime per call to protect IBM i performance and limit data exposure.
- Keep an immutable audit log off the IBM i with user, tool, arguments and result size.
Ways to get it done
Write it yourself with an MCP SDK and jt400
Effort: Two to four weeks for a first read-only version with tests.
Teams with a developer comfortable with Db2 for i and a defined list of questions.
Adapt an open-source database MCP server
Effort: Hours to start, but generic SQL tools lack business meaning and need heavy restriction.
Internal technical users exploring the schema.
Have Netray or another partner build and operate it
Effort: A scoped pilot, with your team supplying definitions and acceptance tests.
You want governed tools, a local model alongside and audit from day one.
Pitfalls
- !Offering a run_sql tool. It is the fastest way to leak cost data and the slowest way to get correct answers.
- !Too many overlapping tools, which confuses models. Keep the catalogue small and descriptions precise.
- !Returning huge result sets. Models perform worse and you leak more; paginate and summarise server-side.
- !Forgetting company, warehouse or facility filters that XA uses to separate entities, leading to cross-entity answers.
- !Treating write tools as a minor extension. Add them only with staging and human approval.
Frequently asked questions
What is an MCP server in this context?
It is a service that exposes named tools over a standard protocol so AI clients can call them. For XA, the tools wrap read-only queries over Db2 for i. The client decides when to call a tool, and the server controls exactly what each tool can return.
stdio or HTTP transport?
Use stdio for a single developer testing on a desktop, since the client launches the server locally. Use HTTP for shared team use, where you can put authentication, rate limits and logging in front. Production for business users should be HTTP behind your gateway.
Can the MCP server write to XA?
It can, but start without it. If you add writes, make tools create proposals in a staging table that a person approves, then run existing XA programs. Never give a model free-form update access to production files.
Which clients will work with it?
Any client that supports MCP, including Claude, ChatGPT where connectors are enabled, IDE assistants and local-model front ends. Features differ per client and plan, so test each one. The server code stays the same.
How does this differ from a REST API?
A REST API is for programs written by developers who read the docs. An MCP server describes its tools in a way a model can pick and use at runtime. You can build both on the same SQL views; the MCP layer adds discovery and tool descriptions.
More for Infor XA (on IBM i)
Want MCP server working on your Infor XA (on IBM i)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment