# How to build an MCP server for Infor LN

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

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

## System

Infor LN

## Capability

mcp-server

## Intro

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.

## Use Cases

### Item and availability lookup

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

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

**Description:** Read-only BOM tools for parent and component relationships, with effectivity dates, used for change impact and shortage analysis.

### Supplier performance snapshot

**Description:** A tool aggregating on-time receipts and rejections over a period for a supplier, for buyers and negotiation prep.

### Project cost summary

**Description:** Budget, committed and actual by project, with limits on depth, for project controllers and managers.

### Document search

**Description:** A retrieval tool over specs, certificates and contracts linked to LN records, honouring folder permissions.

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

### Inventory real questions

**Detail:** Collect the top forty questions planners, buyers and engineers ask. Group them into candidate tools. Drop any needing broad table access.

### Define each tool contract

**Detail:** For every tool write a clear name, description, typed input schema and output shape. Include company and site as explicit parameters.

### Implement with an official SDK

**Detail:** Use the TypeScript or Python MCP SDK. Keep queries parameterised, set timeouts, and cap row counts on every tool.

### Connect to LN

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

### Choose transport

**Detail:** Use stdio for local development and testing. For shared use run an HTTP transport behind your gateway with TLS and per-request authentication.

### Add authorisation

**Detail:** Map the calling user to allowed companies and tools, deny by default, and return clear errors rather than empty results when access is refused.

### Test and version

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

**Steps:**

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

**Steps:**

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

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

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

## Options

### Generic database or REST MCP server pointed at LN

**Fit:** Quick experiments and developer exploration only.

**Effort:** Hours, but poor control and weak safety for production.

### Custom MCP server with curated tools

**Fit:** Production use where you need predictable queries and permissions.

**Effort:** Typically weeks of engineering plus testing.

### Partner-built server and tool pack, such as Netray with an LN partner

**Fit:** Sites wanting a tested starting toolset and private model hosting.

**Effort:** Scoped pilot of several weeks.

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

## Faq

### Is there an official MCP server for Infor LN?

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

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

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

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

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

## Search terms

infor ln mcp server, mcp server for infor ln, infor ln model context protocol, build mcp server erp, infor ln mcp integration, infor ln ion api mcp, mcp for infor ln claude, infor ln ai tools api, infor ln mcp on-prem

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