# How to build an MCP server for SAP S/4HANA

> Source: https://netray.co/integrations/sap-s4hana-mcp-server
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Integrations

## 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.

## System

SAP S/4HANA

## Capability

mcp-server

## Intro

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.

## Use Cases

### Item and material lookup

**Description:** 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

**Description:** Tools for sales order, outbound delivery and billing status let customer service answer where an order is without opening SAP GUI.

### Stock and availability

**Description:** 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

**Description:** Tools read open PO items, schedule lines and confirmations so a buyer or agent can find late supply.

### BOM and routing explorer

**Description:** Read tools return multilevel BOM and routing data for a material, useful for cost, engineering change and shortage analysis.

### Production order status

**Description:** A tool reads order header, operations confirmation status and component withdrawals for a released production order.

## System 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

### Write the tool list as business questions

**Detail:** 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.

### Map each tool to a backend call

**Detail:** 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.

### Implement the server with an MCP SDK

**Detail:** 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.

### Choose transport

**Detail:** 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.

### Implement the permission layer

**Detail:** 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.

### Add audit and tests

**Detail:** 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.

**Steps:**

- 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.

**Steps:**

- 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.

## 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

- 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.

## Options

### Adopt an open-source SAP MCP server

**Fit:** Good for experiments and learning. Review code and maintenance before pointing it at production.

**Effort:** Hours to days.

### Build your own thin server

**Fit:** Good when you have a TypeScript or Python developer and know your SAP services.

**Effort:** One to three weeks for a first read-only server with tests.

### Have a partner such as Netray build and harden it

**Fit:** Good when you want audit, scoping and an on-prem model delivered together.

**Effort:** Weeks, including security review and rollout.

## 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.

## Faq

### Which tools should an S/4HANA MCP server expose first?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

sap s4hana mcp server, mcp server for sap, build mcp server sap s/4hana, model context protocol sap, sap odata mcp, sap mcp claude, sap mcp chatgpt, sap s4hana mcp tools, on-prem mcp server sap, mcp sap bapi

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json