How to build an MCP server for SAP S/4HANA
Short answer
An MCP server for S/4HANA is a small service that turns released OData calls (or wrapped BAPIs) into typed tools such as get_material, get_po_status and get_stock. Start read-only, authenticate to SAP with a scoped user or OAuth, serve over stdio for local use or HTTP for shared use, and log every call.
The Model Context Protocol gives AI clients a standard way to discover and call tools. For S/4HANA that means you write the SAP integration once and reuse it with Claude, ChatGPT-compatible clients, IDE assistants and your own agents, instead of building a custom plugin for each.
What matters most is not the protocol code, which is short, but the tool design. SAP exposes hundreds of services and thousands of fields. A model given all of that will wander. A good S/4HANA MCP server offers a dozen tools named after business questions, returns small labeled results, and refuses anything outside its scope.
This page lays out the tool list, the SAP backends behind each tool, authentication, transport choices and the permission model that keeps the server safe in a system that carries financial postings.
What teams use it for
Item and material lookup
Tools return material description, base unit, MRP type, procurement type and plant data so users can ask about parts in plain language.
Order and delivery status
Tools for sales order, outbound delivery and billing status let customer service answer where an order is without opening SAP GUI.
Stock and availability
A stock tool reads unrestricted, quality inspection and blocked quantities per plant and storage location, so a planner can check coverage quickly.
Purchase order and supplier follow-up
Tools read open PO items, schedule lines and confirmations so a buyer or agent can find late supply.
BOM and routing explorer
Read tools return multilevel BOM and routing data for a material, useful for cost, engineering change and shortage analysis.
Production order status
A tool reads order header, operations confirmation status and component withdrawals for a released production order.
SAP S/4HANA integration surface
- Released OData services from the SAP Business Accelerator Hub: product, business partner, sales order, purchase order, material stock and production order services. Names and V2 or V4 variants differ by release, so inspect your own service catalog.
- ABAP CDS views (I_ interface views) published as OData through RAP or Gateway, ideal for joins that no single standard service provides, such as availability across storage locations.
- BAPIs and function modules over RFC (for example BAPI_MATERIAL_AVAILABILITY and BOM readers) as a fallback on-prem. Use a connector such as the SAP NetWeaver RFC SDK or a Java or Python wrapper, and keep it read-only.
- Authentication: OAuth 2.0 or basic auth to a communication user in cloud editions; on-prem choices include basic, client certificate or SAML bearer assertion through the Gateway.
- Metadata: the $metadata document of each service gives field names and types, useful for generating typed tool schemas, though you should hand-trim the output.
How it works
- 1
Write the tool list as business questions
Draft ten to fifteen tools with names and one-sentence descriptions. 'Which POs are open for vendor X' beats 'query EKPO'. Cut anything you cannot test.
- 2
Map each tool to a backend call
Prefer a released OData service or CDS view. Use BAPI or RFC only where nothing else exists, and avoid direct table reads from other systems because they bypass authorization checks.
- 3
Implement the server with an MCP SDK
Use an official SDK in TypeScript or Python. Define input schemas with enums for plant and company code, and return compact JSON with labeled fields and units.
- 4
Choose transport
Use stdio for single-user desktop testing. Use streamable HTTP behind your SSO and reverse proxy for shared use, with TLS and per-user tokens.
- 5
Implement the permission layer
Check the caller's allowed plants and tools before calling SAP, and call SAP with the narrowest user possible. Cap row counts and field lists in code, not in the prompt.
- 6
Add audit and tests
Log caller, tool, arguments, duration and result size to a store the server cannot edit. Write tests against a sandbox client that cover empty results, pagination and authorization errors.
Example flows
Part availability check
Trigger: A user asks any MCP client whether a material is available in a plant.
- Client discovers the get_stock tool and calls it with material and plant.
- The server checks the user's plant scope.
- It calls the material stock service and open PO receipts.
- It returns unrestricted, quality and blocked quantities plus next expected receipt.
Result: A clear answer with sources, in one call.
Blocked write attempt
Trigger: An agent tries to call a tool that would change a purchase order.
- The server finds no such tool in the read-only profile.
- It returns a clear error explaining that writes are disabled.
- The attempt is logged with caller and prompt context.
Result: The model cannot change SAP data, and the attempt is visible to administrators.
Keeping data on-prem
The server is a plain service, so it runs wherever your SAP network allows: next to the Gateway hub, in an integration zone or on a plant server. Pair it with a self-hosted model and the whole chain stays on premises. The only network rule required is server to SAP Gateway, plus client to server over TLS. In air-gapped sites package the server as a container or a signed artifact, pin dependencies and import them through your internal registry. If SAP system and Gateway are separate on-prem components, point the server at the Gateway that fronts the released services you actually use.
Security checklist
- Run with a technical user holding display authorizations only, limited to the plants and company codes the tools need.
- Enforce limits in code: maximum rows, allowed fields, allowed services. Never rely on the model's good behavior.
- Protect the HTTP transport with TLS, SSO and per-user tokens, and never expose the server to the public internet.
- Keep secrets in a vault, not in the tool config that a client can read.
- Treat tool arguments as untrusted input. Validate formats and escape OData filters to prevent injection into queries.
Ways to get it done
Adopt an open-source SAP MCP server
Effort: Hours to days.
Good for experiments and learning. Review code and maintenance before pointing it at production.
Build your own thin server
Effort: One to three weeks for a first read-only server with tests.
Good when you have a TypeScript or Python developer and know your SAP services.
Have a partner such as Netray build and harden it
Effort: Weeks, including security review and rollout.
Good when you want audit, scoping and an on-prem model delivered together.
Pitfalls
- !Exposing a generic 'run OData query' tool. It invites broad reads and wrong filters.
- !Returning raw SAP field names such as MATNR and WERKS without labels, which confuses both models and users.
- !Skipping pagination, so a vendor with thousands of PO lines floods the context.
- !Using one powerful user for everyone. Tools should respect the caller's scope.
- !Not versioning tool descriptions. Changes to a description change model behavior, so test them.
Frequently asked questions
Which tools should an S/4HANA MCP server expose first?
Read-only business lookups: material, stock, sales order status, PO status, BOM and production order status. These cover most questions, carry low risk and are easy to test. Add reports and write drafts later, one at a time.
Should it use OData or RFC?
Prefer released OData services or CDS views because they are supported, versioned and authorization-aware. Use BAPIs over RFC only where no suitable service exists, and still keep them read-only until you have audit and approval in place.
stdio or HTTP transport?
stdio is fine for one user on one machine. For a team, use HTTP behind SSO so identity, logging and rotation are central. HTTP also lets you run the server near SAP rather than on laptops.
Does it work with clients other than Claude?
MCP is an open protocol, so any compliant client can use it, including several IDE assistants and agent frameworks. Support for features such as remote servers varies by client, so test the ones you plan to use.
How do we handle SAP authorizations?
Best is to call SAP as the end user through OAuth or a bearer assertion so roles apply automatically. If you use a technical user, replicate the scope in your server by plant and tool, and keep it strictly read-only.
Want MCP server working on your SAP S/4HANA?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment