# How to build an MCP server for Infor M3 > Source: https://netray.co/integrations/infor-m3-mcp-server > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## 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. ## System Infor M3 ## Capability mcp-server ## Intro 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. ## Use Cases ### Item and stock lookup **Description:** Tools that resolve item numbers or descriptions and return balances by facility and warehouse, with allocated and available quantities. ### Order status tracking **Description:** Customer order header and line status, delivery dates, and linked delivery or shipment information in one tool call. ### Purchase order visibility **Description:** PO lines by supplier or item with confirmed dates and received quantities, ready for chase lists. ### Bill of material and structure exploration **Description:** A tool that returns product structure components, with limits on depth, to answer where-used and shortage questions. ### Manufacturing order status **Description:** Operation progress, material availability and expected completion for named orders. ### Controlled write proposals **Description:** A later-stage tool that creates a pending change request instead of writing to M3, which a human approves elsewhere. ## System 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 ### List candidate questions **Detail:** Collect fifty real questions from planners, buyers and service staff. Group them; each group becomes one tool, not each program. ### Design tool contracts **Detail:** Give every tool a verb-first name, a one-sentence description, required and optional parameters with types, and a bounded result shape. ### Implement M3 client code **Detail:** Write one module that handles authentication, retries, timeouts and the program-transaction call format, so tools stay small. ### Add the MCP layer **Detail:** Use the official TypeScript or Python SDK to register tools and resources. Return structured content plus a short text summary. ### Choose transport **Detail:** stdio for local single-user clients; streamable HTTP with authentication and TLS for shared deployments behind your gateway. ### Scope permissions **Detail:** Run the server under a service account whose M3 role covers only the programs used, and enforce facility or company filters in code. ### Instrument and test **Detail:** 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. **Steps:** - 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. **Steps:** - 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. ## 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 - 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. ## Options ### Off-the-shelf generic API-to-MCP wrapper **Fit:** Quick experiments when you accept broad, less-curated tools. **Effort:** Low, but quality and safety vary. ### Hand-built server by your M3 and integration team **Fit:** Teams that want full control and have developers who know MI programs. **Effort:** One to three weeks for a first tool set, plus maintenance. ### Partner-built server, such as with Netray **Fit:** When you want curated tools, evaluation sets and an on-prem deployment pattern. **Effort:** Scoped engagement, then handover or managed support. ## 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. ## Faq ### Is there an official MCP server for Infor M3? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms infor m3 mcp server, mcp server for infor m3, model context protocol infor m3, infor m3 mcp, build mcp server m3 erp, infor m3 api mcp, infor m3 mi programs mcp, m3 mcp claude chatgpt, infor m3 ion api mcp --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json