# How to build an MCP server for Priority ERP > Source: https://netray.co/integrations/priority-mcp-server > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer An MCP server for Priority is a small service that turns OData queries into named, typed tools that any MCP client can call. Start with read-only tools, authenticate with a limited Priority user, and log every call. ## System Priority ERP ## Capability mcp-server ## Intro The Model Context Protocol gives AI clients a standard way to discover and call tools. For Priority, that means one server can serve Claude, ChatGPT and in-house assistants without a separate integration for each. Priority is a good target because its forms already behave like business objects: orders, parts, suppliers, work orders. An MCP tool is a thin, opinionated wrapper around one of those, with the filters and limits baked in so the model cannot wander through the whole database. The skill is in tool design, not in protocol plumbing. A server with six well-described tools usually beats one with sixty generic ones. ## Use Cases ### Item and stock lookup **Description:** A tool takes a part number and returns description, unit, planning parameters and stock by warehouse, so any client can answer availability questions. ### Order status **Description:** A tool takes a sales order number and returns lines, quantities, promised dates and linked delivery documents. ### Purchase order tracking **Description:** Tools list open purchase order lines by supplier or by part, with due dates and receipts to date. ### BOM explosion **Description:** A tool returns the multi-level bill of material for a part, with a depth limit, for engineering and planning questions. ### Work order shortages **Description:** A tool compares required quantities for a work order with available stock and returns only the short components. ## System Surface - OData v4 entities exposed by the Priority REST service are the backbone. Each tool maps to one or two entity queries using filter, select and top parameters. - Sub-forms appear as nested collections, which lets one tool return an order with its lines, subject to your version's expansion support. - Priority users, profiles and application credentials determine what the server can see. Create one service identity per environment and keep it read-only. - Priority procedures and interfaces exist for operations that are not simple reads. Keep them out of the first release, and wrap them only as draft-creating tools later. - Entity names, company paths and response shape vary by version and configuration, so write integration tests against a non-production company. ## How It Works ### List the tools from real questions **Detail:** Collect the questions planners, buyers and sales support ask most. Each recurring question becomes a tool with a precise name. ### Define typed schemas **Detail:** Use strict parameter types, enums for status values, and max values for limits. Reject anything outside the schema before calling Priority. ### Implement the OData calls **Detail:** Use select to return only needed fields, apply the company and warehouse filters server side, and cap result size. Normalize dates and units in the response. ### Choose transports **Detail:** stdio suits local development and single-user desktops. For shared use, run an HTTP transport behind your reverse proxy with per-user authentication. ### Add permission scoping **Detail:** Map each client user to a role, and expose only the tools that role may call. Where Priority supports it, use per-user credentials instead of one shared account. ### Add audit and testing **Detail:** Log tool, parameters, user, duration and row count. Build a regression suite of question-to-expected-tool cases and run it on every change. ## Example Flows ### Availability answer through any client **Trigger:** User asks if a part can ship this week **Steps:** - Client calls get_part_stock with the part number. - Server queries Priority and returns stock by warehouse. - Client calls list_open_po_lines for the same part. - Client answers with on-hand and next receipt date. **Result:** A grounded availability answer with warehouse and document references. ### Engineering change impact **Trigger:** Engineer asks which open orders use a part **Steps:** - Client calls where_used for the part. - Client calls list_open_work_orders for each parent, limited in count. - Client summarizes affected orders by due date. **Result:** A quick impact list before the change is approved. ## On Prem The MCP server sits comfortably inside the network next to a self-hosted Priority server, talking to the OData endpoint over the LAN. Pair it with a locally served open-weight model and an MCP-capable client, and the whole chain stays internal. If some users want a hosted client such as Claude or ChatGPT, publish the HTTP transport through your DMZ with strong authentication and expose a reduced tool set for those users, keeping restricted tools internal only. ## Security - Use a read-only Priority service identity and verify it cannot write by testing, not by assumption. - Require authentication on any HTTP transport and prefer short-lived tokens tied to a named user. - Validate inputs against the schema, cap results, and strip fields the tool does not need to return. - Keep an append-only audit log, and alert on unusual volumes or repeated denied calls. - Version your tools and review changes like any code that touches production data. ## Options ### Generic OData-to-MCP bridge **Fit:** Quick for experiments. It exposes too much for production because the model sees raw entities. **Effort:** Days ### Custom server with curated tools **Fit:** Best for production. Needs a developer who knows both MCP and Priority entities. **Effort:** Two to four weeks ### Partner-built server such as Netray **Fit:** When you want curated tools, an evaluation suite and an on-prem model delivered together. **Effort:** Scoped project ## Pitfalls - Exposing a generic query tool that accepts raw OData filters, which invites expensive or unsafe queries. - Returning inconsistent units or currencies between tools. - Skipping pagination, so one broad question times out the Priority service. - Using one super-user credential and losing any ability to attribute actions. - Describing tools in internal jargon the model has no way to interpret. ## Faq ### What language should the server be written in? **Answer:** Use whatever your team maintains well. Official MCP SDKs exist for several languages, including TypeScript and Python. The choice matters less than clear tool schemas, tests and operational ownership. ### Should the server be read-only? **Answer:** Yes at first. Read-only tools cover most value and limit risk. Later, add write tools that create drafts or proposals needing human approval, rather than changing live orders directly. ### Does MCP work with ChatGPT as well as Claude? **Answer:** MCP support is broad and growing across clients, but details vary by product and plan. Check what your chosen client supports today, and keep the server standard so you can switch clients. ### How do I authenticate to Priority? **Answer:** Typically with a dedicated Priority user or application credentials, depending on your version. Store them in a secrets manager, scope the profile narrowly, and avoid reusing a human login. ### How many tools is too many? **Answer:** Quality drops when the list grows into the dozens, because models pick worse. Aim for a focused set, group by role, and expose only the relevant tools to each user group. ## Search terms priority erp mcp server, mcp server for priority erp, model context protocol priority erp, priority software mcp, build mcp server erp odata, priority erp mcp claude, priority erp mcp chatgpt, mcp tools for manufacturing erp, priority odata mcp, on-prem mcp server erp --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json