MCP Abap Adt Compact Http

mcp-abap-adt: Your Gateway to ABAP Development Tools (ADT)

mcp-abap-adt is an MCP server for ABAP ADT in SAP ECC/S/4HANA (on-premise) and SAP BTP ABAP Cloud systems. It gives agents controlled access to real ABAP repositories through ADT, so analysis and changes are grounded in system data instead of assumptions. It is built for AI-assisted pair programming (AIPNV: AI Pairing, Not Vibing), not autopilot vibe coding.

Primary workflows:

• Deep ABAP analysis: where-used, object metadata, repository navigation, object structure, semantic analysis, dependency and impact exploration.
• High-level ABAP development: rapid CRUD and iterative updates for RAP and classic ABAP artifacts (classes, interfaces, function groups/modules, programs, DDIC, CDS/view/service artifacts), validated through ADT flows.

Why teams use it:

• Full CRUD (not read-only): create, read, update, and delete ABAP artifacts
• Works with On-Premise (ECC/S/4HANA) and ABAP Cloud (BTP) systems
• Legacy systems (BASIS < 7.50) are not supported at present: that support is parked on the parked/legacy-support branch until it can be tried against a live legacy system
• Three authentications over stdio: basic (HTTP or RFC), SNC (passwordless, RFC), JWT with browser login (service key, ABAP or XSUAA); a JWT you already hold goes in the x-sap-jwt-token header of mcp-abap-adt-http / mcp-abap-adt-sse
• Multiple transports: stdio, HTTP, SSE
• Several installation variants: the full server (@mcp-abap-adt/core) or the compact one (@mcp-abap-adt/compact), each connecting to the system over HTTP, RFC or SNC — see Installation variants
• Rich tool surface for ABAP objects, metadata, transports, and search

Authorization & Destinations (Important): A *destination* is the filename of a service key stored locally. You place service keys in the service-keys directory, and use --mcp= to select which one to use. This is the primary auth model for on‑prem and BTP systems. See Authentication & Destinations.

You can configure MCP clients either manually (JSON/TOML) or via the configurator CLI (@mcp-abap-adt/configurator, repo: mcp-abap-adt-conf).

Table of Contents

1. Getting Started
2. Architecture
3. Quick Start
4. Use Cases
5. Target Users
6. Capabilities (High-Level Focus)
7. Terminology
8. Authorization & Destinations
9. Registries
10. Features
11. Documentation
12. Dependencies
13. Running the Server

Getting Started

Pick a variant first — full or compact server, and HTTP, RFC or SNC to the system. HTTP needs nothing but Node.js 22 or 24; RFC and SNC need the SAP NW RFC library when the server runs — SAP GUI's 64-bit sapnwrfc.dll on Windows, else the SAP NW RFC SDK; the RFC module comes prebuilt for Linux x64 (glibc), Windows x64 and macOS ARM64, and npm install compiles nothing. Installation variants has the table and the commands; RFC Setup the steps. To run without Node.js on a machine, build your own portable executable — Node.js and your SAP NW RFC SDK inside.

Install the server and configure your client using the configurator:

npm install -g @mcp-abap-adt/core

npm install -g @mcp-abap-adt/configurator

stdio (destination)

mcp-conf --client cline --name abap --mcp TRIAL

HTTP (streamable HTTP)

mcp-conf --client copilot --name abap --transport http --url http://localhost:3000/mcp/stream/http

Full configurator usage (separate repo): CLIENT_INSTALLERS.md.

Terminology

Destination: a local service key filename. You store service keys in the standard service-keys directory, and pass the filename (without extension) via --mcp= to select which system to use.

See docs/user-guide/TERMINOLOGY.md for the full list.

Authorization & Destinations

Destination-based auth is the default. Drop service keys into the standard platform folder and use the filename as your destination:

mcp-abap-adt --mcp=TRIAL --system-type=cloud

Standard service key paths:

• Unix (Linux/macOS): ~/.config/mcp-abap-adt/service-keys/ .json
• Windows: %USERPROFILE%\\Documents\\mcp-abap-adt\\service-keys\\ .json

mcp-abap-adt (stdio) supports exactly three authentications, each a destination stated in a service key, a .env, or both; a JWT you hold is sent in headers to the HTTP or SSE server:

A jwt .env must state SAP_GRANT_TYPE. The mcp-auth command that writes such a .env comes from @mcp-abap-adt/auth-broker-cli. The browser login listens on port 61001 unless --browser-auth-port says otherwise.

A created object always carries its responsible person and, where known, its master system. The servers name them once per destination — its credentials and its ABAP system — when its connection is created, by the rules of @mcp-abap-adt/responsible-rules: the system's systeminformation answer (its user, its system id) wins, on-premise and on ABAP Cloud alike; a tool argument that names the value (a transport's owner, say) still states it for that call. When the system gives no information, ABAP Cloud is an error (cloud_without_systeminformation for a 404, else system_lookup_failed); on-premise the responsible is SAP_RESPONSIBLE / x-sap-responsible if stated, else the login (SAP_USERNAME, x-sap-login), and the master system SAP_MASTER_SYSTEM / x-sap-master-system when stated; with no user at all the call is refused system_user_unknown, and a stdio start ends with exit 1. A 401 is answered as it came. The library applies no rules unless an embedder passes them. See Authentication & Destinations. Coming from 22.x? See the 23.0 migration note — CreateProgram no longer offers include (create an include with CreateInclude); an embedder registering the ./handlers groups on its own McpServer states systemType (SAP_SYSTEM_TYPE is not read there), and HandlerExporter serves no background run and no debugger. Coming from 21.x? See the 22.0 migration note — the tools, their enums and the object types each argument accepts are the declared system type's (onprem or cloud), inspection needs --system-type too, function / func are the function module, main types stand for their one code, RunATC on cloud offers no program, and ValidateServiceBinding requires package_name. Coming from 19.x? See the 20.0 migration note — RFC on connection 19 and sap-rfc-lite 0.3.2: nothing compiled on install, a prebuilt binding for Linux x64, Windows x64 and macOS ARM64 only; over Streamable HTTP state_handle is an argument of every tool, and a long session keeps one SAP session across calls. Coming from 18.x? See the 19.0 migration note — the server split into a package per transport and tool set, the system type required, the low set gone, the auth chain on 6.0. Coming from 17.x? See the 18.0 migration note — the debugger's embedder surface moved to adt-clients 29, and a debugger start needs at least one breakpoint. From 16.x, the 17.0 note first.

For full details (paths, .env, direct headers), see Authentication & Destinations.

Architecture

The project ships a library and the servers — and a compact variant of each server — because the two usage patterns want different licences. Embedding the tools in a network service should not drag in the obligations of a server that service never runs.

| @mcp-abap-adt/core-ro, http-ro, sse-ro | AGPL-3.0-only | The read-only se