How to build an MCP server for JD Edwards World
Short answer
An MCP server for World is a small service that turns vetted DB2 for i views into typed tools (item lookup, order status, availability, BOM) and runs outside the IBM i. Start read-only, authenticate every user, log every call, and any MCP client can use it.
Model Context Protocol gives AI clients a standard way to discover and call tools. For World that matters because there is no standard API to point a client at. Once you write the server, Claude, ChatGPT-compatible clients and your own agents can all share it.
The temptation is to expose a generic 'run SQL' tool. Resist it. A World database has hundreds of cryptic F-files, Julian dates and packed decimals, and an open query tool gives the model every chance to join the wrong columns and the user every chance to see data they should not.
This page describes a tool-first design that an IBM i team and a developer can build together.
What teams use it for
Item and availability lookup
get_item(item, branch) returns description, unit of measure, on-hand, committed and on-order from the item and location tables.
Order status
get_sales_order(order) returns header, line status, promised and ship dates, with open work orders linked.
Open PO exposure
list_open_po_lines(supplier, days_late) supports buyers and expediters.
BOM and where-used
get_bom(item) and where_used(component) from the structure tables for engineers and planners.
Proposal queue for changes
propose_change(type, payload) writes a pending row; it never posts. Humans approve in a separate screen.
JD Edwards World (IBM i) integration surface
- DB2 for i via the jt400 JDBC driver, IBM i Access ODBC, or the IBM Db2 for i connectors for Python and Node. These are the realistic data paths for the server.
- SQL views, UDTFs or stored procedures in a dedicated library that decode Julian dates, join descriptions and enforce row filters.
- Existing ILE or RPG inquiry programs exposed through IWS or called by stored procedure, where you want to reuse World's own logic.
- IBM i authority and profile mechanisms: user profiles, group profiles, object authority and adopted authority to scope what the server sees.
- Journals and data queues for push-style events if you later add subscriptions.
How it works
- 1
Design the tool list
Write each tool as a contract: name, description, input schema, output fields, max rows. Aim for 8 to 15 tools in the first release.
- 2
Build the SQL layer
Create views per tool in a library like MCPVIEWS (name is yours). Convert CYYDDD dates, trim padded text, and expose business names rather than field codes.
- 3
Pick the SDK and language
Use an official MCP SDK in TypeScript or Python. Run it on a Linux host near the IBM i, not on the partition unless your team is set up for that.
- 4
Choose the transport
stdio suits a single desktop client during development. Streamable HTTP with OAuth suits shared use. Terminate TLS and keep it on the internal network or a private link.
- 5
Map identity to IBM i access
Authenticate the end user, map to a role, and apply that role's branch and company filters in the query. Avoid one superuser for everyone.
- 6
Add audit and limits
Log tool, parameters, user, rows returned and duration. Rate limit and set statement timeouts on the DB connection.
- 7
Test against real questions
Run an evaluation set of planner questions, compare to World screens, and tune descriptions until the right tool is chosen.
Example flows
Planner asks about a shortage
Trigger: Client call to get_item then list_open_po_lines
- Server receives item and branch after authenticating the user.
- It queries the availability view and the open PO view with a row cap.
- It returns structured JSON with dates already converted.
Result: The AI client explains the shortage and the next inbound date; the call is logged.
Change proposal
Trigger: Buyer asks the assistant to push out a PO line
- Client calls propose_change with the PO, line and new date.
- Server validates the user has buyer rights and writes a pending row.
- A reviewer approves in a small web page, then a job posts via the normal World process.
Result: The change happens under World's controls with a clear audit trail.
Keeping data on-prem
The server runs on a host in your data center or private cloud and connects to DB2 for i over the internal network. No component needs inbound internet access. If the AI client is also private (an open-weight model served with vLLM or Ollama and an MCP-capable client), the whole loop is air-gapped. Keep dependencies on an internal package mirror and pin versions. If you do use a cloud AI client, only the tool results, not the database, are exposed, so keep the views narrow and masked.
Security checklist
- Never expose a generic SQL tool; only named, parameterized tools over approved views.
- Parameterize every query to prevent SQL injection from model-generated arguments.
- Scope by user role, branch and company in the SQL, not just in the prompt.
- Write tools must stage proposals; gate them with separate permissions.
- Keep audit logs immutable and review high-volume or off-hours use.
Ways to get it done
Build it in-house
Effort: About 4 to 8 weeks for a read-only server with auth and audit.
You have an IBM i developer and a TypeScript or Python developer.
Adapt a community IBM i or Db2 MCP server
Effort: Days to prototype, then real work to lock down.
Quick experiments; generic servers may offer SQL tools that need hardening before production.
Partner build with Netray
Effort: Scoped pilot, then add tools as use cases prove out.
You want a World-aware tool set, role mapping and an on-prem model delivered together.
Pitfalls
- !Exposing raw tables. The model will not know that a field is a Julian date or a status code with local meaning.
- !Using a shared database login so audit cannot show who asked.
- !Returning thousands of rows. Cap and summarize.
- !Vague tool names such as query_data; the client picks wrong tools.
- !Forgetting company and branch segregation that World users rely on.
Frequently asked questions
Does IBM i or World have an official MCP server?
Community and vendor projects for IBM i and Db2 exist and change quickly, but a World-aware server with your naming, security and views is something you generally build or have built. Check current options, and harden anything generic before production.
Should the MCP server run on the IBM i?
It can, since modern IBM i supports open source runtimes, but most teams run it on a separate Linux host to keep the production partition clean and make scaling and patching easier. It connects over JDBC or ODBC either way.
stdio or HTTP transport?
Use stdio while developing with a local client. For shared use choose HTTP with TLS and OAuth so you can authenticate users, rate limit and log centrally. Never put an unauthenticated HTTP server in front of ERP data.
Which tools should be first?
Read-only ones that answer frequent questions: item availability, order status, open POs and BOM. They are easy to verify against World screens and build trust. Add write proposals after the read tools are stable.
Can ChatGPT use the same server?
Where the client supports MCP, yes, and Claude does too. The server is client-neutral. If a client only supports plain OpenAPI actions, you can add a thin HTTP wrapper over the same tool functions without rewriting the SQL layer.
More for JD Edwards World (IBM i)
Want MCP server working on your JD Edwards World (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