Ciltress/sap-abap-mcp

AnMCPserver that gives an AI agent full read/write access to an SAP ABAP system throughADT(ABAP Development Tools), authenticated withSPNEGO/Kerberos single sign-on, anX.509 client certificateor anOAuth 2.0 bearer token— no password anywhere in the configuration. User and password is still available as fallback but not recommended!

It wrapsabap-adt-apiand adds one thing ADT itself cannot do:calling RFC-enabled function modules, over the SAP Gateway JSON-RPC 2.0 service.

This is the SSO fork ofmcp-abap-abap-adt-apiby mario-andreschak. The main differences: Kerberos SSO instead of Basic Auth, the JSON-RPC/RFC tools, a router derived from the tool definitions, and a documented tool reference.

- Two password-less logon modes— SPNEGO/Kerberos with the logged-on Windows user's ticket, or an X.509 client certificate for a service or technical user that has no Kerberos identity. No SAP password is stored or sent either way, and both self-heal when the session expires.
- Read any object by name—readAbapObjectresolves a name to its source in one call; no ADT URL to discover or hand-craft.
- Describe a table—describeAbapTablereturns fields, DDIC types, key flags and check tables.
- Object management— search, read, create, modify, delete and activate ABAP objects.
- Survey a naming convention—searchPackagesfinds packages by pattern (["ZPP_","Z_PP"]) and expands each into its objects grouped by type, in one call.
- Source workflow— lock → edit → syntax check → activate → unlock, with transport handling.
- Code intelligence— completion, definitions, usage references, ABAP Doc, pretty printer, ATC, ABAP Unit, refactoring (rename, extract method).
- Call RFC function modules—callFunctionViaJsonRpcexecutes an RFC-enabled function module and validates the request against its real signature, read from the system.
- Batch RFC calls in one LUW—callFunctionsViaJsonRpcsends several function modules in a single request, which is what lets an update BAPI and itsBAPI_TRANSACTION_COMMITshare one LUW.
- Data access—tableContentsand ad-hocrunQuerySELECTs.
- See the running system—listLoggedOnUsersanswers "who is logged on" fromTH_USER_LIST, the data behindSM04;readProfileParametersreads RZ11 values in one round trip; andcheckLogonConfigurationsays which authentication the system actually accepts.
- Bundled agent skills— 54 skills underskills/, for ABAP (Clean ABAP, RAP, CDS, ATC, abapGit…) and general engineering (TDD, code review, diagnosing bugs), served as resources and viareadSkill.
- Self-documenting— the guides below are served by the server itself, as MCP resources (abap-adt://guides/…) and through thereadServerGuidetool, so an agent can look up a workflow or an argument mid-task without leaving the session.

- An X.509 client certificate— for a service or technical user that has no Kerberos identity. Needs neither curl nor Windows. SAP has to be set up for it: the ICM port must request a certificate (VCLIENTinicm/server_port_<n>, which overridesicm/HTTPS/verify_client), the issuing CA trusted inSTRUST, and aCERTRULEmapping to the user. Full setup — including how to check those from this server — indocs/Authentication.md.
- An OAuth 2.0 client— for an SAP BTP ABAP environment, where there is no Kerberos realm and no ICM to configure, or for an on-premise system that publishes ADT throughSOAUTH2. A BTP service key is already one of these. See§11.

git clone --recurse-submodules https://github.com/Ciltress/sap-abap-mcp.git cd sap-abap-mcp npm install npm run build

Copy.env.exampleto.envand fill in your system:

SAP_URL=https://your-sap-server.example.com:44301 SAP_USER=YOUR_SAP_USER SAP_CLIENT=100 SAP_LANGUAGE=EN

SAP_USER=CLAUDEAGENT # the user CERTRULE maps the certificate to SAP_CERT_FILE=C:\Users\svc_agent\SNC\sec\claudeagent.p12 SAP_CERT_PASSPHRASE=<PKCS#12 password / PSE PIN>

SAP_OAUTH_TOKEN_URL=https://your-tenant.authentication.eu10.hana.ondemand.com/oauth/token SAP_OAUTH_CLIENT_ID=sb-abap-agent!t1234 # 'clientid' in a BTP service key SAP_OAUTH_CLIENT_SECRET=<'clientsecret'>

SAP_USER=CLAUDEAGENT SAP_PASSWORD=<the password>

The last resort, and not interchangeable with the other two.A missing ticket or an unmapped certificate is simply refused; awrong passwordcounts againstlogin/fails_to_user_lockand locks that user for every consumer of it, not just this server. The implementation refuses to retry a rejected password for that reason — one failed logon, latched, however many tools are called. Prefer a certificate for anything unattended.docs/Authentication.md§10has the detail.

{ "mcpServers": { "sap-abap-dev-100": { "command": "node", "args": ["C:/path/to/sap-abap-mcp/dist/index.js"], "env": { "SAP_URL": "https://your-sap-server.example.com:44301", "SAP_USER": "YOUR_SAP_USER", "SAP_SYSTEM_ID": "DEV", "SAP_CLIENT": "100", "SAP_LANGUAGE": "EN" } } } }

"env": { "…": "…", "ABAP_MCP_PROFILE": "core" }

{ "mcpServers": { "sap-abap-dev-100": { "command": "docker", "args": ["run", "-i", "--rm", "--env-file", "C:/path/to/.env", "abap-adt-mcp"] } } }

All four logon modes work in here, but a credential is something the container has to begiven, and--env-fileis not dotenv — Docker strips no quotes, reads noexport, and drops no trailing# comment, so a value dotenv would have cleaned up arrives verbatim. Windows paths in.envhave to be replaced by the mounted ones. Kerberos is the mode that needs the most from the container and OAuth the least: a token is fetched over the network, so nothing has to be mounted at all.

Certificate mode— mount the key material read-only, and the CA that signsSAP'scertificate with it:

docker run -i --rm --env-file .env \ -v /host/certs:/certs:ro \ -e SAP_CERT_FILE=/certs/agent.p12 \ -e SAP_CA_FILE=/certs/corporate-root.pem \ abap-adt-mcp

docker run -i --rm --env-file .env \ -v /etc/krb5.conf:/etc/krb5.conf:ro \ -v /host/agent.keytab:/krb5/agent.keytab:ro \ -e SAP_KRB_KEYTAB=/krb5/agent.keytab \ -e SAP_KRB_PRINCIPAL=SVC_AGENT@CORP.EXAMPLE.COM \ abap-adt-mcp

docker run -i --rm --env-file .env \ -e SAP_OAUTH_TOKEN_URL=https://your-tenant.authentication.eu10.hana.ondemand.com/oauth/token \ -e SAP_OAUTH_CLIENT_ID='sb-abap-agent!t1234' \ -e SAP_OAUTH_CLIENT_SECRET=<clientsecret> \ abap-adt-mcp

docker run -i --rm --env-file .env \ -e SAP_USER=YourUser \ -e SAP_PASSWORD=YourPassword \ abap-adt-mcp

docker run --rm --env-file .env -v /host/agent.keytab:/krb5/agent.keytab:ro \ -e SAP_KRB_KEYTAB=/krb5/agent.keytab abap-adt-mcp klist

"sap-abap-dev-100": { "env": { "SAP_SYSTEM_ID": "DEV", "SAP_CLIENT": "100", "…": "…" } }, "sap-abap-dev-200": { "env": { "SAP_SYSTEM_ID": "DEV", "SAP_CLIENT": "200", "…": "…" } }, "sap-abap-q01-100": { "env": { "SAP_SYSTEM_ID": "Q01", "SAP_CLIENT": "100", "…": "…" } }

{"tool":"readAbapObject","args":{"objectName":"ZCL_MY_CLASS"}} {"tool":"describeAbapTable","args":{"tableName":"T000"}}

{"tool":"searchPackages","args":{"patterns":["ZPP_","Z_PP"]}} // -> each package with its objects grouped by type, sub-packages, and a \truncated\ flag

Call a function module — the signature is read first and the request validated against it:

{"tool":"readAbapFunctionModule","args":{"functionModuleName":"STFC_CONNECTION"}} {"tool":"callFunctionViaJsonRpc","args":{"functionModuleName":"STFC_CONNECTION", "inputParameters":{"REQUTEXT":"hello"}}}

A BAPI and its commit must travel inonebatch, or the commit lands in its own LUW and the BAPI's changes are lost:

{"tool":"callFunctionsViaJsonRpc","args":{"calls":[ {"functionModuleName":"BAPI_USER_LOCK","inputParameters":{"USERNAME":"DEVUSER"}}, {"functionModuleName":"BAPI_TRANSACTION_COMMIT","inputParameters":{"WAIT":"X"}} ]}}

The full write cycle (lock → modify → check → activate → unlock), the debugger, ATC and every other workflow are indocs/MCP-Tools.md§4.

{"tool":"readAbapObject", "args":{"objectName":"ZCL_MY_CLASS"}} {"tool":"describeAbapTable","args":{"tableName":"T000"}} {"tool":"searchPackages", "args":{"patterns":["ZPP_","Z_PP"]}}

readAbapObjectreturns the metadataandthe source in one call. When a name belongs to several objects —ZPP_EXT_LABEL_DATAis both a function group and a function module — it picks the more specific one and tells you, viaambiguous:trueandalternatives; passobjectTypeto force the choice. Objects with no source come back withhasSource:falseand a pointer to the right tool.

describeAbapTablegives field names, DDIC types, lengths, key flags, data elements, domains andcheck tables— the check table is the foreign-key target, which is the quickest way to see how two tables join.objectStructurereturns no fields for a table, andtableContentsreturns rows rather than a definition, so neither answers "what does this table look like".

Rules worth putting in your client's system prompt

- Prefer the by-name tools.Only fall back tosearchObject→objectStructure→getObjectSourcewhen you need the intermediate results. Never hand-craft a/sap/bc/adt/...path.
- Select efficiently.SAP tables are large. Always constrainSELECTs with aWHEREclause, and useSELECT SINGLE(all key fields known) orUP TO n ROWSotherwise.

SELECT vgbel FROM vbrp WHERE vbeln = @lv_vbeln INTO @DATA(lv_vgbel) UP TO 1 ROWS. EXIT. ENDSELECT.

SAP is decoupled from your file system: reading source returns it as a tool result only, and writing a local file changes nothing in SAP. Local copies are useful for diffing, nothing more.

Earlier READMEs listedGetTable,GetStructureandGetTypeInfo. Those belong to the separatemcp-abap-adtproject, not to this server.

npm run build # tsc -> dist/ npm test # jest: parser, tool catalogue, JSON-RPC handler (no SAP system needed) npx tsc --noEmit # type check only

Tests live insrc/__tests__and run entirely offline — the JSON-RPC suite exercises the handler end to end against a fake SAP Gateway node.

Against arealsystem (needs a Kerberos ticket), the end-to-end check is: