How to build an MCP server for ProShop ERP
Short answer
An MCP server for ProShop wraps a few ProShop API queries as named, typed tools such as work order status, part lookup and NCR history. Start read-only, authenticate with a restricted API user, choose stdio for one user or HTTP for a team, and log every call.
A Model Context Protocol server is a thin program that tells an AI client what tools exist and runs them on request. For ProShop, that means the AI never learns the GraphQL schema or holds a credential. It just calls get_work_order with a number and receives a tidy answer.
The value is reuse. Once the tools exist, Claude, ChatGPT where it supports MCP, and in-house assistants can all use the same server, so you invest in the integration once rather than rebuilding it per vendor.
Most of the work is not protocol code. It is deciding which tools are worth exposing, how much each returns, and who is allowed to call them. A small, well-described set beats a large raw wrapper over the whole API.
What teams use it for
Job status lookup
A tool taking a work order number returns status, current operation, quantity complete, due date and any holds, so anyone can ask without opening ProShop.
Part and revision lookup
Return a part's description, current revision, material, customer and linked routing summary for engineers and quoting.
PO and material status
Given a work order, list its material and outside process POs with promised dates and receipt status for buyers and planners.
NCR search
Search nonconformances by part, date range or keyword and return short records with IDs for quality review.
Customer open-orders summary
List a customer's open work orders with ship dates, supporting account managers who field status calls.
Schema-aware discovery
A helper tool lists which fields exist for a record type in your instance, including custom fields, so prompts adapt without code changes.
ProShop ERP integration surface
- ProShop's API, GraphQL based in current releases with token authentication, is the single backend for the server. Confirm endpoint, auth flow and rate limits with ProShop for your version.
- Introspection, if enabled for your API user, lets the server discover types and custom fields. If not, maintain a versioned field map in the server.
- Pagination matters for work orders and parts. Build tools that take filters and limits instead of fetching everything.
- The API user's role defines the ceiling of what any MCP caller can see, so create it deliberately.
- No direct database access is assumed for a hosted ProShop, so do not design around SQL; use the API and scheduled exports for bulk needs.
How it works
- 1
List tools by question
Write the ten questions staff ask most, then define one tool per question with explicit inputs and a short output.
- 2
Pick an SDK and language
Use an official MCP SDK, such as the TypeScript or Python one, and a GraphQL client library.
- 3
Implement auth
Load the ProShop token from a secret store, refresh it as the vendor requires, and never return it in any output.
- 4
Shape the outputs
Return labelled fields and record IDs only. Cap list sizes and say when results were truncated.
- 5
Choose the transport
stdio runs the server as a local child process for one analyst. Streamable HTTP behind sign-in serves a team and supports per-user checks.
- 6
Add logging and limits
Log caller, tool, arguments and result size. Add rate limits and a kill switch.
- 7
Test with real questions
Run your ten questions against several clients and compare answers with the ProShop screens before sharing.
Example flows
Planner asks about a job
Trigger: Question in an MCP client: what is blocking job 12345?
- Client calls get_work_order and list_open_pos.
- Server queries ProShop and returns trimmed results.
- Client explains the blocker and cites the PO and operation.
Result: A sourced answer without anyone navigating screens.
Quote engineer checks a part
Trigger: RFQ arrives for a part number already made
- Client calls find_part with the number.
- Server returns revision, material and last three work orders.
- Client summarises actual versus quoted hours from returned fields.
Result: The estimator starts from real history instead of memory.
Keeping data on-prem
The MCP server itself can run entirely inside your network on a small VM or container, so credentials, logs and caches never leave. It reaches out only to the ProShop API. Pair it with a model hosted on your own GPUs for a fully private assistant, since MCP does not require a specific model vendor. If you also use a hosted model, decide which tools are allowed to feed it and consider separate tool sets for sensitive and non-sensitive questions, selected by user group.
Security checklist
- Dedicated least-privilege ProShop API user per environment.
- Per-user sign-in on HTTP transport, with tool access by group.
- Audit log of every call, retained under your policy.
- Input validation on all arguments to prevent query abuse.
- Treat all returned text as untrusted; free-text fields can contain instructions that try to steer the model.
Ways to get it done
Use an existing community server
Effort: Days including review.
Only if you can review the code and its scope; otherwise risk outweighs the saved time.
Build and host your own
Effort: One to two weeks for a focused read-only set.
Best control; suitable if you have a developer and want to own logging and tools.
Netray builds it with you
Effort: Weeks, scoped by tool count and hosting.
When you want the server, a private model and an approval flow delivered together.
Pitfalls
- !Exposing a generic run-any-query tool, which defeats permission scoping.
- !Returning entire records so the model drowns in irrelevant fields.
- !Prompt injection through free-text notes that the model then obeys.
- !Shared credentials across all users, which destroys the audit trail.
- !Forgetting that schema and custom fields change after upgrades.
Frequently asked questions
Does ProShop publish an MCP server?
Check the vendor directly, as this changes. If one is not offered, building your own is straightforward because the work is mapping a handful of ProShop API queries to tools. Review any third-party server's code and permissions before connecting production data.
stdio or HTTP transport?
Use stdio when the server runs on one person's machine with their credentials. Use HTTP when several people share a hosted server, because it supports sign-in, central logging and per-user permissions. Most teams pilot on stdio and move to HTTP for rollout.
Which tools should come first?
Start with the questions asked daily: work order status, part lookup, PO status and customer open orders. All are read-only and low risk. Add NCR search next. Delay any write tool until read accuracy is proven and approvals are designed.
How do we limit who can see what?
Two layers. The ProShop API user role caps the maximum data. Your server then enforces per-user or per-group tool access on top. Never rely on the model to decline sensitive requests; enforce limits in code.
Will it work with ChatGPT as well as Claude?
MCP is an open protocol supported by a growing set of clients, including Claude. Support in other products varies by version and plan, so check current documentation. Building to the standard keeps your options open, and you can add a thin adapter if a client needs one.
Want MCP server working on your ProShop ERP?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment