How to build an MCP server for QAD Adaptive ERP
Short answer
An MCP server for QAD is a small service that exposes named, typed tools such as item lookup, order status and BOM explosion. It reads from an OpenEdge replica or QAD web services, authenticates each caller, enforces domain and site scope, and logs every call. Start read-only and add writes through QXtend later.
The Model Context Protocol gives AI clients a standard way to call tools. Instead of a custom integration for every assistant, you build one server in front of QAD and any MCP-capable client can use it, including Claude and other agent frameworks.
For QAD the interesting design work is not the protocol. It is deciding the tool surface. A good tool maps to a question a planner or buyer actually asks, returns a small structured result, and cannot be abused to dump the database.
This page is a design guide for the server itself: tools, data access, auth, transport and operations.
What teams use it for
Inventory and availability
A tool returns on-hand, allocated and on-order for an item by site and location, so any assistant can answer stock questions consistently.
Order status
Look up a sales order or purchase order with line status, dates and open quantities, without exposing cost fields to roles that should not see them.
Multi-level BOM explosion
A tool walks the product structure to a given depth and returns components with quantities per, useful for shortage and where-used questions.
Work order and routing status
Return the work order's operations, quantities complete and current queue, for supervisors asking what is blocking a job.
Supplier performance
Aggregate on-time receipts and rejects per vendor over a period, computed in the server so the model gets a summary, not raw rows.
Read-only schema help
A documentation tool returns field meanings from your own data dictionary notes, which keeps the model from guessing at cryptic OpenEdge field names.
QAD Adaptive ERP integration surface
- OpenEdge SQL-92 through JDBC or ODBC against a replica, the best route for fast read tools; check the driver licensing for your OpenEdge version.
- QXtend inbound services for any future write tool, so QAD business logic and validations run.
- QAD web services and APIs for functions that are only available through application logic rather than tables.
- Authentication sources: your identity provider for users, plus a mapping to QAD users, domains and sites.
- Schema dictionary: OpenEdge metadata plus your own notes, since customisations often add fields and tables.
How it works
- 1
Write the tool catalogue first
List ten questions people ask. Turn each into a tool with a precise name, description, and typed parameters.
- 2
Implement with an MCP SDK
Use the official TypeScript or Python SDK. Keep each tool function small, parameterised and covered by tests.
- 3
Connect to the replica
Use a pooled, read-only connection with query timeouts and row limits. Never accept free-form SQL from the model.
- 4
Add authentication
For a remote server use an authenticated HTTP transport and map the caller to allowed domains and sites. For local developer use stdio is simpler.
- 5
Add result shaping
Return concise JSON with units and descriptions. Truncate large lists and tell the caller how to page.
- 6
Add audit and metrics
Record user, tool, arguments, row count and latency. Alert on unusual volume.
- 7
Introduce writes last
A propose_ tool stores a draft; a human approves; a separate service submits through QXtend.
Example flows
Shortage check from an AI client
Trigger: A planner asks the assistant whether work order 5521 can start.
- Client calls get_work_order_components for the order.
- It calls get_item_availability for each short component.
- It calls get_open_pos for items still short.
- It composes an answer with expected receipt dates.
Result: A multi-screen lookup becomes one question, and each tool call is logged.
Developer exploring a data model
Trigger: A consultant connects a local MCP client by stdio to a test environment.
- The client calls describe_table with a table name.
- The server returns field names, types and your notes.
- The consultant asks for sample rows with a row limit.
- Results guide the design of new reports.
Result: Faster discovery on a test copy without giving anyone production credentials.
Keeping data on-prem
An MCP server is inherently suited to on-prem QAD because it runs wherever you put it. Deploy it on a server in the same network zone as the OpenEdge replica, front it with your reverse proxy and identity provider, and point a locally hosted model at it. The clients can be desktop AI applications used by staff or an internal web assistant. Open ports only to the client networks that need them. If staff use a cloud-hosted client, the tool results will travel to that provider, so make the tool surface reflect what you are willing to send. For air-gapped sites, run the model, the server and the clients in the isolated segment and move updates in through your normal change process.
Security checklist
- No generic SQL tool. Every tool is parameterised with allow-listed tables and fields.
- Authenticate each caller and apply domain and site filters inside the server.
- Separate read and write credentials, and keep write tools disabled until approval flows exist.
- Rate limit and cap result sizes to limit accidental or malicious bulk extraction.
- Log all calls immutably and review regularly.
Ways to get it done
Generic database MCP connector
Effort: An afternoon
Local exploration on a test database by a technical user.
Purpose-built QAD MCP server in-house
Effort: 3 to 6 weeks for a solid read-only version
Teams with OpenEdge knowledge and a developer to maintain it.
Netray-built server with approvals
Effort: A few weeks for an initial scope
When you want curated tools, auditing and a private model alongside.
Pitfalls
- !Tool names and descriptions that overlap, which confuses model selection.
- !Returning raw rows with cryptic OpenEdge field names instead of labelled output.
- !Forgetting domain and site filters in a multi-entity install.
- !Pointing at production without timeouts, causing slow queries to affect users.
- !Treating the server as a one-off script with no tests, versioning or monitoring.
Frequently asked questions
What is an MCP server in plain terms?
A service that tells an AI client which tools exist and runs them on request. For QAD, each tool is a controlled query or business function, such as get open POs for a supplier, with results returned in a clean format.
Stdio or HTTP transport?
Stdio suits local single-user development. For shared team use, run the server over authenticated HTTP behind your proxy so access control, logging and updates are centralised.
Can the same server serve Claude and ChatGPT?
In principle any MCP-capable client can use it, though client support and connector rules vary by product and plan. Keep the server standards-compliant and test with each client you intend to use.
Should I expose write tools?
Not at first. Add propose-style tools that create drafts, then submit approved changes through QXtend under a named user so QAD validation and audit fields apply.
Does QAD provide one out of the box?
Do not assume. Ask QAD what is available for your release. If nothing fits, a small custom server over a replica is a manageable project.
Want MCP server working on your QAD Adaptive 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