How to build an MCP server for Epicor Kinetic
Short answer
An MCP server for Kinetic is a small service that exposes named, read-only tools (part lookup, order status, availability, job status) backed by BAQs and selected REST v2 calls. It works with Claude, ChatGPT and other MCP clients, and carries all authorisation and audit in your code.
Model Context Protocol gives AI clients a standard way to discover and call tools. For an ERP that means you write the integration once and let any compliant client use it, rather than building separate plugins per assistant.
Kinetic is a good fit because it already has the pieces a tool layer wants: BAQs as reviewed, parameterised queries, a REST API with consistent service naming, and role-based security. The design work is deciding what to expose and how to keep it safe.
This page is the design checklist. It assumes you are comfortable with an MCP SDK and want the Kinetic-specific decisions.
What teams use it for
Part and availability lookup
get_part returns description, revision, UOM and on-hand by warehouse and bin, plus allocations and the next supply date.
Order and shipment status
get_sales_order returns lines, promise dates, shipped quantities and carrier references for a customer service agent.
Job status and WIP
get_job returns operations, completed quantity, labor reported and material issued, useful for a shop supervisor assistant.
Supplier and PO history
get_po_status and get_supplier_performance feed buyer assistants and expediting agents.
BOM and where-used
get_bom and where_used support engineering questions without opening the Part Tracker.
Quality records
get_ncr and get_lot_trace let a quality engineer pull genealogy for a lot, with the read scoped to quality roles.
Epicor Kinetic integration surface
- BAQs via the BaqSvc OData endpoint: parameterised, versioned and reviewable, the best foundation for most tools.
- REST API v2 business objects (for example sales order, job entry and purchase order services) for single-record reads where a BAQ is overkill. Exact service and method names vary by version.
- Authentication options on your version: basic with a service account, token based, and API key headers. Confirm which your deployment requires.
- Company context in the URL path, so the server must map the caller to the right company.
- Server-side audit: Kinetic's own logs plus your MCP server's call log. Do not rely on only one.
How it works
- 1
Inventory the questions
Collect twenty real questions from planners, buyers, sales and quality. Group them into eight to twelve tools.
- 2
Write or reuse a BAQ per tool
Parameterise inputs, return stable column names, and test performance on production-size data.
- 3
Define tool schemas
Use clear names and descriptions, typed parameters with enums where possible, and a maximum result size.
- 4
Implement the server
Use the Python or TypeScript MCP SDK. Add a thin Kinetic client with retries, timeouts and company routing.
- 5
Pick the transport
Stdio for a single desktop client. Streamable HTTP with SSO and an API gateway for shared use.
- 6
Add permission scoping
Map each end user or group to allowed tools and companies. Hide tools the user should not see.
- 7
Test with multiple clients
Try Claude, ChatGPT and an open-source client to catch assumptions about schema or output size.
Example flows
Customer service asks about a delayed order
Trigger: An agent in a chat client asks about order status.
- Client discovers get_sales_order and calls it with the order number.
- Server checks the user's allowed customers and runs the BAQ.
- Server returns lines with promise dates and open quantities.
- Client explains the delay and suggests a customer message.
Result: A grounded answer with no Kinetic login, and a log row for the audit.
Quality lot trace
Trigger: A quality engineer requests the trace for a supplier lot.
- Server runs the lot receipts BAQ, then the issues to jobs BAQ.
- Server joins shipments of the affected jobs.
- Output limited to 200 rows with a continuation token.
Result: Fast containment scope, with record IDs for verification.
Keeping data on-prem
For on-prem Kinetic, deploy the MCP server on a host inside the network that can reach the application server and, if needed, a read replica of the SQL Server database. Expose it over HTTPS only to your internal clients or to a private-model gateway. When the model is also on-prem, via vLLM or Ollama, no ERP data leaves the building. If you must support a cloud-hosted client, put the server behind your reverse proxy with mutual TLS or a signed token and restrict source IPs, and think carefully about whether that client may receive the returned fields.
Security checklist
- Start with read-only tools. A write tool should return a draft and need an explicit confirmation call from an authenticated human.
- Never accept raw SQL, raw OData filters or arbitrary service names from the model.
- Authenticate users to the MCP server and use a separate least-privilege service account to Kinetic.
- Log tool name, arguments, user, row count and latency. Ship the logs somewhere tamper resistant.
- Apply field-level masking for prices, margins and personal data according to role.
Ways to get it done
Open-source starter you adapt
Effort: One to two weeks for a first set of tools.
In-house developers who know OData and want control.
Generic REST-to-MCP gateway
Effort: Days, but harder to secure and audit.
Quick exploration, accepting broader exposure than ideal.
Netray-built server with approvals and private models
Effort: A scoped build over several weeks.
Regulated plants needing audit, role mapping and on-prem inference.
Pitfalls
- !Too many fine-grained tools, which confuses the model. Aim for a small, well-described set.
- !Letting BAQs return wide tables full of columns the user should not see.
- !Ignoring pagination, so a large result silently truncates.
- !Not versioning tools. Renaming a tool breaks saved prompts and agent flows.
- !Skipping load tests. A chatty client can hit Kinetic hard.
Frequently asked questions
Is there an official Epicor MCP server?
Do not assume so. Check Epicor's current announcements and your account team. Even if an official one exists, review what it exposes and how it authenticates before putting it in front of your production data.
BAQ or REST business object for each tool?
Prefer a BAQ for lists, joins and reporting-style reads because it is reviewable and efficient. Use a REST business object read for a single record when you need fields the BAQ would not offer cheaply. Test both for speed.
Stdio or HTTP transport?
Stdio is simplest for one user on one machine. For a team, use HTTP with SSO, centralised logging and rate limits, so credentials never sit on laptops.
Can the same server serve Claude and ChatGPT?
Yes if both clients support MCP in your plan and version, since the protocol is the same. Client features differ, so test tool descriptions and output sizes in each.
How do I limit what each user sees?
Map identity to roles in the MCP server, expose only permitted tools, and pass company and customer filters as server-enforced parameters. Do not rely on the model to respect restrictions.
Want MCP server working on your Epicor Kinetic?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment