sap-abap-mcp
MCP serverAI & modelsDevelop, test, analyze, and operate SAP ABAP systems through ADT from AI coding agents.
Unavailable. This server has no hosted endpoint yet, so ahel can't serve it.
Add to setup to save this item as a reference. ahel cannot run it, and signing in will not install it.
Getting started
- Save this item in Your setup as a reference.
- Read the source or reference documentation for its setup requirements. Saving it here does not connect it to your AI.
- Check this page for availability before trying to install it through ahel.
From the project's README
As published by coaspe/sap-abap-mcp in README.md.
The headless, client-neutral, governance-first MCP server for SAP ABAP development across multiple systems.
SAP ABAP MCP lets Codex, Claude, and other local MCP hosts work with SAP ABAP through ABAP Development Tools (ADT) HTTP services. It can inspect and edit source, run quality checks, manage transports, use abapGit and the RAP generator, inspect runtime data, compare systems, and perform guarded refactorings without an IDE runtime, SAP GUI, or an ABAP FS virtual workspace.
Why this server
SAP now provides an official ADT MCP Server inside its ADT clients. This project serves a different operating model: headless automation from any supported local MCP host.
| SAP ABAP MCP | SAP ADT MCP Server | |
|---|---|---|
| Runtime | Independent Node.js process: local stdio, or self-hosted Streamable HTTP for a shared instance | Local HTTP server hosted by an ADT client |
| Agent hosts | Codex, Claude, and other MCP clients, locally or over HTTP | MCP hosts configured against the running ADT server |
| SAP sessions | Multiple named profiles in one process | SAP projects and sessions managed by ADT |
| Guardrails | Production profiles are read-only; writes support package restrictions and explicit confirmations; HTTP mode adds API key roles, rate limits, and a structured audit log | Governed by the installed ADT version, SAP authorizations, and client configuration |
| Assurance | Read-only transport assessment with JSON, SARIF, and JUnit evidence | SAP-provided in-IDE development workflows |
| Verification | Separates implemented, discovered, authorized, and live-verified capabilities | SAP product support and release documentation |
This is a deployment-model comparison, not a capability benchmark or a claim of SAP endorsement. Official behavior varies by ADT and SAP backend release.
90-second workflow
The animation contains synthetic object and transport names and no live SAP data. See the accessible transcript and exact workflow.
Quick start
Detailed references: profiles and authentication, HTTP deployment, and CLI commands.
You need Node.js 20 or later, network or VPN access to SAP, and an SAP HTTPS URL, three-digit client number, username, and ADT Basic Auth permission.
Recommended: guided onboarding
Run one command and follow the local browser wizard. It checks npm, Claude Code,
Codex, existing .claude and .codex settings, and saved SAP profiles. It then
verifies the SAP login before saving it and registers the MCP server through the
installed client's official CLI. Existing steps are detected and skipped.
Windows:
npx.cmd -y @coaspe/sap-abap-mcp@latest onboard
macOS:
npx -y @coaspe/sap-abap-mcp@latest onboard
The wizard runs only on 127.0.0.1; SAP credentials do not pass through a
publisher-operated service. Passwords are protected with Windows DPAPI or macOS
Keychain. Linux users should use the manual setup because the browser wizard
does not store Linux credentials.
Manual setup
1. Configure SAP
Windows:
npx.cmd @coaspe/sap-abap-mcp@latest setup
macOS or Linux:
npx @coaspe/sap-abap-mcp@latest setup
The wizard calls the local connection alias Server name and the endpoint SAP URL. Windows and macOS validate SAP before saving and protect the password with DPAPI or Keychain. Linux saves only non-secret settings and prints the password environment-variable commands to run before starting the MCP client.
2. Register the MCP server
After setup, run only the command for your client. On Windows, use npx.cmd.
Codex CLI:
codex mcp add sap-abap -- npx.cmd -y @coaspe/sap-abap-mcp@latest serve
Claude Code:
claude mcp add --transport stdio --scope user sap-abap -- npx.cmd -y @coaspe/sap-abap-mcp@latest serve
On macOS or Linux, use npx.
Codex CLI:
codex mcp add sap-abap -- npx -y @coaspe/sap-abap-mcp@latest serve
Claude Code:
claude mcp add --transport stdio --scope user sap-abap -- npx -y @coaspe/sap-abap-mcp@latest serve
This registration exposes all saved SAP profiles; every SAP-facing tool still requires an explicit connectionId. Restart the client, then use codex mcp list, claude mcp get sap-abap, or /mcp to confirm that the process starts. The completed wizard already performs live SAP verification; /mcp alone does not prove that SAP authentication succeeded.
Prefer a plugin install? Follow Claude Code and Codex plugin marketplaces; the included setup skill guides the same local wizard without putting the SAP password in chat. See the detailed Windows, macOS, and Linux sections for platform-specific behavior and server management.
Community and adoption
- Read the public roadmap.
- Run or implement the open SAP ABAP MCP compatibility profile.
- Add an opt-in, sanitized entry to ADOPTERS.md.
- Use GitHub Discussions for implementation questions, compatibility evidence, and RFCs.
Need a transport-specific release decision and CI evidence from existing ATC and ABAP Unit checks? Review the fixed-scope paid diagnostic and three-day pilot. If your current workflow already preserves the check results, release decision, and evidence together, the service is not a fit. Never include SAP credentials, source code, hosts, transport numbers, logs, tokens, or other confidential information in a public issue or discussion.
Current v1 surface
The v1 catalog contains 120 action-specific tools and seven Resources.
Unreleased local CLI builds default to the minimal preset: five discovery/invocation tools. Other capabilities are loaded on demand.
Use --toolsets all to advertise the complete catalog directly. Use --api-version v0 only for legacy
client compatibility, or select toolsets explicitly when a host should
advertise fewer schemas.
Normal clients should omit both --api-version and --toolsets.
| Invocation | Advertised surface |
|---|---|
serve --profile DEV100 | Minimal v1: 5 gateways, all 120 capabilities reachable, seven Resources |
serve --profile DEV100 --toolsets all | Full direct v1: 120 tools and seven Resources |
serve --profile DEV100 --preset compact | Token-efficient v1, 12 everyday read/inspect tools |
serve --profile DEV100 --toolsets core,analysis | Selected v1 toolsets only |
serve --profile DEV100 --api-version v0 | Legacy 53-tool compatibility surface |
See the v1 migration guide for contracts, Resources, and the separate live-SAP verification boundary.
Built-in workflow prompts (unreleased)
MCP hosts supporting prompts/list and prompts/get can select these workflows:
| Prompt | Outcome |
|---|---|
sap-explain-object | Explain current source and callers with source-line evidence |
sap-change-object | Guide a scoped edit through diagnostics, activation, ABAP Unit and ATC |
sap-review-transport | Assess readiness and incomplete evidence without releasing a transport |
sap-plan-rap | Discover backend schema, validate inputs and preview RAP generation |
Each prompt accepts systemId, target, and optional goal in your preferred
language. Prompts appear only when their required tools are enabled; viewer
sessions never expose the source-change workflow. The legacy v0 API is unchanged.
Fetching a prompt performs no SAP calls. These are agent instructions, not an
automatic transaction or an additional authorization grant.
For local usage and verification, see workflow prompts. The September 2026 competitive assessment separates implemented improvements from remaining live-SAP and release gaps.
Live SAP evidence
Capabilities are reported as unverified until they succeed against a live
connection. docs/live-sap-evidence.md records the
current sanitized results — no credentials, no customer source, no host names.
| Area | ECC 758 | S/4HANA 758 |
|---|---|---|
$TMP-scoped v1 surface | 87 passed, 11 unsupported, 0 failed | 93 passed, 2 unsupported, 0 failed |
| Self-hosted HTTP mode, roles, and audit | 13 of 13 passed | not run |
| CI assurance gate and its artifacts | 7 of 7 passed | not run |
200 live checks in total: 180 tool-surface checks across two systems, plus 20 transport and CI checks on one. The tool-surface count counts each capability once per system, because release coverage is the claim; it is not 180 distinct capabilities.
On S/4HANA this includes the complete class-runner and debugger chain: a $TMP
class runner executed, a breakpoint on its own source suspended it, and the
attached debugger returned a 13-frame stack, variables, an evaluated expression,
and a completed step. On ECC the ADT class-run endpoint rejects the same class, so
the attached debugger is unreachable there; that difference accounts for the nine
extra unsupported results and is documented with its exact SAP message.
Reproduce the tool-surface run against your own development system:
npm run evidence:live -- DEV100
The harness creates exactly one class in the local package $TMP under a
run-unique name, treats it as owned only after a create receipt and an immediate
exact read-back agree, refuses in code to mutate anything else, and deletes it
again. Existing objects are only ever read. The two unsupported results are
missing SAP-side prerequisites — the ABAP REPL and the abapGit ADT backend — not
defects.
ABAP FS parity status
The pinned ABAP FS 2.6.5 source exposes 43 MCP tools. This server provides a strict-compatible subset of 42; the omitted tool is manage_subagents, which depends on the VS Code agent host. With 10 headless feature extensions and read_deferred_result, this server advertises 53 tools in total.
The development surface supports create-time source for BDEFs, classes, interfaces, programs/includes, CDS/DCL/metadata extensions, and service definitions, plus structured DDIC reads/writes, one-request batch activation, class and executable-program profiling, the ABAP FS REPL contract, detailed semantic and enhancement inspection, paged repository-child discovery, bounded runtime feeds, and an opt-in classic-object bridge. SAP-dependent capabilities remain unverified until they succeed against the selected live connection; call get_sap_capabilities for per-connection evidence.
Snippet execution requires ZCL_ABAP_REPL and an active SICF service at /sap/bc/z_abap_repl. Executable programs use the ADT program-run endpoint through a confirmed one-use plan and request only a bounded server-time profile.
What it supports
The server provides all 42 strict-compatible headless tools from the pinned ABAP FS baseline, ten grouped feature extensions, and one infrastructure tool for continuing oversized results.
| Area | Capabilities |
|---|---|
| Connections | Multiple SAP profiles, Basic Auth, OAuth client credentials, browser OAuth Authorization Code with PKCE, request-scoped bearer passthrough, lazy login, system metadata, ADT discovery export |
| Repository reads | Search, metadata, structured DDIC properties, paged package/program/function-group children, source ranges, batch reads, URI reads, source search, enhancement implementations and elements |
| Semantic services | Completion details, definition lookup, documentation, type hierarchy, components, quick-fix discovery, SAP formatter preview |
| Source writes | Exact source replacement, typed DDIC updates, create-time source for textual ADT object types, syntax diagnostics, single- and one-request batch activation, text elements |
| Refactoring | Rename, package move, extract method, quick-fix application, formatting, deletion |
| Quality | ABAP Unit, ATC, diagnostics, test-include creation |
| Transports | List, details, objects, read-only release assessment, JSON/SARIF/JUnit evidence, compare, create, release, delete, owner/user management, object resolution |
| Versions | Active revision history, revision comparison, inactive source, guarded revision restore |
| abapGit | Repository list, remote information, create, pull, unlink, stage, push, check, branch switch (requires the abapGit ADT backend on the SAP system) |
| RAP | Availability, paged schema, defaults, validation, preview, generation, service binding details, and OData V2/V4 publication and unpublication |
| Runtime | Guarded class/program execution with bounded aggregate profiling, fixed-contract ABAP REPL execution, debugger, breakpoints, stack, variables, dumps, traces, Gateway/system feeds, heartbeat checks |
| Cross-system | Source comparison across configured SAP systems |
| Dependency analysis | Bounded where-used dependency graph |
| SAP GUI integration | Validated WebGUI transaction URL generation and optional local launch |
| Classic objects | Opt-in, same-origin Screen/Dynpro and full GUI Status bridge with confirmed writes |
| Data | Read-only ADT SQL queries with bounded or file-based output |
| Artifacts | Mermaid validation/viewer and DOCX test documentation |
The ten grouped extension tools are:
inspect_abap_coderefactor_abap_codemanage_abapgitmanage_rap_generatormanage_abap_versionscompare_abap_systemsget_abap_dependency_graphrun_sap_transactionget_sap_capabilitiesrun_abap_application
Grouping related actions keeps the tool-schema footprint lower than exposing every operation as a separate MCP tool.
read_deferred_result is the additional infrastructure tool; it reads the remaining UTF-8 chunks of a large result without repeating the SAP operation.
See advanced ABAP workflows for enhancement, behavior implementation, CDS Unit, local test include, and program profiling recipes. See the classic-object bridge guide before enabling Screen/Dynpro or GUI Status access.
Transport change assurance
manage_transport_requests keeps transport review inside the existing grouped tool. Its read-only assess_transport action can run ATC and ABAP Unit for each supported transport object, optionally compare the same objects with a target connection, and emit JSON, SARIF 2.1.0, and JUnit XML reports.
The returned gate is passed, failed, or incomplete. Truncated object coverage, truncated ATC findings, failed check execution, empty transports, and classes without discoverable tests prevent a pass. A target-system difference is recorded as landscape evidence rather than automatically treated as a failure. Assessment never releases the transport; release_transport remains a separate confirmed mutation.
The plugin includes sap-abap-change-assurance for this workflow. In Claude Code run /sap-abap-mcp:sap-abap-change-assurance; in Codex ask to use $sap-abap-change-assurance.
Gate a pipeline without an MCP host
Change assurance does not require an AI agent. The assure command runs the same
read-only assessment directly and turns the gate into an exit code:
npx @coaspe/sap-abap-mcp@latest assure DEV100 --transport DEVK900123 \
--checks atc,unit_tests --formats json,sarif,junit \
--report-directory ./reports
| Exit code | Gate | Meaning |
|---|---|---|
| 0 | passed | Every assessed object passed every requested check |
| 1 | failed | A check produced a definite failure |
| 2 | incomplete | Safety could not be proven — truncated coverage, a check that could not run, an empty transport, or a class with no discoverable tests |
incomplete blocks by default. Pass --fail-on failed when only definite
failures should stop a build. assure never releases or modifies the transport.
GitHub Action
action.yml wraps the same command and uploads SARIF to GitHub code
scanning, so ABAP findings appear next to the rest of a repository's security
results:
- uses: Coaspe/sap-abap-mcp@v1
id: assurance
with:
sap-url: ${{ secrets.SAP_URL }}
sap-client: "100"
sap-username: ${{ secrets.SAP_USERNAME }}
sap-password: ${{ secrets.SAP_PASSWORD }}
transport: ${{ inputs.transport }}
checks: atc,unit_tests
- uses: github/codeql-action/upload-sarif@v3
if: always()
with:
sarif_file: ${{ steps.assurance.outputs.report-sarif }}
The action outputs gate, report-json, report-sarif, and report-junit, and
writes a job summary. The SAP password is passed only through a
profile-specific environment variable, never as a command argument, so it does
not appear in a process list or a command echo. The runner needs network or VPN
access to SAP.
MCP directories and registries
The canonical registry identity is io.github.Coaspe/sap-abap-mcp, defined in server.json. Directory installs must run this package as a local stdio server; SAP profiles and credentials stay on the user's machine and are never hosted by a registry.
Before the first SAP-facing request, create and verify at least one local SAP profile using the commands in Quick start or llms-install.md. The Claude plugin may start successfully without a profile; after installation, run /sap-abap-mcp:sap-abap-setup to complete local SAP setup. A generic registry launch runs @coaspe/sap-abap-mcp with the serve argument and exposes all locally configured profiles; every SAP-facing tool still requires an explicit connectionId.
Registry publication does not change the live-evidence boundary. SAP-dependent development-parity capabilities remain unverified until they succeed against the selected live connection.
The public Smithery listing installs the validated local MCPB bundle. Its current catalog contains 120 tools and seven Resources and is synchronized from the runtime before publication.
The public LobeHub listing
uses the owner-validated lhm.plugin.json manifest. The
current listing advertises the same default 120 tools and seven Resources.
Privacy Policy
SAP ABAP MCP runs locally and does not send SAP profiles, credentials, source code, or tool results to a publisher-operated service. It communicates only with destinations selected by the user, including the configured SAP system and the user's MCP host. See the complete PRIVACY.md and TERMS.md.
Claude Code and Codex plugin marketplaces
This repository is also a dual-compatible plugin marketplace. The plugin starts the same npm latest package as a local stdio process, so SAP profiles, credentials, and ADT traffic stay on the user's computer. Profiles are user-scoped outside the plugin cache and survive plugin updates.
Claude Code:
/plugin marketplace add Coaspe/sap-abap-mcp
/plugin install sap-abap-mcp@coaspe-sap
/reload-plugins
Run the namespaced setup skill after reloading:
/sap-abap-mcp:sap-abap-setup
The skill reuses an existing profile or guides profile creation, local password entry, and live ADT verification. Use /mcp to confirm that the sap-abap process is connected, but do not treat that status as proof that an SAP profile is authenticated; the setup skill verifies SAP with doctor.
Codex:
codex plugin marketplace add Coaspe/sap-abap-mcp
Then install SAP ABAP MCP from the Coaspe SAP Developer Tools marketplace in the Codex app and start a new task. Ask Codex to set up SAP ABAP MCP; the included sap-abap-setup skill keeps passwords out of chat and guides profile creation, authentication, and live ADT verification.
The plugin also includes sap-abap-change-assurance, which assesses an existing transport without releasing it and returns CI-native evidence paths.
OAuth client credentials
The interactive setup wizard remains the Basic Auth path. OAuth client credentials are an explicit advanced profile type and do not change the defaults for newly created profiles. Create and verify one on Windows or macOS with:
npx @coaspe/sap-abap-mcp@latest profile add BTP100 \
--url https://abap.example.com --client 100 \
--auth-type oauth-client-credentials \
--token-url https://auth.example.com/oauth/token \
--client-id mcp-client --scope "abap.read abap.write" --login
The hidden prompt requests the OAuth client secret. The profile file stores the token URL, client ID, and optional scope, but never the client secret or access token. The token endpoint must use HTTPS and must not contain embedded credentials, query parameters, or a fragment. The client uses HTTP Basic client authentication, requires a Bearer token with a positive expires_in, and recreates the ADT client before the cached token expires because abap-adt-api 8.4.1 memoizes a bearer fetch.
For automation, pipe the client secret and add --password-stdin. On Linux, create the profile without --login, place the client secret in the printed profile-specific SAP_ABAP_MCP_PASSWORD_<PROFILE> environment variable, and start the MCP process from that environment. The variable name is retained for backward compatibility even when its value is an OAuth client secret.
Browser OAuth Authorization Code profiles are also available for identity providers that support a loopback redirect URI and S256 PKCE:
npx @coaspe/sap-abap-mcp@latest profile add DEV100 \
--url https://sap.example.com --client 100 \
--auth-type oauth-authorization-code \
--authorization-url https://login.example.com/oauth2/authorize \
--token-url https://login.example.com/oauth2/token \
--client-id mcp-public-client --scope "openid abap" --login
The command opens the system browser, listens only on a random loopback port,
validates OAuth state, exchanges the code with PKCE, and stores the resulting
credential in Keychain or DPAPI. Refresh-token rotation is persisted. Browser
OAuth login is therefore available on macOS and Windows; Linux's environment-
only secret store cannot safely persist or rotate this credential.
Client certificates, Kerberos, and user/password OAuth grants remain
unsupported. OAuth behavior is still live-unverified for a particular SAP
system until doctor succeeds there.
SAP BTP ABAP environment service keys
A service key downloaded from an ABAP environment service instance already contains the endpoint, client id, and client secret, so it can be imported directly:
npx @coaspe/sap-abap-mcp@latest profile add BTP100 --service-key ./service-key.json
Shortened here. Read the whole README on GitHub.
Signals
- GitHub stars
- 5
- Last commit
- Sep 2026
- Weekly_downloads
- 359 weekly_downloads
Advanced
- Delivery
- sap-abap-mcp MCP server → your ahel connector (mcp.ahel.ai) → your AI.
- Item type
- mcp-server
- Key
io-github-coaspe-sap-abap-mcp- Source
- github.com/coaspe/sap-abap-mcp
github.com/coaspe/sap-abap-mcp