How to build an MCP server for Epicor Vantage and Epicor 9
Short answer
An MCP server for Epicor 9 is a small service that exposes named, read-only tools (part lookup, job status, PO release, inventory) backed by parameterised queries on the OpenEdge database or calls to business objects. Any MCP client, including Claude and ChatGPT-compatible clients, can then use them under your authentication and audit.
Epicor 9 and Vantage have no MCP server from the vendor. If you want AI clients to work with your ERP without pasting exports, you write one, and the quality of that server determines how useful and how safe the whole thing is.
The temptation is to expose a generic query tool and let the model figure it out. That works in a demo and fails in a plant: it exposes every column, produces slow joins, and makes audit meaningless. A good server is a thin set of purposeful tools that encode how your planners actually think about the data.
This page walks through the design of that tool set, the access path into a Progress database, how to authenticate callers, and how to keep the server safe to leave running.
What teams use it for
Item and revision lookup
A get_part tool returns description, UOM, current revision, planning type and site-level on-hand, so a client can answer 'what is this and do we have it' without raw SQL.
Order and release status
get_order_status joins OrderHed, OrderDtl and OrderRel and returns promised dates, shipped quantities and any hold flags in a compact form.
Job progress
get_job_status returns the operation list with completed quantity, labor hours booked and material issued, which is the question most supervisors ask.
Purchasing visibility
get_po_releases lists open releases by vendor, part or due date range, with received-to-date and the jobs or sales orders they feed.
BOM and where-used
get_bom and get_where_used walk the part methods with a depth limit, giving AI clients structure they can reason over without pulling the whole tree.
Quality and receipt inspection
get_inspection_queue surfaces receipts waiting inspection or held, so a quality-focused client can prioritise work.
Epicor Vantage / Epicor 9 integration surface
- Progress OpenEdge SQL-92 over ODBC or JDBC: the practical read path. Use a read-only user and prefer views or a replica. Reserved words and quoting follow Progress rules, so test your queries against the driver.
- Table families you will wrap: Part, PartWhse, PartBin, PartTran for inventory; JobHead, JobAsmbl, JobMtl, JobOper for jobs; POHeader, PODetail, PORel for purchasing; OrderHed, OrderDtl, OrderRel for sales. Exact names and fields vary slightly by version.
- Business objects through the application server for validated reads and for any writes. Interface details differ across 9.04, 9.05 and Vantage 8.x.
- UD tables and UD fields: customer-specific, often critical. Document them per tool so results carry meaning.
- Windows authentication or Epicor user accounts for the business object path; database logins for the SQL path. Choose one identity model and stick to it.
How it works
- 1
Write the tool contract first
For each tool, define name, a plain-language description the model will read, input schema with types and limits, and output shape. Include units, currency and status meanings in the output.
- 2
Implement against a replica
Connect through ODBC with a read-only login. Use parameterised queries only and a hard row limit and timeout per call.
- 3
Handle Epicor quirks inside the tool
Convert UOMs, hide inactive records, resolve revision and site context, and decode status flags so the client never has to guess.
- 4
Choose the transport
Use stdio for a single-user pilot. For shared use, serve over HTTP on an internal host with TLS and a reverse proxy, and place it close to the database.
- 5
Add authentication and scoping
Issue tokens per client or group. Map groups to tool sets, for example planners get inventory and jobs, finance also gets cost tools.
- 6
Add audit and rate limits
Log caller, tool, arguments, row count and duration. Limit calls per minute to protect the Progress database.
- 7
Pilot with two clients
Test with Claude and one other MCP client to prove the server is not accidentally tuned to one model.
Example flows
Planner asks about a shortage
Trigger: Question: 'Why is job 54321 not starting?'
- Client calls get_job_status for 54321.
- It calls get_job_materials filtered to short items.
- For each short item it calls get_po_releases.
- It explains which PO is late and by how many days.
Result: A grounded answer built from three small tool calls, each logged.
Buyer checks supplier exposure
Trigger: Question: 'What do we have open with vendor ACME?'
- Client calls get_po_releases with vendor and open status.
- It sums value by due week.
- It flags releases past due.
Result: The buyer gets a ready-to-act exposure summary without running a report.
Keeping data on-prem
An MCP server is naturally on-prem: it is just a service next to your Epicor replica. Run it on a server in the same network segment, keep ODBC traffic local, and expose it only to internal clients. Pair it with an on-prem model client backed by vLLM or Ollama, and the entire chain from question to answer stays inside the plant. For air-gapped sites, package the server and its dependencies for offline install and refresh the replica from backup media on a schedule you control.
Security checklist
- Read-only database user restricted to the tables or views the tools need; no write privileges at all in phase one.
- Per-client tokens or SSO, with tool allow-lists by role, and cost fields hidden from roles that should not see them.
- Parameterised queries only; reject any input that is not a validated identifier or range.
- Full audit logging with retention that meets your internal record policies.
- If writes are ever added, route them through approval and business objects, not through the MCP server's database login.
Ways to get it done
Write it yourself with an MCP SDK
Effort: Two to four weeks for a solid read-only set with tests.
Fine for teams with a developer who knows Progress SQL and Epicor tables.
Use an open-source or community Epicor connector as a base
Effort: Review and adaptation can approach the cost of writing your own.
Only if one exists that targets Epicor 9 and has been reviewed; many target Kinetic REST instead.
Partner build with Netray
Effort: A scoped pilot is typically weeks.
When you want tools, auth, audit and an on-prem model client delivered together.
Pitfalls
- !Exposing a generic run_sql tool, which defeats scoping and invites slow joins.
- !Running queries against the live production database during peak MRP or posting runs.
- !Returning raw tables with cryptic codes, so the client misreads status or units.
- !Forgetting multi-site and company context, producing totals that mix plants.
- !Not testing with a second client, then discovering the tool descriptions only suit one model.
Frequently asked questions
Is there an official MCP server for Epicor 9?
We are not aware of one from the vendor for Epicor 9 or Vantage. Newer Kinetic REST APIs make community connectors more plausible there, but for older releases you generally build your own against ODBC or the business object layer.
Which tools should I build first?
Part lookup, order status, job status, PO releases and inventory by warehouse. They are read-only, answer the most common questions, and are easy to validate against screens your users already know.
Should the MCP server be able to write to Epicor?
Not at first. Prove read accuracy, then add a narrow write tool that creates a proposal in an approval queue. Applying the change should happen in a separate step using Epicor's business objects so validation and audit still run.
Does it work with clients other than Claude?
Yes. MCP is a protocol, so any compliant client can use the same tools, including some ChatGPT-compatible and open-source clients. Test with more than one client so descriptions and schemas are not model-specific.
Where should the server run?
Close to the database, on an internal host, ideally pointed at a read replica. Use stdio for solo pilots and HTTP with TLS and authentication for shared use. Keep it off the public internet unless you have a hardened gateway in front.
Want MCP server working on your Epicor Vantage / Epicor 9?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment