How to build an MCP server for Macola
Short answer
An MCP server for Macola is a small service that exposes read-only tools such as item lookup, order status, open POs and BOM availability over a curated database layer, authenticates the person calling it, and logs every call. Any MCP client, including Claude and ChatGPT, can then use the same tools.
If you intend to use more than one AI client with Macola, an MCP server is the right investment. Instead of wiring each assistant to the database separately, you build one governed tool layer and keep the business rules in one place.
The hard parts are not the protocol. They are deciding which Macola tables are the source of truth for each answer, handling the fact that database logins do not carry Macola's application roles, and keeping the tool surface small enough to audit.
This page is a design guide for that server: tool list, auth, transport, scoping and testing. It assumes you can read your Macola schema and have a developer comfortable with Python or TypeScript.
What teams use it for
Item and availability lookup
A tool takes an item number and returns description, unit of measure, on-hand by location, allocated and on-order, with the as-of time.
Order and shipment status
A tool takes an order number and returns header status, lines, ship dates, tracking and invoice reference.
Open purchase order search
A tool filters PO lines by vendor, item or days late so buyers can ask natural questions and get consistent rows.
BOM explosion
A tool returns the multi-level bill of material for an item with component availability, supporting shortage questions.
Customer and vendor card
A tool returns contact data, terms and open balance, with fields filtered by the caller's role.
Document finder
A tool locates attached specifications and certificates for an item or order and returns paths and metadata, not file bodies.
Macola integration surface
- Curated database views: define views per tool on SQL Server (Macola 100) or the equivalent ODBC accessible schema on Progress based installs. Views let you rename cryptic columns and hide restricted ones.
- Vendor web services or SDK: if your release offers them, use them for any later write tool because they enforce business rules the database does not.
- Authentication: Macola logins are separate from database logins. Map your identity provider user to a Macola user or role in the MCP server and enforce field rules there.
- As-of semantics: inventory changes during posting. Return a timestamp and make clear whether values include unposted batches.
- Custom fields: user-defined fields often hold promise dates or revision levels and should be surfaced explicitly in the tools that need them.
How it works
- 1
Write the tool contract first
For each tool, define name, description, input schema, output schema and row cap. Keep the first release to six to eight tools.
- 2
Build the views and test them with planners
Check outputs against what Macola screens show for 20 sample orders and items before wiring the model in.
- 3
Pick the transport
Use stdio for a single analyst's desktop client. Use streamable HTTP on the LAN behind your reverse proxy for team use, with TLS and per-user tokens.
- 4
Implement auth and field filtering
Resolve the caller from the token, look up allowed fields and filter outputs. Deny by default if the user is unknown.
- 5
Add audit logging
Write user, tool, arguments, row count, duration and a hash of the result to an append-only store.
- 6
Test with multiple clients
Try the server from Claude, ChatGPT where supported and an open-source MCP client, and verify tool descriptions lead each to use tools correctly.
- 7
Version and document
Version the tool schemas and publish a short guide so teams know what is available and what is not.
Example flows
Buyer asks about a late vendor
Trigger: Buyer types 'what is late from vendor ACME?'
- Client calls open_po_lines with the vendor filter.
- Server checks the caller's role and returns allowed fields.
- Client asks for item availability for the top three lines.
- Server returns on-hand and demand with an as-of time.
Result: A grounded answer with the PO numbers and quantities, and a log entry for each call.
Shortage question from the floor supervisor
Trigger: Supervisor asks if job 8841 can start.
- Client calls bom_availability for the job's item.
- Server explodes the BOM and joins availability.
- Client lists components short within the lead window.
Result: A yes or no with the exact components blocking the job.
Keeping data on-prem
An MCP server is naturally an on-prem component. Deploy it on a server inside the same network as the Macola database, with the read-only login stored in a local secrets store and no inbound internet access. Local clients reach it over the LAN. If a cloud-hosted assistant must use it, put a reverse proxy in front with mutual TLS or a VPN and expose only the HTTP endpoint, never the database port. For air-gapped sites, pair it with a locally served open-weight model and an MCP-capable client on the intranet. Resource needs are modest: the server is a lightweight service, while the model is where GPU capacity goes.
Security checklist
- Use a database login with SELECT on specific views only and deny access to base tables and system procedures.
- Require TLS and per-user tokens on the HTTP transport, never a single shared secret.
- Cap rows and response sizes per tool to limit data exfiltration through prompt injection.
- Treat tool arguments as untrusted and use parameterized queries only.
- Keep a separate, disabled-by-default module for any write tool, with its own credentials and approval flow.
Ways to get it done
Build it yourself with an MCP SDK
Effort: About 3 to 6 weeks for a first set of tools with auth and audit.
You have a developer who knows your Macola schema.
Generic database MCP server over your views
Effort: Days, but it exposes raw SQL style access, so keep it to a sandbox copy.
Quick experiments where role filtering is not yet needed.
Partner built, such as Netray
Effort: A scoped build of a few weeks and a handover.
You want tested patterns for role handling and on-prem deployment.
Pitfalls
- !Exposing a generic run_sql tool and discovering the model can read payroll or cost tables.
- !Skipping as-of timestamps and getting answers that disagree with the screen a minute later.
- !Too many overlapping tools, which makes models choose inconsistently.
- !Forgetting to test with large result sets, causing slow or truncated responses.
- !No audit trail, which blocks approval from your security team.
Frequently asked questions
Does Macola already provide an MCP server?
I am not aware of an official one. Ask your Macola reseller or vendor about current AI features, then plan to build or commission your own for control over data and roles.
Which tools should the first version include?
Start read-only: item lookup, order status, open PO lines, BOM availability, and a customer or vendor card. These cover most daily questions and are low risk. Add documents and writes later.
stdio or HTTP transport?
stdio is simple for one desktop user. HTTP is better for teams because you can centralize auth, logging and updates on a server. Most production deployments end up on HTTP behind a proxy.
How do we enforce Macola roles?
Database logins do not carry them, so the server maps each caller to a role table you define and filters fields accordingly. Keep that mapping reviewed by finance and operations owners.
Can ChatGPT use the same server?
If the ChatGPT product you use supports remote MCP connectors, yes, through the HTTP transport. Otherwise a thin adapter can expose the same tools. Verify current support with OpenAI.
Want MCP server working on your Macola?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment