How to build an MCP server for abas ERP
Short answer
An MCP server for abas ERP is a small service that exposes a handful of typed, read-only tools such as item lookup, order status and open purchase lines, backed by EDP, the Java object layer or REST. Any MCP client, including Claude and ChatGPT, can then use abas data within the permissions of a service account.
The Model Context Protocol gives AI clients a standard way to call tools. For abas that means you build the bridge once, and every compliant client can use it rather than each assistant needing its own custom integration.
The design question is not the protocol, which is simple, but what to expose. abas holds everything from price lists to personnel-adjacent data, and a careless tool can turn a helpful assistant into a data exfiltration path.
Start small. Five well-named tools with strict schemas will answer most planner and sales questions, and they are easy to review, test and audit.
What teams use it for
Part and stock lookup
A tool takes a part number or description fragment and returns master data, free stock and storage locations.
Order and job status
Tools return sales order lines and linked production order progress for questions from sales and customer service.
Open purchase lines
A tool lists open purchase order lines for a supplier or part with confirmed dates, supporting expediting.
Bill of materials explosion
A tool returns the multi-level structure of a product with quantities, used by engineering and planning.
Infosystem wrapper
A tool runs a named, pre-approved infosystem with limited parameters, reusing logic your team already trusts.
abas ERP integration surface
- EDP client: opens a session to the abas server, runs selections and reads fields. Many MCP servers for abas will start here.
- Java object layer: typed access to business objects, convenient when the server is written in Java or Kotlin.
- REST or integration endpoints in newer versions: simplest to call from Node or Python when your version supports the entities you need.
- Infosystem execution: running named infosystems with parameters can deliver curated outputs without querying raw tables.
- abas roles and client (Mandant) separation: your service user determines which client data is visible, and the server must target one client explicitly.
How it works
- 1
Write the tool contract first
For each tool define name, description, input schema with limits, and output fields. Descriptions should mention your local meaning of fields.
- 2
Pick language and SDK
Use the official MCP SDK in TypeScript, Python or Java depending on which abas client library you will use.
- 3
Implement the data layer
Wrap EDP or REST calls in functions that cap rows, whitelist fields and convert results to compact JSON.
- 4
Choose transport
Use stdio for single-user desktop tests. Use streamable HTTP behind a reverse proxy with authentication for shared use.
- 5
Add authentication and identity
Authenticate the MCP client to your server, then map the caller to an abas service role, ideally passing the end-user identity to the audit log.
- 6
Test with several clients
Try Claude, a ChatGPT-compatible client and an open-source client to confirm behavior. Check error handling and empty results.
Example flows
Where is part X
Trigger: User asks any MCP client about a part
- Client calls search_parts with the fragment
- Server runs a bounded selection and returns candidates
- Client calls get_stock for the chosen part
- Answer lists quantities by location
Result: A stock answer without anyone opening an abas screen.
Supplier exposure check
Trigger: Buyer asks about everything open with one supplier
- Client calls get_open_po_lines with the supplier
- Server returns lines with dates and values within a row cap
- Client groups by delay and highlights the oldest
Result: A quick conversation starter for a supplier call.
Keeping data on-prem
An MCP server is just a service, so it runs wherever your abas server is reachable. Deploy it on a host in the same network segment, expose HTTP only inside the plant or through a VPN, and pair it with a locally hosted open-weight model and an MCP-capable client. No part of the stack needs internet access after installation. For sites that must also use cloud assistants for certain tasks, run two server instances with different tool sets and permissions so the sensitive tools are never reachable from the cloud client.
Security checklist
- Read-only tools and a least-privilege abas service role to start
- Strict input schemas, row caps and field allow-lists on every tool
- Per-user identity in the audit log, even when one service account queries abas
- TLS and authentication on the HTTP transport, with no anonymous endpoints
- Treat all retrieved text as untrusted to limit prompt injection through records
Ways to get it done
Write it yourself with an SDK
Effort: Days for a prototype, weeks to harden.
Developers available and a small, well-understood tool set.
Partner-built connector
Effort: Depends on partner scope.
Your abas partner already knows the data model and the customisations.
Netray gateway
Effort: A scoped pilot, then extend tools.
You also want private models, evaluation and approval workflows around the server.
Pitfalls
- !Exposing a generic run-any-selection tool defeats the purpose of controlled access.
- !Opening a new EDP session per call exhausts licenses and slows responses. Reuse and pool sessions.
- !Tool results that are too verbose waste model context and invite hallucination. Return compact, labeled fields.
- !Skipping client selection can query the wrong Mandant. Make the client explicit in configuration.
- !No version pinning of the abas client library leads to breakage after server upgrades.
Frequently asked questions
What is an MCP server for abas ERP?
It is a service that exposes abas data and actions as named tools following the Model Context Protocol. AI clients discover those tools, call them with structured input, and receive structured results, all under the permissions of the service account you configured.
Which abas interface should it use?
Use the one that gives you the entities you need with the least risk. EDP and the Java object layer are broadly available. REST is attractive where your version supports it. Check your release documentation, as coverage varies.
Stdio or HTTP transport?
Stdio suits a single developer testing locally. HTTP is the choice for shared or server-side use, where you need authentication, TLS, logging and central updates. Most production abas deployments use HTTP inside the network.
Can the same server serve Claude and ChatGPT?
Often yes, since MCP is an open protocol and many clients support it. Client support, authentication options and remote server rules differ, so test each client you plan to use before promising it.
How do we stop it from changing data?
Expose only read tools, use an abas service role without write rights, and review any later write tool as a proposal flow with human approval. Defense in depth means both the server and the role forbid writes.
Want MCP server working on your abas 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