How to build an MCP server for Infor LN
Short answer
Build an MCP server for Infor LN as a small service that exposes a few read-only tools, such as item lookup, order status, inventory and where-used, backed by ION API or a read replica. Authenticate with a scoped service identity, use HTTP transport for shared use, and log every call.
A Model Context Protocol server is the adapter between an AI client and your system. For LN it translates a request like 'what is the status of purchase order 40012' into a controlled call, and returns structured results the model can reason about. Once built, it works with Claude, ChatGPT-compatible clients and open-source agents without rewriting.
The temptation is to expose LN generously. Resist it. LN has hundreds of sessions and thousands of tables, and a model with broad access will find the wrong ones. The best servers are small, opinionated and tied to the questions your users actually ask.
This page is a design guide: tool list, auth, transport, permission scoping and testing, with the LN-specific traps that bite first-time builders.
What teams use it for
Item and availability lookup
A tool returning item master essentials, on-hand by warehouse and planned supply, so any assistant can answer stock questions without session navigation.
Order status across sales, purchase and production
Tools that return header and line status, promised dates and linked orders, with a consistent shape for each order type.
Where-used and BOM explosion
Read-only BOM tools for parent and component relationships, with effectivity dates, used for change impact and shortage analysis.
Supplier performance snapshot
A tool aggregating on-time receipts and rejections over a period for a supplier, for buyers and negotiation prep.
Project cost summary
Budget, committed and actual by project, with limits on depth, for project controllers and managers.
Document search
A retrieval tool over specs, certificates and contracts linked to LN records, honouring folder permissions.
Infor LN integration surface
- ION API: the supported REST gateway where service calls require a client ID and secret provisioned in Infor OS; scopes and available services vary with release, so inventory them before designing tools.
- Read replica of the LN database: the right place for aggregate tools. Table names follow package, module and sequence with a company suffix, and you must map company numbers explicitly.
- Infor Data Lake and Compass-style SQL access, where licensed: a decoupled query path that keeps tool load off the transactional system.
- BODs and ION Desk: use to inspect integration events and, later, to submit drafted changes through the standard document flow.
- LN business object layer: the only responsible route for a future write tool, because it applies LN validation.
How it works
- 1
Inventory real questions
Collect the top forty questions planners, buyers and engineers ask. Group them into candidate tools. Drop any needing broad table access.
- 2
Define each tool contract
For every tool write a clear name, description, typed input schema and output shape. Include company and site as explicit parameters.
- 3
Implement with an official SDK
Use the TypeScript or Python MCP SDK. Keep queries parameterised, set timeouts, and cap row counts on every tool.
- 4
Connect to LN
Fetch ION API tokens from a secrets store, cache with expiry, and handle token refresh. For database tools use a read-only account on the replica.
- 5
Choose transport
Use stdio for local development and testing. For shared use run an HTTP transport behind your gateway with TLS and per-request authentication.
- 6
Add authorisation
Map the calling user to allowed companies and tools, deny by default, and return clear errors rather than empty results when access is refused.
- 7
Test and version
Write contract tests against a non-production LN, version the tool schemas, and keep a changelog so clients do not break silently.
Example flows
Shortage check
Trigger: An assistant is asked whether a production order can start Monday.
- Client calls get_production_order with the order number.
- Client calls get_bom_components for the item and quantity.
- Client calls get_availability for each component.
- Model summarises shortages and the earliest supply dates.
Result: A grounded yes or no with the missing components listed.
Blocked access
Trigger: A user without rights asks for a company they cannot see.
- Server checks the user's mapped companies.
- It denies the call with an explicit permission error.
- It logs the attempt with user and parameters.
- Client explains it cannot access that company.
Result: No silent leakage, and a clean audit record.
Keeping data on-prem
An MCP server is just a service, so it fits an on-prem deployment naturally. Host it on an application server inside the network, give it internal routes to ION or the replica, and connect it to clients that run against a local open-weight model, or to hosted clients through a tightly controlled reverse proxy if policy allows. Air-gapped sites can run the whole chain, server, retrieval index and model, inside the enclave and refresh data on a schedule.
Security checklist
- Use a read-only service identity per environment and keep secrets in a vault, not in configuration files.
- Authenticate and authorise each call to the user level; do not rely on a shared token as the only control.
- Limit rows, fields and query time on every tool to bound damage from a bad request.
- Log tool, caller, parameters, row count and duration to append-only storage.
- Treat any text returned from LN comments or documents as untrusted input that may contain instructions.
Ways to get it done
Generic database or REST MCP server pointed at LN
Effort: Hours, but poor control and weak safety for production.
Quick experiments and developer exploration only.
Custom MCP server with curated tools
Effort: Typically weeks of engineering plus testing.
Production use where you need predictable queries and permissions.
Partner-built server and tool pack, such as Netray with an LN partner
Effort: Scoped pilot of several weeks.
Sites wanting a tested starting toolset and private model hosting.
Pitfalls
- !Exposing a raw SQL tool lets the model run expensive or wrong queries against live data.
- !Forgetting the company number in joins returns data from the wrong entity.
- !Unversioned tool schemas break client prompts when you rename a field.
- !Returning entire records floods the context window and exposes unneeded fields.
- !Skipping a non-production LN for tests pushes experiments onto the live system.
Frequently asked questions
Is there an official MCP server for Infor LN?
We are not aware of a vendor-supported one that fits customised installations, so check current Infor offerings. Most sites build or commission a server that wraps ION API or a replica and exposes a short, approved list of tools.
Which transport should we use?
Use stdio for local testing, where the client launches the server as a process. Use an HTTP-based transport for anything shared, because it lets you place authentication, TLS and logging at a gateway and serve many users from one instance.
Should the server allow writes?
Start with none. Read-only tools cover most value and risk almost nothing. If you later add writes, make them propose-then-approve, run under the approver's identity, and use supported LN interfaces so validation and audit remain intact.
Will it work with Claude and ChatGPT?
MCP is an open protocol with growing client support, including Claude. Support in other products varies by client and plan, so verify the current state. The server itself is client-neutral, which is the main reason to build it this way.
How many tools should it have?
Fewer than you think. Ten to twenty well-described tools usually outperform a hundred overlapping ones. Each should answer a distinct real question, and you should remove tools that logs show are never used or are frequently misused.
Want MCP server working on your Infor LN?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment