# How to build an MCP server for ECI M1

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

## Short answer

Expose a handful of read-only tools (item lookup, order status, inventory, BOM, open POs) that query a SQL view layer over M1, authenticate callers against your identity provider, and serve it over stdio for desktop use or HTTP for shared use. Any MCP client, including Claude and ChatGPT, can then use it.

## System

ECI M1

## Capability

mcp-server

## Intro

An MCP server is a small program that tells an AI client what tools it offers and runs them on request. For ECI M1, it is the layer that turns a SQL Server database full of cryptic table names into a few well-described questions an assistant can ask.

The value is reuse. Build the server once and every MCP-capable client benefits, without a separate Claude integration, ChatGPT integration and chatbot integration each re-implementing M1 access.

The design discipline matters more than the code. A good M1 MCP server has few tools, narrow parameters, hard limits and a clear audit trail, because the model will call whatever you expose.

## Use Cases

### Item master lookup

**Description:** Return description, unit of measure, revision, preferred vendor and on-hand by location for a part number or fuzzy description match.

### Order and job status

**Description:** Given a sales order, job or customer PO number, return lines, quantities, current operation and promise dates.

### Inventory and availability

**Description:** Show on-hand, allocated, on-order and projected availability for a part, so planners can ask in plain language.

### BOM and where-used explorer

**Description:** Return multi-level BOMs and where-used for a component to support engineering change questions.

### Open PO by vendor

**Description:** List open lines with promise dates and receipts for a vendor, ready for an expedite agent.

### Quality and receiving history

**Description:** Return recent rejects and receiving inspections for a vendor or part for supplier review conversations.

## System Surface

- SQL Server database for M1: connect with a read-only login from the MCP server, ideally to a replica.
- A curated schema of SQL views named for business concepts, so the server never exposes raw base tables.
- Optional supported M1 write path (import or web service, version and licence dependent) for later approval-gated tools.
- Windows Authentication or an identity provider such as Entra ID for knowing who is calling.
- File shares or document systems that hold drawings and certificates, if you add document tools.

## How It Works

### List five questions people ask every day

**Detail:** Item status, order status, shortage, open POs and where-used usually cover most of the value. Resist adding more initially.

### Create views for each

**Detail:** Write and test SQL views, with clear column names and filters, and document the semantic meaning of each column.

### Implement tools with the MCP SDK

**Detail:** Use an official SDK in Python, TypeScript or C#. Define each tool with a typed input schema, a plain-English description, a row cap and a timeout.

### Choose transport

**Detail:** stdio suits a single user running the server locally beside their client. Streamable HTTP suits a shared server behind your reverse proxy with authentication.

### Add auth and scoping

**Detail:** Authenticate the caller, map to an M1 role, and apply role-based filters in the view or in the query.

### Add audit logging and tests

**Detail:** Log tool name, arguments, caller and row count. Add unit tests with a fixture database and a small evaluation set of real questions.

## Example Flows

### Where-used during an ECO

**Trigger:** An engineer asks which open jobs use a part that is changing revision.

**Steps:**

- Client calls the where-used tool with the part number.
- Server returns parent assemblies from the BOM view.
- Client calls the open jobs tool for those parents.
- The assistant summarises affected jobs and quantities.

**Result:** The engineer sees impact in one conversation instead of three M1 screens and a spreadsheet.

### Multiple clients, one server

**Trigger:** Sales uses Claude, planning uses a local chat client, both need order status.

**Steps:**

- Both clients connect to the HTTP server with their own credentials.
- Each call is filtered to that user's role.
- The audit log records who asked what.

**Result:** One integration serves different tools with consistent permissions.

## On Prem

The MCP server is a plain service, so host it on a Windows or Linux VM inside your network next to the SQL Server replica. For stdio, install it on the user's workstation, though that spreads credentials to many machines, so prefer HTTP behind your reverse proxy for anything shared. Pair it with an on-prem model served by vLLM or Ollama and an MCP-capable client or agent framework and nothing leaves the building. If you also want cloud clients, publish the server only through a controlled gateway with mutual TLS or a VPN, and restrict which tools those clients can see.

## Security

- Give the server a SQL login with SELECT only on the view schema.
- Authenticate every HTTP caller and propagate identity; never run all calls as one service identity without filtering.
- Cap rows, query time and request rate per tool and per user.
- Treat tool outputs as untrusted text, since fields like descriptions can contain instructions that a model might follow.
- Keep immutable audit logs and review them periodically.

## Options

### Build with the official MCP SDK in-house

**Fit:** Best when you have a developer who knows SQL Server and your M1 schema.

**Effort:** One to three weeks for a first toolset.

### Generic database MCP server pointed at M1

**Fit:** Fine for exploration, but exposing raw tables is risky for production.

**Effort:** Hours to try, much more to make safe.

### Partner-built, tested server with evaluations

**Fit:** When you want production hardening and an on-prem model path.

**Effort:** A scoped pilot, often within weeks.

## Pitfalls

- Exposing a run-any-SQL tool, which the model will eventually misuse.
- Dozens of overlapping tools that confuse tool selection.
- Ignoring multi-site, multi-currency and unit-of-measure quirks in views.
- No caller identity, so everyone sees everything.
- Not versioning tool schemas, which breaks clients when columns change.

## Faq

### Does ECI provide an MCP server for M1?

**Answer:** We are not aware of an official one. Check with ECI for your version. Otherwise you build one, and a read-only server over curated SQL views is a manageable project.

### stdio or HTTP?

**Answer:** Use stdio for a single user on a workstation or for development. Use HTTP for shared access with central authentication, logging and rate limits. Most production deployments for an ERP end up on HTTP.

### Which language should I use?

**Answer:** Use the one your team supports. Official SDKs exist for common languages, including Python, TypeScript and C#. C# can be convenient on Windows and SQL Server shops.

### Can I let the server write to M1?

**Answer:** Later and carefully. Use a supported M1 import or API path, require human approval, validate inputs strictly and log everything. Never write by inserting directly into tables.

### Does it work with ChatGPT and Claude?

**Answer:** MCP is an open protocol supported by a growing set of clients. Support details change, so check the current client documentation. Local and open-weight setups can use it through compatible frameworks.

## Search terms

eci m1 mcp server, mcp server for eci m1, model context protocol erp, eci m1 mcp, build mcp server sql server erp, eci m1 claude mcp, mcp server on-prem erp, mcp tools job shop erp, eci m1 ai tools api

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