# How to build an MCP server for Global Shop Solutions > Source: https://netray.co/integrations/global-shop-mcp-server > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer An MCP server for Global Shop Solutions is a small service that exposes a handful of read-only tools (job status, PO lines, inventory, routing) to any MCP client such as Claude or ChatGPT. Build it against database views or the vendor's web services, authenticate each caller, scope permissions per tool, and log every call. ## System Global Shop Solutions ## Capability mcp-server ## Intro If you want more than one AI tool talking to the same ERP, you do not want to build a custom integration for each. The Model Context Protocol lets you build the ERP side once. Claude, ChatGPT-compatible clients, IDE assistants and your own agents then share it. For Global Shop Solutions this matters because the data model is wide and the answers people want cut across modules: a job, its routing, its material, the purchase orders feeding it, and the customer order behind it. A thoughtfully designed tool set hides that complexity. The design work is mostly deciding what not to expose. A good first server has under ten tools, all read-only, with output shaped for a model to read rather than a database dump. ## Use Cases ### Job lookup for any assistant **Description:** One get_job tool returns status, current operation, due date and material state, so every client answers job questions the same way. ### Purchasing visibility **Description:** A list_open_po_lines tool filtered by vendor, part or job gives buyers a conversational view of what is late and what is due. ### Inventory availability **Description:** A check_availability tool returns on-hand, allocated and on-order for a part with location detail, replacing a multi-screen lookup. ### Routing and standards **Description:** A get_routing tool lets estimators and AI drafts reference the actual operation sequence and standards. ### Developer tooling **Description:** An internal IDE assistant that can read schema descriptions and sample records helps report writers build and test queries faster. ## System Surface - Database views: a read-only schema of views over jobs, routings, POs, inventory and customers, accessed by ODBC or the native driver for your database (commonly an Actian Zen style engine in on-prem installs; confirm for your version). - Vendor web services: where available, use documented endpoints for reads to stay within support boundaries. - Scheduling output: schedule dates are produced by the scheduling module, so read the stored results rather than recomputing. - Shop floor data collection tables: labor and quantity postings give real progress, which complements planned dates. - Metadata: a simple catalog describing each view and column helps the model and your developers use them correctly. ## How It Works ### Inventory the questions **Detail:** List the 20 questions staff ask most. Group them into five to eight tools. Resist adding a tool for every table. ### Create stable views **Detail:** Define views with readable names and fixed columns. This isolates your tools from version upgrades and customisation drift. ### Implement tools with strict schemas **Detail:** Each tool declares typed parameters, a row cap and a short description written for a model. Return an as-of timestamp and ERP keys. ### Choose the transport **Detail:** Use stdio for a single user on a workstation. Use streamable HTTP with TLS for shared access on your network, behind your reverse proxy. ### Add authentication and scoping **Detail:** Authenticate callers with tokens or your identity provider, then map each identity to the tools and sites it may call. ### Log and monitor **Detail:** Record caller, tool, arguments, rows returned and latency. Alert on unusual volume and expose a kill switch. ## Example Flows ### Status through two different clients **Trigger:** A planner asks Claude and an internal chat the same job question. **Steps:** - Both clients discover the get_job tool from the server. - Each calls it with the job number. - The server returns identical, timestamped facts. **Result:** Consistent answers across tools, with a single audit trail. ### Availability check before quoting **Trigger:** An estimator asks if a long-lead material is in stock. **Steps:** - The client calls check_availability for the material. - The server returns on-hand, allocated and open PO dates. - The client summarises what can be promised and when. **Result:** A quote promise grounded in current inventory and inbound supply. ## On Prem An MCP server is naturally on-prem friendly. It runs on a small VM inside your network, talks to the database or API on the LAN, and only the MCP client needs to reach it. If you use a hosted client such as Claude or ChatGPT, tool results are sent to that service as part of the conversation, so decide which tools are safe for hosted clients. For controlled data, pair the same server with a local open-weight model and an on-prem MCP-capable client. No public inbound port is required for stdio setups, and HTTP setups can stay behind your VPN. ## Security - Run with a read-only database account limited to the exposure views, never the application owner login. - Authenticate every request and apply per-tool, per-site authorization. - Redact or omit sensitive columns such as unit cost and margin unless a role needs them. - Cap result sizes and rate-limit to prevent bulk extraction through the model. - Keep immutable logs and review them periodically, and pin dependencies since the server is a privileged component. ## Options ### Build it yourself with an MCP SDK **Fit:** Good if you have a developer and a stable view layer. **Effort:** Two to four weeks for a first hardened server. ### Generic database MCP server **Fit:** Acceptable for developer exploration only. It exposes raw schema and lacks business-level tools. **Effort:** Hours, but not suitable for end users. ### Partner-built server such as Netray **Fit:** Good when you want tool design, auth, audit and an on-prem model path delivered together. **Effort:** A scoped pilot of a few weeks. ## Pitfalls - Exposing raw tables and free-form SQL, which produces confident but wrong answers. - Returning enormous result sets that waste context and leak data. - No identity mapping, so everyone effectively shares one privileged ERP login. - Putting write tools in the same server as read tools without separate authorization. - Not versioning the view layer, so an ERP update silently changes tool output. ## Faq ### Is there an official MCP server for Global Shop Solutions? **Answer:** We are not aware of an official one you can rely on, and that can change. Check with the vendor. Most teams build a small one tailored to their questions and permissions. ### Which clients work with it? **Answer:** Any client implementing the Model Context Protocol, including Claude clients, several IDE assistants and other chat applications. Support for connecting remote servers varies by client and plan. ### stdio or HTTP transport? **Answer:** stdio suits a single user on one machine. For a team, use HTTP with TLS and authentication behind your proxy so access is centrally controlled and logged. ### Should it ever write to the ERP? **Answer:** Not at first. If you add writes, make them separate tools that create drafts or proposals, require a named human approval, and use a distinct service account. ### How many tools should it have? **Answer:** Start with five to eight. More tools make selection harder for the model. Add tools only when a real recurring question is not answered by the existing set. ## Search terms global shop solutions mcp server, mcp server for erp, model context protocol global shop, global shop erp mcp, build mcp server manufacturing erp, mcp odbc erp, claude mcp global shop, on-prem mcp server --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json