How to build an MCP server for MRPeasy
Short answer
An MRPeasy MCP server is a small service that wraps the MRPeasy REST API as named, read-only tools such as item lookup, order status, stock and BOM. It authenticates to MRPeasy with an API key, serves tools over stdio or HTTP, and works with Claude, ChatGPT and other MCP clients.
A Model Context Protocol server is the part that decides what an AI client can do inside your system. For MRPeasy, which has no local database to query, it is also the only place where API credentials live. Getting its design right matters more than which model sits on top.
The temptation is to expose the whole API generically. That produces an assistant that can do anything and explains nothing. A better design is a short list of tools, each answering a question your planners already ask.
This page walks through the tool list, the authentication model, transport choices and logging for a server you could build in a week. It assumes you can read the MRPeasy API documentation for your account to confirm exact paths and field names.
What teams use it for
Item and product lookup
Find an item by code or description and return its unit, lead time, default vendor and current stock in one compact result.
Customer order status
Given an order number, return lines, promised dates, linked manufacturing orders and shipment state.
Open purchase orders by part
List outstanding POs for a part with quantity, vendor and expected date, to answer where is the material.
BOM explode
Return a multi-level bill of materials for a product with quantities per level and the stock status of each component.
Capacity and job queue view
Return manufacturing orders scheduled on a work center for a date range, for questions about loading.
Search customers and vendors
Resolve a name to an ID so other tools can be called safely without the model guessing identifiers.
MRPeasy integration surface
- REST API over HTTPS authenticated with an API key and secret from the integration settings. Confirm the base URL and version path in your own account documentation.
- Resource families most useful for tools: items, products and BOMs, customer orders, manufacturing orders, purchase orders, vendors, customers and stock. Names and fields vary slightly by version.
- Pagination and filtering parameters differ by endpoint. Read them before designing tool arguments.
- API rate limits: put a token bucket and a short-lived cache in the server.
- Webhooks, where your plan supports them, can invalidate cache entries. Otherwise use modified-since polling.
How it works
- 1
Define the tool contract
Write each tool as a name, a one-line description for the model, input arguments with types, and a bounded output schema.
- 2
Implement with an MCP SDK
Use the official TypeScript or Python SDK to register tools and handle requests. Keep each handler a thin call to an API client class.
- 3
Wrap the MRPeasy client
Centralise authentication, retries with back-off, pagination and error mapping so tools never see raw HTTP errors.
- 4
Choose the transport
Stdio is simplest for one user running a local process. Streamable HTTP suits a shared server, where you add authentication and TLS.
- 5
Add caching and limits
Cache static lookups such as items for minutes, order data for seconds, and cap result sizes with a clear truncated flag.
- 6
Add audit logging
Record the caller, tool, arguments, duration and row count for every call, without logging secrets.
- 7
Test with a real client
Use an MCP inspector and then a client like Claude to run a script of 30 questions with known answers.
Example flows
Where is my material
Trigger: A user asks a connected client where a specific part is.
- The client calls search_items to resolve the part number.
- It calls open_purchase_orders with the item ID.
- The server returns vendor, quantity and expected date per line.
- The client summarises and notes any overdue line.
Result: A direct answer with record references, produced from two bounded calls.
BOM stock check before quoting
Trigger: Sales asks if a product can ship in four weeks.
- The client calls bom_explode for the product.
- It calls stock_for_items on the component list.
- The server marks components short or covered.
- The client lists shortages and their vendor lead times.
Result: Sales gets a grounded yes, no or maybe with the blocking parts named.
Keeping data on-prem
Run the MCP server inside your own network or private cloud even though MRPeasy is a hosted service. The server then becomes the single controlled egress point: it makes outbound HTTPS calls to the MRPeasy API, and nothing else in your environment needs vendor credentials. Pair it with an open-weight model served locally and you have an AI assistant over ERP data without any prompt leaving your site. If you prefer a cloud model, the same server can sit behind a private endpoint with an allowlisted client. For air-gapped sites, synchronise a nightly export into a local store and point the tools there instead of the live API, accepting that answers are as fresh as the last sync.
Security checklist
- Store the API key and secret in a secrets manager and load them at start-up.
- Make every tool read-only in version one. Add writes only as separately named tools with confirmation.
- Authenticate HTTP clients with OAuth or signed tokens and map users to allowed tools.
- Validate and bound all arguments to prevent broad scans, and cap output size.
- Log calls for audit and alert on unusual volume or off-hours use.
Ways to get it done
Generic REST-to-MCP gateway
Effort: Hours to days
Fast prototype from an OpenAPI file, but exposes too many raw endpoints for production.
Hand-built MCP server with curated tools
Effort: 1-2 weeks
The recommended path for most teams: few tools, clear descriptions, tight outputs.
Partner build with Netray
Effort: Typically a few weeks for a scoped pilot
When you want role-based tool scoping, evaluation harness and an on-prem model option included.
Pitfalls
- !Writing vague tool descriptions. The model picks tools from them, so be precise about when to use each.
- !Returning full API payloads. Trim to the fields the question needs.
- !Ignoring ID resolution. Always give the model a search tool so it never fabricates an ID.
- !One shared credential with no per-user identity in the logs.
- !Skipping pagination so large lists silently truncate and the model reports a wrong total.
Frequently asked questions
What tools should the first version have?
Five to eight read-only tools: search items, get item and stock, get customer order, get manufacturing order, open purchase orders by item, BOM explode, and search customers and vendors. Anything that writes can wait until reads are proven.
Stdio or HTTP transport?
Use stdio when one person runs the server locally with their own credentials. Use HTTP when a team shares a hosted server, which also lets you add central authentication, rate limits and logging. Most production deployments end up on HTTP.
Does it work with ChatGPT as well as Claude?
MCP is an open protocol supported by a growing set of clients, including Claude and ChatGPT in some product surfaces. Client support and connector rules change, so confirm your plan's capabilities, but the server itself is client-neutral.
How do I handle MRPeasy rate limits?
Add a client-side token bucket, cache repeated lookups briefly, and make tools return summaries. If usage grows, sync data into a local database on a schedule and let the tools read from that.
Is there an existing MRPeasy MCP server I can install?
Community servers may exist, but we cannot vouch for any. If you try one, read the code, check which API operations it calls, restrict the key's access, and prefer your own curated version for production.
Want MCP server working on your MRPeasy?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment