How to build an MCP server for ECI E2 Shop System
Short answer
An MCP server for E2 Shop System is a small service that exposes named read-only tools, such as job status, open PO lines and part inventory, backed by parameterised queries on a least-privilege SQL Server login. Any MCP client, including Claude and ChatGPT-compatible tools, can then use E2 data under your control.
If you want more than one AI tool to work with E2, build the connection once. MCP gives you that: a standard way to describe tools so that different clients can discover and call them. The server is the only thing that touches your database, which makes it the place to enforce scope and audit.
E2 does not ship with an MCP server that I can confirm, and its data model differs by version, so this is a build-it-yourself job or a job for a partner. The good news is that a useful first version is small: five to eight read-only tools can cover most daily questions.
The design discipline matters more than the code. A well-scoped server is safe to hand to a pilot group; a server with a generic query tool is a liability.
What teams use it for
Job status lookup
get_job returns status, next open operation, due date, quantity complete and any hold flags, so any client can answer where a job stands.
Open PO exposure
list_open_po_lines returns vendor, part, quantity open, promise date and the jobs it feeds, for buyer chase lists.
Inventory position
get_inventory returns on hand, allocated and on order per part, so planners can check availability without opening E2.
Part and quote history
get_part_history returns past jobs, quoted versus actual hours and material for similar parts, to support estimating.
Customer snapshot
get_customer_summary returns open orders, late shipments and recent quotes for account reviews.
Shop floor labor view
get_operation_labor returns hours posted by operation and employee, scoped by role, for variance checks.
ECI E2 Shop System integration surface
- SQL Server: connect with a dedicated login holding SELECT on curated views only. Use parameterised queries; never string-build SQL from model input.
- Schema discovery: dump your own table and column list, then create views with stable, readable names such as v_open_jobs, so the server survives E2 updates with minimal change.
- Transports: stdio for a single-user desktop client; streamable HTTP for a shared server with token auth on your network.
- Identity: E2 user rights are not available to the SQL login, so map your own users or groups to tool permissions inside the server.
- Version differences: ask your reseller which E2 version you run and re-check views after upgrades or service packs.
How it works
- 1
Inventory the questions
Write down the twenty questions the office asks most. Group them into tools; each tool answers one family of questions.
- 2
Create curated views
Build SQL views that join and rename the needed E2 tables. Exclude cost and pricing columns from views meant for broad use.
- 3
Provision least-privilege access
Create a SQL login with SELECT on those views only, no access to base tables, and connect from a fixed host.
- 4
Implement tools with an MCP SDK
Define each tool with a clear name, a description written for the model, typed inputs and a bounded row count.
- 5
Add auth and permissions
For HTTP transport, require tokens tied to users or groups and decide which tools each may call.
- 6
Add audit logging
Log time, user, tool, parameters and row count to an append-only store you own.
- 7
Test with multiple clients
Try the server from Claude, another MCP client, and a script, and confirm identical results and limits.
Example flows
Planner asks about a shortage
Trigger: A planner asks whether bar stock for job 4521 is covered.
- Client calls get_job for the material requirement.
- Client calls get_inventory for the part.
- Client calls list_open_po_lines filtered by part.
- Client summarises coverage and the earliest receipt.
Result: A three-screen lookup becomes one question, with each fact traceable to a tool call.
Audit review
Trigger: Quarterly access review.
- Security exports the tool-call log.
- Reviewer filters by user and cost-bearing tools.
- Unusual access is queried and tool permissions are tightened.
Result: Evidence of who looked at what, owned entirely by you.
Keeping data on-prem
An MCP server is naturally on-prem friendly: it is a small process that can run on the same server as SQL Server or on a neighbouring VM, listening only on your internal network. Pair it with a locally served open-weight model and a local MCP-capable client, and the entire chain stays inside your firewall with no outbound dependency. For mixed use, keep the same server and simply restrict which clients may reach it; hosted clients can be limited to a separate server exposing only non-sensitive tools. Back up the view definitions and server config with the rest of your E2 environment.
Security checklist
- Read-only SQL login restricted to views; deny access to base tables.
- No generic query or execute tool, ever; all queries are fixed and parameterised.
- Token authentication on HTTP transport, TLS, and network allow lists.
- Per-tool and per-role permissions, with cost and margin tools separated.
- Append-only audit log and row limits to reduce bulk extraction risk.
Ways to get it done
Open-source or generic database MCP server
Effort: Hours; limited control over scope.
Fine for a throwaway experiment on a copy of the database; too permissive for production.
Custom server built in-house
Effort: One to three weeks for a first set of tools.
Best if you have a developer and want full ownership.
Partner-built E2 server with Netray
Effort: Scoped engagement, often a few weeks.
When you want a vetted tool set, views, audit and a private model together.
Pitfalls
- !Exposing a run_sql tool because it is faster to build.
- !Pointing the server at the live production database without testing query load.
- !Returning entire rows including cost fields when the caller only needs status.
- !Verbose tool descriptions that leak internal table names or logic.
- !Letting the server drift out of sync with E2 after an upgrade.
Frequently asked questions
Is there an official MCP server for E2 Shop System?
None that I can confirm. Check with ECI or your reseller for current offerings. Otherwise a custom server over read-only SQL views is the common approach.
Which tools should I build first?
Start with job status, open PO lines, inventory position and part history. They are read-only, answer frequent questions, and make accuracy easy to verify against E2 screens.
Should I use stdio or HTTP transport?
Stdio suits one user on one machine and is simplest. HTTP suits a shared server for several users and needs authentication, TLS and logging. Most shops that go beyond a pilot end up on HTTP.
Can the server write to E2?
It can in principle, but start without write tools. If you add them later, make them create pending requests for human approval rather than updating tables directly.
Does it work with ChatGPT as well as Claude?
MCP is an open protocol supported by a growing set of clients. Support varies by product and plan, so check what your chosen client supports today.
More for ECI E2 Shop System
Want MCP server working on your ECI E2 Shop System?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment