# How to build an MCP server for Epicor Kinetic > Source: https://netray.co/integrations/epicor-kinetic-mcp-server > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## 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. ## System Epicor Kinetic ## Capability mcp-server ## Intro 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. ## Use Cases ### Part and availability lookup **Description:** get_part returns description, revision, UOM and on-hand by warehouse and bin, plus allocations and the next supply date. ### Order and shipment status **Description:** get_sales_order returns lines, promise dates, shipped quantities and carrier references for a customer service agent. ### Job status and WIP **Description:** get_job returns operations, completed quantity, labor reported and material issued, useful for a shop supervisor assistant. ### Supplier and PO history **Description:** get_po_status and get_supplier_performance feed buyer assistants and expediting agents. ### BOM and where-used **Description:** get_bom and where_used support engineering questions without opening the Part Tracker. ### Quality records **Description:** get_ncr and get_lot_trace let a quality engineer pull genealogy for a lot, with the read scoped to quality roles. ## System 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 ### Inventory the questions **Detail:** Collect twenty real questions from planners, buyers, sales and quality. Group them into eight to twelve tools. ### Write or reuse a BAQ per tool **Detail:** Parameterise inputs, return stable column names, and test performance on production-size data. ### Define tool schemas **Detail:** Use clear names and descriptions, typed parameters with enums where possible, and a maximum result size. ### Implement the server **Detail:** Use the Python or TypeScript MCP SDK. Add a thin Kinetic client with retries, timeouts and company routing. ### Pick the transport **Detail:** Stdio for a single desktop client. Streamable HTTP with SSO and an API gateway for shared use. ### Add permission scoping **Detail:** Map each end user or group to allowed tools and companies. Hide tools the user should not see. ### Test with multiple clients **Detail:** 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. **Steps:** - 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. **Steps:** - 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. ## 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 - 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. ## Options ### Open-source starter you adapt **Fit:** In-house developers who know OData and want control. **Effort:** One to two weeks for a first set of tools. ### Generic REST-to-MCP gateway **Fit:** Quick exploration, accepting broader exposure than ideal. **Effort:** Days, but harder to secure and audit. ### Netray-built server with approvals and private models **Fit:** Regulated plants needing audit, role mapping and on-prem inference. **Effort:** A scoped build over several weeks. ## 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. ## Faq ### Is there an official Epicor MCP server? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms epicor kinetic mcp server, mcp server for epicor, model context protocol epicor, epicor mcp, build mcp server erp, epicor kinetic api mcp, epicor baq mcp tool, mcp epicor claude chatgpt, epicor kinetic ai tools api --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json