How to build an MCP server for proALPHA
Short answer
An MCP server for proALPHA is a small service that exposes a handful of read-only tools, such as item lookup and order status, backed by OpenEdge SQL or proALPHA services. Any MCP client, including Claude and ChatGPT, can then use it under your auth and audit rules.
The Model Context Protocol gives AI clients one way to call tools on a system. For proALPHA that is valuable because you write the integration once, and it serves Claude, ChatGPT where MCP is supported, IDE assistants and your own agents. Without it, each assistant needs its own custom connector to the same OpenEdge data.
The hard part is not the protocol. It is deciding which tools exist, what they return, and who may call them. A proALPHA installation has years of customisation, and a loose tool such as run_query will quickly produce confident, wrong answers and uncomfortable access questions.
This page treats the MCP server as an integration product: a small, versioned set of tools with tests, authentication, scoping and logs. Start read-only and keep it boring.
What teams use it for
Item and BOM lookup
Tools return item master data, units, lead time and a BOM explosion to a given depth, so any assistant can answer structure questions accurately.
Order and delivery status
A tool returns customer order lines with promised dates, linked production orders and last goods issue.
Inventory and availability
Stock by warehouse and lot, with open demand and supply, for available-to-promise style questions.
Purchasing visibility
Open PO lines by supplier with confirmation status, used by expediting assistants.
Quality and traceability read access
Where your installation holds lot and inspection data, a tool returns the genealogy of a lot for recall questions.
Resources for reference data
MCP resources can serve code lists and field glossaries, so the model uses your names for plants, order types and statuses.
proALPHA integration surface
- OpenEdge SQL-92 over ODBC or JDBC against a read-only account on a replica is the simplest backend for read tools. Schema and field names vary by proALPHA release and customisation, so keep queries in versioned files.
- OpenEdge application server services: where your release exposes web service or REST style access, tools can call them to inherit proALPHA business rules and authorisation.
- Stored exports and interface directories: older sites often rely on file-based interfaces. A tool can read the latest export when live access is not permitted.
- Proalpha user and rights model: decide whether tools run under one service identity with scoping done in your code, or under per-user credentials. The first is simpler, the second is stricter.
- Document storage: certificates and drawings referenced by items can be served as resources or fetch tools.
How it works
- 1
Write the tool catalogue first
Name each tool, its inputs, outputs and the proALPHA source. Keep to six to ten. Use verbs and explicit parameter descriptions.
- 2
Implement with an official SDK
Python or TypeScript SDKs handle the protocol. Validate every input, cap result sizes and return structured JSON.
- 3
Choose the transport
stdio suits a developer workstation. Streamable HTTP suits shared use behind your gateway, with TLS and token authentication.
- 4
Connect and scope the data
Use a read-only OpenEdge account. Add company, plant and customer filters in code, driven by the caller's identity claim.
- 5
Authenticate callers
Use OAuth or your identity provider's tokens for HTTP. Map the caller to allowed plants and tool lists.
- 6
Add audit and rate limits
Log tool name, parameters, row counts and caller. Limit calls per minute to protect OpenEdge.
- 7
Test with several clients
Check Claude, a ChatGPT-compatible MCP client if available, and a local model client. Fix descriptions where tools are misused.
Example flows
Availability question from any client
Trigger: User asks whether 200 units of an item can ship Friday
- Client calls item_lookup to resolve the item number.
- It calls stock_by_item and open_supply.
- It calls open_demand for competing orders.
- It answers with the numbers and constraints cited.
Result: A grounded answer from the same tool layer, whichever assistant the user prefers.
Recall scoping
Trigger: Quality asks which customers received a lot
- Tool returns lot genealogy for the supplied lot number.
- Tool lists shipments containing derived lots.
- Client formats a customer list for review.
Result: A candidate list in minutes, with the final decision left to quality staff.
Keeping data on-prem
An MCP server is naturally on-prem friendly: it is just a service next to OpenEdge. Keep it in the same network, expose it only to internal clients, and pair it with a local MCP-capable client and an open-weight model if no hosted AI is allowed. For air-gapped sites, package the server with pinned dependencies and deliver updates through controlled transfer. If you do allow hosted clients, publish the HTTP transport only through a gateway with strong authentication, and consider returning less detail to external callers than to internal ones.
Security checklist
- Read-only database identity and a hard allow-list of tools; no arbitrary SQL tool.
- Server-side scoping by plant and company from the verified caller identity, never from a model-supplied parameter.
- Token authentication, TLS and rate limits on the HTTP transport.
- Result size caps and field redaction for prices or personal data by role.
- Immutable audit logs, and a way to disable a tool quickly.
Ways to get it done
Use a generic database MCP server
Effort: Hours, but poor control and weak answers on customised schemas.
Throwaway exploration on a test copy.
Build a custom server in-house
Effort: Two to four weeks for a tested read-only catalogue.
Teams with OpenEdge and Python or TypeScript skills.
Partner build with Netray and your proALPHA partner
Effort: A scoped pilot of a few weeks.
When you want the tool layer, evaluation set and a private model delivered together.
Pitfalls
- !Exposing run_sql, which the model will use creatively and your DBA will not like.
- !Returning entire tables, which wastes context and leaks data.
- !Taking the plant filter from a tool argument the model can change.
- !Vague tool descriptions, so the client picks the wrong tool.
- !Skipping version control for queries, so a schema change breaks answers silently.
Frequently asked questions
What is an MCP server for proALPHA?
A service that speaks the Model Context Protocol and exposes named tools backed by proALPHA data, usually through read-only OpenEdge SQL or exposed services. AI clients call the tools instead of needing a custom integration each.
Is there an official proALPHA MCP server?
We are not aware of one, and this may change. Ask your proALPHA partner. Otherwise you build a small server, which is practical because the tool set is narrow.
Should tools be able to write?
Not initially. Add write tools only with explicit approval steps and by calling proALPHA services so standard validation runs. Keep read and write tools in separate permission groups.
stdio or HTTP?
Use stdio for a single user on a controlled workstation. Use HTTP for shared access, with TLS, token authentication, rate limits and logging. Most production plants end up on HTTP behind a gateway.
Will it work with local models?
Yes, if the client supports MCP. Tool-calling reliability varies by model, so test your catalogue with the model you plan to run on-prem and simplify tool descriptions where needed.
Want MCP server working on your proALPHA?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment