# How to build an MCP server for Infor XA

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

## 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.

## System

Infor XA (on IBM i)

## Capability

mcp-server

## Intro

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.

## Use Cases

### Item and availability lookup

**Description:** 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

**Description:** 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

**Description:** Open PO lines by supplier, promise versus need date and receipts to date, supporting buyer chase workflows.

### Bill of material and routing explosion

**Description:** 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

**Description:** Released order status, operations completed and component issue status to answer where a job stands.

### Data dictionary and definitions

**Description:** A documentation tool that tells the client what a status code means at your site, which prevents wrong guesses about codes.

## System 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

### Write the tool catalogue before code

**Detail:** 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.

### Build the SQL views

**Detail:** 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.

### Pick the SDK and transport

**Detail:** 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.

### Implement connection and safety limits

**Detail:** 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.

### Add authentication and tool scoping

**Detail:** 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.

### Add audit logging and tests

**Detail:** 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.

### Pilot with two clients

**Detail:** 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?

**Steps:**

- 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

**Steps:**

- 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.

## 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

- 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.

## Options

### Write it yourself with an MCP SDK and jt400

**Fit:** Teams with a developer comfortable with Db2 for i and a defined list of questions.

**Effort:** Two to four weeks for a first read-only version with tests.

### Adapt an open-source database MCP server

**Fit:** Internal technical users exploring the schema.

**Effort:** Hours to start, but generic SQL tools lack business meaning and need heavy restriction.

### Have Netray or another partner build and operate it

**Fit:** You want governed tools, a local model alongside and audit from day one.

**Effort:** A scoped pilot, with your team supplying definitions and acceptance tests.

## 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.

## Faq

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

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

infor xa mcp server, mcp server for infor xa, mcp server ibm i db2, model context protocol as400 erp, build mcp server for legacy erp, mcp jt400 db2 for i, infor xa model context protocol, mcp server manufacturing erp on-prem

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