How to build an MCP server for Infor M3
Short answer
An MCP server for Infor M3 is a small service that maps a few typed tools, such as item lookup or order status, to M3 API (MI program) calls, authenticates to M3 with a scoped service account, and speaks MCP over stdio or HTTP so Claude, ChatGPT and other clients can use it. Begin with read-only tools and add logging before anything that writes.
M3 already has a mature API surface: hundreds of MI programs expose lookups and transactions with named input and output fields. What it lacks, from an AI client's point of view, is a friendly layer that says which of those calls matter, what the parameters mean, and what is safe to run. That layer is what an MCP server provides.
Done well, the server makes an assistant feel like it knows M3: it can find an item, show balances by warehouse, follow a customer order to its delivery lines, and report a manufacturing order's material status, all without a person navigating panels. Done badly, it hands a model a firehose of raw fields and unrestricted authority.
The design work is mostly in tool selection, parameter schemas and permissions, not in the protocol code, which is short with the official SDKs.
What teams use it for
Item and stock lookup
Tools that resolve item numbers or descriptions and return balances by facility and warehouse, with allocated and available quantities.
Order status tracking
Customer order header and line status, delivery dates, and linked delivery or shipment information in one tool call.
Purchase order visibility
PO lines by supplier or item with confirmed dates and received quantities, ready for chase lists.
Bill of material and structure exploration
A tool that returns product structure components, with limits on depth, to answer where-used and shortage questions.
Manufacturing order status
Operation progress, material availability and expected completion for named orders.
Controlled write proposals
A later-stage tool that creates a pending change request instead of writing to M3, which a human approves elsewhere.
Infor M3 integration surface
- M3 API (MI programs): called by program, transaction and fields. Examples include MMS200MI for item warehouse data, PPS200MI for purchase orders, OIS100MI and OIS350MI for customer orders, CRS610MI for customers, and PMS100MI for manufacturing orders. Confirm the exact names in your version through the MI program metadata.
- Authentication, cloud: ION API Gateway with OAuth 2.0 and an .ionapi service account file. Tokens expire, so cache and refresh them in the server.
- Authentication, on-prem: depends on release and configuration, often a service user with a role in M3 security and token or basic authentication through the grid. Verify with your Infor administrator.
- Metadata: the M3 API exposes program and transaction definitions, which you can use to generate parameter schemas and descriptions for tools rather than hand-writing everything.
- Pagination and limits: many list transactions return a capped number of records, so tools need explicit filters and next-page handling.
- Optional: ION events or the Infor Data Lake for history and subscriptions the transactional API handles poorly.
How it works
- 1
List candidate questions
Collect fifty real questions from planners, buyers and service staff. Group them; each group becomes one tool, not each program.
- 2
Design tool contracts
Give every tool a verb-first name, a one-sentence description, required and optional parameters with types, and a bounded result shape.
- 3
Implement M3 client code
Write one module that handles authentication, retries, timeouts and the program-transaction call format, so tools stay small.
- 4
Add the MCP layer
Use the official TypeScript or Python SDK to register tools and resources. Return structured content plus a short text summary.
- 5
Choose transport
stdio for local single-user clients; streamable HTTP with authentication and TLS for shared deployments behind your gateway.
- 6
Scope permissions
Run the server under a service account whose M3 role covers only the programs used, and enforce facility or company filters in code.
- 7
Instrument and test
Log tool name, arguments, duration and row counts, and run a regression set against known results after every M3 update.
Example flows
Item availability tool call
Trigger: An MCP client calls get_item_availability with item MPN-1042 and facility A10.
- The server validates the parameters against its schema.
- It calls the item warehouse balance transaction through the M3 API.
- It trims fields to on-hand, allocated, on order and available.
- It returns structured JSON with a one-line summary.
Result: The client can answer stock questions with exact figures and unit of measure.
Write proposal with approval
Trigger: A client calls propose_po_date_change with a PO line and a new date.
- The server checks that the line exists and the date is valid.
- It stores a pending proposal with the requester identity.
- It notifies an approver through email, Teams or IPA.
- On approval a separate process performs the M3 update and logs it.
Result: The model can request changes but never executes them on its own.
Keeping data on-prem
The MCP server is plain application code, so it can live on an internal server next to the M3 grid with no internet path at all. Pair it with a local MCP client, or with an internal chat application using a locally served open-weight model through vLLM or Ollama. If you do allow a cloud client such as Claude or ChatGPT to reach the server, publish it through an authenticated gateway or reverse proxy with IP allow-lists and mutual TLS rather than opening the grid. Keep database access out of the server: use the M3 API so that M3 security and logging still apply.
Security checklist
- Service account with the minimum M3 role, separate for read and for any approved write path.
- Authenticate every HTTP MCP request and map the caller to an allowed set of tools and facilities.
- Validate and bound all parameters, and never build calls by concatenating model-supplied text.
- Return only needed fields; mask customer prices or personal data where the caller is not entitled.
- Keep append-only audit logs and review them for unusual call patterns.
Ways to get it done
Off-the-shelf generic API-to-MCP wrapper
Effort: Low, but quality and safety vary.
Quick experiments when you accept broad, less-curated tools.
Hand-built server by your M3 and integration team
Effort: One to three weeks for a first tool set, plus maintenance.
Teams that want full control and have developers who know MI programs.
Partner-built server, such as with Netray
Effort: Scoped engagement, then handover or managed support.
When you want curated tools, evaluation sets and an on-prem deployment pattern.
Pitfalls
- !One tool per MI program, which gives the model hundreds of confusing choices.
- !Returning raw API payloads with cryptic field codes instead of named, trimmed fields.
- !Missing pagination handling, so answers silently cover only the first batch of records.
- !Not testing after M3 updates or enhancement packages, when fields or behaviours change.
- !Exposing an HTTP MCP endpoint without authentication because it is on an internal network.
Frequently asked questions
Is there an official MCP server for Infor M3?
Do not rely on one existing for your version and deployment. Check Infor and marketplace channels for current offerings, and evaluate any against your security needs. The M3 API is well documented, so a custom MCP server is a practical, controllable route.
Which language should I use?
Use whichever your team can maintain. The official MCP SDKs for TypeScript and Python are the most common, and both can call the M3 API over HTTPS easily. The language matters less than clean tool design, authentication handling and testing.
stdio or HTTP transport?
stdio suits one user running the server locally, as with a desktop client. Streamable HTTP suits shared team use and central logging, but needs authentication, TLS and gateway controls. Many teams prototype on stdio and move to HTTP for rollout.
How many tools should we start with?
Start with about five to eight read-only tools covering your most common questions. Fewer, well-described tools outperform dozens of overlapping ones because the client model must choose between them from descriptions alone.
Can the same server work with ChatGPT and Claude?
Yes, if the client supports MCP, which is a goal of the protocol. Client capabilities and connector setup differ, so test with each, but the tool layer over M3 stays the same and you avoid building separate integrations.
Want MCP server working on your Infor M3?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment