How to build an MCP server for Global Shop Solutions
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.
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.
What teams use it for
Job lookup for any assistant
One get_job tool returns status, current operation, due date and material state, so every client answers job questions the same way.
Purchasing visibility
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
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
A get_routing tool lets estimators and AI drafts reference the actual operation sequence and standards.
Developer tooling
An internal IDE assistant that can read schema descriptions and sample records helps report writers build and test queries faster.
Global Shop Solutions integration 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
- 1
Inventory the questions
List the 20 questions staff ask most. Group them into five to eight tools. Resist adding a tool for every table.
- 2
Create stable views
Define views with readable names and fixed columns. This isolates your tools from version upgrades and customisation drift.
- 3
Implement tools with strict schemas
Each tool declares typed parameters, a row cap and a short description written for a model. Return an as-of timestamp and ERP keys.
- 4
Choose the transport
Use stdio for a single user on a workstation. Use streamable HTTP with TLS for shared access on your network, behind your reverse proxy.
- 5
Add authentication and scoping
Authenticate callers with tokens or your identity provider, then map each identity to the tools and sites it may call.
- 6
Log and monitor
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.
- 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.
- 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.
Keeping data 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 checklist
- 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.
Ways to get it done
Build it yourself with an MCP SDK
Effort: Two to four weeks for a first hardened server.
Good if you have a developer and a stable view layer.
Generic database MCP server
Effort: Hours, but not suitable for end users.
Acceptable for developer exploration only. It exposes raw schema and lacks business-level tools.
Partner-built server such as Netray
Effort: A scoped pilot of a few weeks.
Good when you want tool design, auth, audit and an on-prem model path delivered together.
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.
Frequently asked questions
Is there an official MCP server for Global Shop Solutions?
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?
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?
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?
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?
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.
More for Global Shop Solutions
Want MCP server working on your Global Shop Solutions?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment