Connect Claude Code to SAP ECC 6.0 with sap-mcp-server

What you need

• Python 3.10 or newer, and Node.js 22.14 or newer for the RFC tools. The OData tools work without Node.
• An SAP user with the authorisations you intend to grant: the Gateway service authorisations for the OData services you use; S_RFC restricted to the function groups the tools call, plus S_TABU_DIS or S_TABU_NAM for read_table. Which checks apply depends on your release and security notes; ask your Basis team.
• Network access from the machine running the server to the Gateway HTTPS port and to the RFC path, usually the direct gateway port 33NN where NN is the system number; message-server logon, SAProuter, gateway ACLs and SNC change what has to be open.
• A sandbox first. An ECC 6.0 IDES or an S/4HANA appliance from SAP Cloud Appliance Library is enough; CAL appliances need an S-user and the hyperscaler infrastructure is billed to you. Never use a production system or a production user for a first run; the licensing and supportability questions for production are covered on the service page.

Install

git clone https://github.com/romankorim/sap-mcp-server.git
cd sap-mcp-server
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
cd rfc-bridge && npm install && cd ..
chmod +x run.sh

Configure .env

Copy .env.example to .env and fill in the connection. The file is re-read on every tool call, so a changed host or password takes effect without restarting the client. The password sits in plain text in that file, which is acceptable only for a sandbox user; a pilot takes the credential from a vault. Values in .env take precedence over the process environment. Claude Desktop starts servers with a minimal PATH, so on macOS NODE_BIN is usually needed.

SAP_BASE_URL=https://<host>:<port>/sap/opu/odata/sap
SAP_CLIENT=100
SAP_USER=<technical user>
SAP_PASSWORD=<password>
SAP_ASHOST=<application server host>
SAP_SYSNR=00
SAP_LANG=EN
SAP_VERIFY_TLS=1
NODE_BIN=/usr/local/bin/node
AUDIT_LOG_PATH=audit.jsonl

Add it to Claude Code

One command registers the server; then ask Claude Code to run sap_ping and rfc_ping, which are the two connection tests.

claude mcp add sap -- /absolute/path/to/sap-mcp-server/run.sh

Add it to Claude Desktop

Quit Claude Desktop completely before editing the config file; the app rewrites claude_desktop_config.json from memory when it quits and overwrites any edit made while it is running. The file is in ~/Library/Application Support/Claude/ on macOS and in %APPDATA%\Claude\ on Windows. Start the app again and the sap tools appear in the tools list.

{
  "mcpServers": {
    "sap": {
      "command": "/absolute/path/to/sap-mcp-server/run.sh",
      "args": []
    }
  }
}

First calls on ECC

• sap_ping reads the Gateway service catalog; rfc_ping calls RFC_SYSTEM_INFO and returns SID, host, release and database.
• table_fields('MARA') returns field names, types and descriptions from DDIF_FIELDINFO_GET, so you can pick a field list before reading.
• read_table('MARA', 'MATNR,MTART,MATKL', "MTART = 'FERT'", 20) reads twenty finished products through RFC_READ_TABLE. Pass a field list on wide tables; one row is limited to 512 bytes, cluster tables and some views do not work, and the function checks the technical user's table authorisations (S_TABU_DIS or S_TABU_NAM, depending on your release and security notes), not application-level or organisational authorisations.
• list_services('API_') lists the OData services registered on the Gateway. On ECC the S/4HANA API_* services are normally absent; check what is registered, then point SAP_SVC_* and SAP_ES_* at your own Z services or stay on RFC.
• bapi_call runs only names on the READ_BAPIS allowlist in rfc_tools.py, the GETLIST, GETDETAIL and GETOPENITEMS families; everything else is rejected. Extending the list is a code change, not a runtime option.
• create_purchase_requisition returns a proposal; the SAP write itself is not in the published server. A confirm flag from an MCP client is not an approval control, so in a pilot the write is enabled per BAPI after the customer's IT team approves it, with a confirmation step the customer's security team has accepted.

What the audit log records

Every call appends one JSON line to AUDIT_LOG_PATH: time in UTC, the SAP account, the tool, the arguments, the status, the duration and a note. The user field is the technical SAP account, not the person; a pilot adds the person's identity from the sign-in layer. On a laptop it is a file that can be edited or deleted; in a pilot it is forwarded to the customer's log store or SIEM, which is the control. Treat it as sensitive; it contains every query sent to SAP.

{"ts": "2026-10-19T09:12:44+00:00", "user": "SAPUSER", "tool": "read_table", "args": {"table": "MARA", "fields": "MATNR,MTART,MATKL", "where": "MTART = 'FERT'", "max_rows": 20, "skip_rows": 0}, "status": "ok", "ms": 412, "note": "rfc_user=SAPUSER"}

Limits you will hit on ECC

• RFC_READ_TABLE returns each row as one character line of at most 512 bytes; wide tables need an explicit field list, and selecting RPRCTR from FAGLFLEXT fails on the systems we tested.
• The where argument is split into 72-character OPTIONS lines on whitespace; a single token longer than 72 characters is rejected.
• odata_query caps top at 200; OData V2 only.
• Tables with credentials, secrets or personal data (USR*, USH*, RSEC*, SEC*, PA0*, PA9*, HRP*, T77*, RFCDES, SECSTORE, the SSF_PSE tables) are refused unless SAP_ALLOW_SENSITIVE_TABLES=1 is set for an audited admin session. The denylist is a sandbox guard, not a data classification: personal data can sit in almost any standard or Z table, so a pilot classifies the tables it reads.
• The RFC bridge starts a Node process per call, with no connection pooling, so each call opens a new logon.
• The TED tenders connector answers with HTTP 429 above roughly ten requests per minute.

From sandbox to a governed pilot

What changes for production is code and operations, not only configuration: a scoped technical user per deployment with only the roles the use case needs, released interfaces instead of RFC_READ_TABLE for each production process, SNC on the RFC path and TLS on HTTPS, the credential in a vault, personal identifiers masked in the server before the model sees them, sign-in through the company directory with the person's identity in the audit line, the model under the customer's own EU cloud account, the audit log forwarded to the SIEM, a pinned release with a dependency list, and SAP's contractual answer on named-user, indirect-access and Digital Access terms before anything writes. Named-user propagation is on the roadmap. That is what a six-week pilot builds.

Questions we get asked

Does it work with S/4HANA as well as ECC?

Yes. On S/4HANA the convenience tools use the standard API_PRODUCT_SRV, API_PRODUCTION_ORDER_2_SRV and API_PURCHASEORDER_PROCESS_SRV services; on ECC those services do not exist, so you point the SAP_SVC_* and SAP_ES_* variables at your own Z services or use the RFC tools.

Is open-rfc supported by SAP?

No. open-rfc is an independent implementation of the RFC protocol. Use it on an isolated sandbox with non-production data; it handles SAP credentials, so it is not exempt from a security review because the calls are read-only. For production, run the bridge on SAP's NetWeaver RFC SDK with PyRFC, which the server supports; SAP supports the SDK, not PyRFC or this server, and your Basis team decides.

Does it need SAP BTP?

No. The server talks to the Gateway over HTTP and to the application server over RFC. BTP is not part of the setup.

Can Claude write to SAP through it?

Not through the published server; it is read-only. In a pilot a write is enabled per BAPI from an allowlist, after the customer's IT team approves it, and runs only after a named person confirms the proposal.

Is my SAP data sent to Anthropic?

The server sends data only to SAP and to the MCP client you connected. What the client does with it depends on which Claude you use and how its account is configured: Claude Code through your Anthropic, Bedrock or Vertex account. In a pilot we run the model on Amazon Bedrock in the Frankfurt region under the customer's own account, with the retention and logging configuration documented.

What licence and who maintains it?

MIT. The server is maintained by iteractive.ai. We sell production deployments, the security layer and support.

Is your ECC ready for Claude?

A 30-minute technical readiness check: which interfaces your ECC exposes, which roles a pilot needs, where the model would run, the licensing questions for your SAP account team, and a two-page summary you can forward. Sandbox demo on request.

Request the ECC readiness check

Or write to us directly: info@iteractive.ai · +421 905 452 325