1. Introduction
What if SAP BASIS administrators/consultants could ask an AI assistant “Are there any ST22 dumps today?”, “Which background jobs failed?”, or “Show me the busiest users in ST03N”, and receive live data from an SAP system rather than generic troubleshooting advice?
This article documents a working proof of concept that connects ChatGPT to an on-premise SAP S/4HANA 2023 system through the Model Context Protocol (MCP), Python, PyRFC and SAP NetWeaver RFC SDK. The integration currently exposes six read-oriented operational tools. It does not require SAP BTP, SAP Cloud Connector or OData for its RFC-based architecture.
The focus is reproducible architecture, actual implementation details, lessons learned and the security boundaries needed before considering production deployment.
2. Architecture
The MCP listener is bound to loopback, not the VM LAN interface. This reduces direct network exposure, but does not itself authenticate remote users. The tested plugin was configured without authentication; that setting is appropriate only for a tightly controlled PoC, not a shared or production service.
3. Tested environment
The following components were used in the working proof of concept:
SAP System: SAP S/4HANA 2023, SID S4D, ABAP 7.58, SAP HANA, client 100.
SAP Application Instance: Instance number 01, private lab network.
MCP Server: Rocky Linux 9.8 running on Microsoft Hyper-V.
Python Runtime: Python 3.11 virtual environment.
PyRFC: Version 3.4.
SAP NetWeaver RFC SDK: Version 7.50, PL20.
MCP Python SDK: Version 2.3.0.
MCP Transport: Streamable HTTP, listening on 127.0.0.1:8000/mcp.
SAP RFC User: Dedicated technical user (MCP_RFC).
Linux Service Accounts: sapmcp for the HTTP service and mcpadmin for the tunnel service.
This configuration was validated in a dedicated lab environment and should be treated as a proof of concept rather than a production-ready deployment.
4. Preparing the Linux environment
The installation uses /opt/sap-mcp. The commands below are safe verification commands for the actual environment, not a reconstructed history of every dnf or pip operation.
Project structure, omitting backup files, logs, credentials and the virtual environment:
/opt/sap-mcp/
app/
server.py
server_http.py
test_mcp.py
test_mcp_http.py
config/
sap.env # private; never publish contents
packages/
pyrfc-3.4-cp311-cp311-linux_x86_64.whl
venv/
tests/
test_rfc.pyFor a new installation, install the SAP NetWeaver RFC SDK using SAP-authorized distribution and its supported platform instructions. Install a Python version compatible with the chosen PyRFC wheel, and ensure the RFC SDK shared libraries are discoverable by the service process. The original package installation transcript and runtime library-path settings were not preserved in the reviewed documentation; therefore this article does not invent exact commands for those steps.
5. SAP RFC connection and credential handling
A dedicated technical SAP user in client 100 is used for RFC calls. Credentials are loaded from a private environment file outside the source code. Example variable names (values intentionally omitted):
SAP_ASHOST=<sap-application-host>
SAP_SYSNR=01
SAP_CLIENT=100
SAP_USER=<dedicated-rfc-user>
SAP_PASSWORD=<secret>
SAP_LANG=ENsudo stat -c "%U %G %a %n" /opt/sap-mcp/config/sap.env
The working deployment uses restrictive permissions (mode 600). Never paste the actual environment file into a blog, issue tracker, AI prompt or screenshot. Grant only required RFC and application authorizations; RFC-enabled does not automatically mean read-only, released or safe for external use.
6. MCP server design
The application registers Python functions with an MCP server named SAP-S4D-Operations using @McP.tool(). A typical tool validates input, opens a PyRFC connection, calls an SAP function module, converts the result to JSON-compatible data and closes the connection.
In the real application, connection parameters are constructed by a load_config() helper and tools are registered using the MCP decorator. Inspect SAP function signatures in SE37 and, where useful, through PyRFC function metadata. Test function behavior in SAP before exposing it as a tool.
7. HTTP entry point — verified source
This code was copied from the running /opt/sap-mcp/app/server_http.py:
import asyncio
from server import mcpif __name__ == "__main__":
asyncio.run(
mcp.run_streamable_http_async(
host="127.0.0.1",
port=8000,
streamable_http_path="/mcp",
)
)The MCP endpoint is http://127.0.0.1:8000/mcp on the Linux VM. An outbound tunnel connects this local service to the remote client integration. The public endpoint and tunnel credentials are intentionally excluded.
8. systemd services — verified configuration
Two services were confirmed active with systemctl is-active: sap-mcp-http.service and sap-mcp-tunnel.service.
8.1 HTTP service
[Unit]
Description=SAP S4D MCP HTTP Server
After=network-online.target
Wants=network-online.target[Service]
Type=simple
User=sapmcp
Group=sapmcp
WorkingDirectory=/opt/sap-mcp/app
ExecStart=/opt/sap-mcp/venv/bin/python /opt/sap-mcp/app/server_http.py
Restart=on-failure
RestartSec=5
UMask=0077
NoNewPrivileges=true[Install]
WantedBy=multi-user.target8.2 Tunnel service
The following represents the verified service with the local tunnel profile name generalized for publication. A tunnel client must be installed and provisioned separately; its configuration is provider-specific.
[Unit]
Description=Tunnel Client for SAP S4D MCP
Wants=network-online.target
After=network-online.target sap-mcp-http.service
Requires=sap-mcp-http.service[Service]
Type=simple
User=mcpadmin
Group=mcpadmin
WorkingDirectory=/home/mcpadmin
Environment=HOME=/home/mcpadmin
EnvironmentFile=/etc/tunnel-client/runtime.env
ExecStart=/usr/local/bin/tunnel-client run --profile <profile-name>
Restart=on-failure
RestartSec=10
UMask=0077
NoNewPrivileges=trueThe path to runtime.env is shown only as a configuration location. Do not publish its contents. The service naming and tunnel executable are specific to this PoC; adapt them to the tunnel provider used in your environment.
sudo systemctl is-active sap-mcp-http.service sap-mcp-tunnel.service
sudo systemctl status sap-mcp-http.service --no-pager
sudo systemctl status sap-mcp-tunnel.service --no-pager
sudo ss -lntp | grep :8000
sudo journalctl -u sap-mcp-http.service -n 80 --no-pager9. The six implemented SAP operations tools
| MCP tool | SAP capability / implementation |
| sap_system_info | RFC_SYSTEM_INFO: system metadata |
| sap_background_jobs | BAPI_XMI_LOGON + BAPI_XBP_JOB_SELECT: background jobs |
| sap_st22_dumps | Z_MCP_ST22_READ: ST22 dumps via internal SAP FM |
| sap_logged_on_users | Active SAP user sessions; exact SAP FM omitted pending source verification |
| sap_work_processes | TH_WPINFO: work process overview (SM50) |
| sap_workload_statistics | SWNC_COLLECTOR_GET_AGGREGATES: ST03N daily workload |
All six tools have been exercised in the PoC. This table describes operational monitoring, not a generic authorization to execute arbitrary commands or modify SAP data.
10. ST22: a custom RFC-enabled ABAP wrapper
The standard RS_ST22_GET_DUMPS function was not callable directly over RFC in this environment. A custom Remote-Enabled Function Module Z_MCP_ST22_READ was therefore created in function group ZMCP_MONITOR. The PoC used local package $TMP, which is not transportable.
The confirmed ABAP implementation is reproduced below; the FM interface includes IV_DATE, EV_COUNT and ET_DUMPS with types defined in the SAP system:
FUNCTION Z_MCP_ST22_READ.
DATA: lv_date TYPE sy-datum,
lt_dumps TYPE rsdumptab.
CLEAR ev_count.
REFRESH et_dumps.
lv_date = iv_date.
IF lv_date IS INITIAL.
lv_date = sy-datum.
ENDIF.
CALL FUNCTION 'RS_ST22_GET_DUMPS'
EXPORTING p_day = lv_date
IMPORTING p_infotab = lt_dumps
EXCEPTIONS no_authority = 1 OTHERS = 2.
IF sy-subrc <> 0.
RETURN.
ENDIF.
LOOP AT lt_dumps INTO DATA(ls_dump).
APPEND ls_dump TO et_dumps.
ENDLOOP.
ev_count = lines( et_dumps ).
ENDFUNCTION.Important limitation: this PoC code returns zero results for both an empty dump list and some failures, including authorization errors. A production wrapper must explicitly propagate errors, validate input, apply authorization checks and avoid returning sensitive dump content unnecessarily.
11. ST03N workload statistics: implementation and validation
The newest tool, sap_workload_statistics(date, top_n=10), reads daily workload aggregates through SWNC_COLLECTOR_GET_AGGREGATES. The tested parameters were COMPONENT=TOTAL, ASSIGNDSYS=S4D, PERIODTYPE=D, PERIODSTRT=<YYYYMMDD>, SUMMARY_ONLY blank, STORAGE_TYPE=A and FACTOR=1000.
The USERTCODE aggregate (DDIC structure SWNCAGGUSERTCODE) is grouped by ACCOUNT. The Python tool sums COUNT, RESPTI, CPUTI, PROCTI and QUEUETI, and converts duration units for the returned report. It validates date format and limits top_n to 1–50.
| Validation: 12 October 2026 | Observed result |
| Test account | DDIC |
| Dialog steps | 8,877 |
| Total response time | 2,710.256 seconds |
| Average response time | 305.31 ms |
| Total CPU time | 743.270 seconds |
| SAP FM records read | 142 |
The figures were cross-checked against the SAP GUI ST03N display for the same date and account. Subsequent live MCP tests returned 46,189 total steps for 12 October and 46,429 for 13 October. These are daily totals; the current tool does not establish the busiest hour.
12. Testing end to end
Validate Python syntax, restart the HTTP service after code changes, and run the MCP HTTP test script:
sudo -u sapmcp -H /opt/sap-mcp/venv/bin/python -m py_compile /opt/sap-mcp/app/server.py
sudo systemctl restart sap-mcp-http.service
sudo systemctl status sap-mcp-http.service --no-pager
sudo -u sapmcp -H /opt/sap-mcp/venv/bin/python /opt/sap-mcp/app/test_mcp_http.pyA previously confirmed HTTP test returned the MCP tool list and RFC system information (S4D, ABAP 758, HDB, client 100). After registering new tools, refresh the tool list in the ChatGPT MCP plugin configuration; otherwise the client may continue showing a cached list.
Suggested test prompts: “Show ST22 dumps for 2026-10-13”; “List background jobs for today”; “Show current work processes”; “Summarize ST03N workload for 2026-10-12, top 5 users.” Results depend on RFC authorizations and available SAP data.
13. Troubleshooting lessons
Non-RFC-enabled SAP functions: a direct remote call may produce CALL_FUNCTION_NOT_REMOTE. Verify the FM attributes in SE37; where justified, create a narrow, audited RFC wrapper rather than assuming an internal FM is remotely callable.
Tool visibility: a successful server restart does not necessarily update the ChatGPT plugin tool catalog. Refresh tools and rerun the listing test.
Python decorator behavior: in this implementation, a registered tool function can be called directly for a local test; do not assume it has an .fn property.
ST03N aggregation: match the aggregation period, component and SAP GUI filters before comparing results. A daily aggregate cannot answer a peak-hour question.
14. Security and production readiness
This is a functional PoC, not a production-certified integration. Before deployment to clients, implement authenticated access to the MCP endpoint (for example OAuth/OIDC where supported), per-user and per-system authorization, least-privilege SAP technical users, controlled tool allowlists, auditing, rate limits, secret rotation, network segmentation and response redaction.
For potentially destructive operations such as restart, backup, user administration or job cancellation, introduce explicit approval gates, scoped permissions, precondition checks and change logs. Never expose arbitrary RFC or operating-system command execution merely because an AI client can call tools.
Review SAP support and release status for each function module. Internal SAP FMs may change across releases and are not equivalent to stable public APIs.
15. Next steps
Planned extensions include RFC metadata discovery, SM12 locks, SM21 system logs, ST02/ST06 performance monitoring, hourly ST03N time profiles, and a multi-system gateway with strict system-level isolation. A separate SAP BTP/OData-based MCP integration is also being considered; it has not been implemented as part of this RFC PoC.
16. Conclusion
MCP provides a practical interface between conversational AI and SAP BASIS operations. In this PoC, Python and PyRFC translate six well-defined monitoring tasks into SAP RFC calls, while Streamable HTTP and an outbound tunnel connect the Linux gateway to ChatGPT. The key engineering lesson is to validate SAP APIs, restrict privileges and verify results against SAP GUI before trusting AI-generated operational summaries.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.