How to build an MCP server for ECI M1
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.
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.
What teams use it for
Item master lookup
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
Given a sales order, job or customer PO number, return lines, quantities, current operation and promise dates.
Inventory and availability
Show on-hand, allocated, on-order and projected availability for a part, so planners can ask in plain language.
BOM and where-used explorer
Return multi-level BOMs and where-used for a component to support engineering change questions.
Open PO by vendor
List open lines with promise dates and receipts for a vendor, ready for an expedite agent.
Quality and receiving history
Return recent rejects and receiving inspections for a vendor or part for supplier review conversations.
ECI M1 integration 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
- 1
List five questions people ask every day
Item status, order status, shortage, open POs and where-used usually cover most of the value. Resist adding more initially.
- 2
Create views for each
Write and test SQL views, with clear column names and filters, and document the semantic meaning of each column.
- 3
Implement tools with the MCP SDK
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.
- 4
Choose transport
stdio suits a single user running the server locally beside their client. Streamable HTTP suits a shared server behind your reverse proxy with authentication.
- 5
Add auth and scoping
Authenticate the caller, map to an M1 role, and apply role-based filters in the view or in the query.
- 6
Add audit logging and tests
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.
- 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.
- 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.
Keeping data 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 checklist
- 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.
Ways to get it done
Build with the official MCP SDK in-house
Effort: One to three weeks for a first toolset.
Best when you have a developer who knows SQL Server and your M1 schema.
Generic database MCP server pointed at M1
Effort: Hours to try, much more to make safe.
Fine for exploration, but exposing raw tables is risky for production.
Partner-built, tested server with evaluations
Effort: A scoped pilot, often within weeks.
When you want production hardening and an on-prem model path.
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.
Frequently asked questions
Does ECI provide an MCP server for M1?
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?
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?
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?
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?
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.
Want MCP server working on your ECI M1?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment