Everything in ABAP

Stateful apps cannot be operated: a stateful session lives in one HTTP request and an MCP call is one request, so `app_start` refuses them. The repository carries no release yet and states the addon has not been run in production use, the 7.02 downport is lint-only with no 7.02 system having run it, and the ABAP Cloud HTTP service setup is written down but still to verify on your own system.

Server side only, and deliberately: the author states there is no realistic way to support the SSE streaming a client needs, so there are no notifications, no `listChanged`, no `subscribe` and no logging. It is also frozen — protocol versions up to 2025-11-25 and no further, with everything after that in a separate V2 SDK, so starting here today is starting on a closed branch.

Stateless by design: with no `Mcp-Session-Id` and no SSE, notifications of any kind, `resources/subscribe` and stream-close cancellation are excluded, which the author states are protocol-level impossibilities on stateless ICF rather than gaps to be filled later within this design. ABAP Cloud is not supported and not planned, the stated reason being SAP pushing its own MCP strategy and features in BTP; the first iteration targets 7.5x classic, with 7.02 to 7.4x served from a separate generated downport repository. No authorization object and no default auth check are delivered, so a user who may call the ICF node may call every `AREA`/`SERVER` registered under it until `check_authorization` is redefined.

Not reachable Not reachable since 2026-10-20.

Functional boundary What it exposes is whatever somebody put in the configuration table, which moves the governance question inside the SAP system and out of the server — an advantage if that table is controlled and a hazard if it is not. The web management interface is a second surface to secure alongside the MCP one.

Its maker offers it commercially.

Its README says it plainly and so does this entry: this is not a simulation, every tool call reaches a live BW system, and write operations produce real changes. BW modelling objects are the definition of a warehouse — the blast radius of a wrong one is every report built on it.

Neither the package manifest nor the repository tree declares a licence.

Not where SAP's own Google Workspace integration already applies: the README opens by announcing a native integration between Google Workspace and [SAP S/4HANA](external:sap-s4hana), whose first set of features is included in SAP S/4HANA Cloud 2208 and SAP S/4HANA 2022 and needs an additional licence for the SAP Document Management Service. Not where end users cannot each hold a regular Google account, since there is no way to use an enterprise account or to log on to Google Drive through single sign-on, and not where the redirect URL Google calls cannot reach a public top-level domain server. No SAP standard support is provided for it.

Its README says it plainly and so does this entry: this is not a simulation, every tool call reaches a live BW system, and write operations produce real changes. BW modelling objects are the definition of a warehouse — the blast radius of a wrong one is every report built on it.

Neither the package manifest nor the repository tree declares a licence.

Every gate here runs off-system, so what the class does on a real system and what the view does on the oldest UI5 release it has to serve are what the `pitfalls` catalogues carry and no local run can see. It runs abap2UI5 app classes, so ABAP that is not one has nothing here to deploy into. In system mode the sandbox tools are not offered, and an `app_act` event runs on the system as the configured user.

A descendant rather than a distinct idea: if what you need is the ADT surface itself, its ancestors are entered here too and one of them may already be in your stack.

Written for Amazon Q Developer and Kiro, and the central deployment path is ECS Fargate — the further you are from AWS, the more of it is scaffolding you do not need. Python rather than the Node most of this group uses. Its README says the repository is no longer maintained and that the latest version of ABAP Accelerator is shared after registering with AWS for [Modernization Agents for SAP on AWS](https://github.com/aws-for-sap/Modernization-Agents-for-SAP-on-AWS).

A Python 3.10+ CLI, installed with pipx rather than through any SAP-provided package manager. Its own README lists what it does not do yet: where-used, syntax check and unit test runs — for those it says to reach for [ADT/Eclipse](external:eclipse) or an MCP server. First release, v0.1.0, and no standalone LICENSE file in the repository — the MIT grant is in the README and in pyproject.toml's project metadata rather than its own file.

Neither the package manifest nor the repository tree declares a licence.

Commercial Its maker offers it commercially.

Functional boundary The MIT licence covers the connector only: connecting to SAP needs a licensed ABAPilot backend installed in your system, so this is a commercial decision wearing an open-source badge on one half. Its own published checks did not cover writes, activation, transports or authorisation boundaries.

A system that reports itself productive, or whose role the probe cannot prove non-productive, is write-locked with no override, so changing code in production is not something this does. The permission ladder constrains the package, object name and transport request the server itself passes on a write, and is not a sandbox around ABAP it executes: `abap_run`, `abap_test` and the opt-in `core.eval` run under the connected technical user's SAP authorisations, which is where the boundary actually sits. Data preview, dump variable contents and driving a transaction by batch input stay off in every mode, `admin` included, until each is named explicitly.

There is nothing to install and nothing to deploy, and equally nothing to run headless: in VS Code it exists only while ADT for VS Code is running with a logged-on ABAP project, so it is a developer's local surface rather than anything a pipeline or a hosted agent can reach. No public repository, so what it exposes is what the documentation says it exposes.

Not reachable Not reachable since 2026-10-20.

Functional boundary `run_class` executes code in your system — that is the point and it is also the risk.

Classic BOPF only: business objects of the ABAP Programming Model for SAP Fiori are not handled, and on [the BTP ABAP environment](artifact:btp-abap-environment) or S/4HANA Public Cloud classic BOPF enhancements do not exist. It is version 0.1.0, verified on S/4HANA 2025 (SAP_BASIS 816) on-premise only, and [arc-1](artifact:arc-mcp-arc-1) still marks the plugin API it is built on as experimental. ARC-1 loads no extensions on its multi-target routes and offers none of these tools in its `hyperfocused` tool mode.

Single-tenant today, one technical user, with per-user principal propagation on the roadmap — so a shared deployment cannot yet act as the developer who asked. The sibling edition [ARC-1](artifact:arc-mcp-arc-1) speaks ADT directly if you would rather not depend on the language server.

It lives inside Eclipse and inherits everything that implies — the session is a developer's, not a pipeline's. And it is version-bound: ADT 3.60 or newer for 0.5.1, with 0.3.x the path for ADT 3.58 and 3.59.

Its README says it plainly and so does this entry: this is not a simulation, every tool call reaches a live BW system, and write operations produce real changes. BW modelling objects are the definition of a warehouse — the blast radius of a wrong one is every report built on it.

Built and last touched in the same week of March 2026, so the maintenance reading is what it is — the authentication work is the reason to look, and a stalled repository is the reason to read it before depending on it.

Freestyle SQL and `abap_run` mean an agent can read data and execute code, which is well past reading source. Neither is something to grant on a system where the distinction between development tooling and business data matters.

In the Eclipse mode the server lives in a developer's IDE, binds to 127.0.0.1 and answers any request carrying an `Origin` header with HTTP 403, so a pipeline or a remote agent has nothing to reach; the standalone mode on the runtime of the ADT for VS Code extension is the documented route with no IDE open. A new connection starts in write mode, so the 11 write tools are live against a connected system until someone presses Toggle Read-Only. The dropins route for the two bundles is documented as untested.

A compiled binary rather than an npm package, shipped prebuilt per platform and through pip and uvx. It collects anonymous usage telemetry by default, switched off with `--no-telemetry` or `DATAZOO_DISABLE_TELEMETRY=1`. And the BW reach is what distinguishes it — if the work is plain ABAP, that half is weight you are not using.

Neither the package manifest nor the repository tree declares a licence.

Two licences, by which package you install: the standalone server, `@mcp-abap-adt/core`, is AGPL-3.0-only, a licence to read before shipping anything built around it; the library, `@mcp-abap-adt/lib`, is Apache-2.0. The destination model also expects service keys sitting in a local directory, which is a secrets decision to make deliberately.

Its maker offers it commercially.

Development and sandbox systems only: the README warns against pointing it at production. Transport release is never executed, since the tool exists to show the policy stopping it, and separation of duties is checked against the `identity.approvers` list in the policy file rather than against SAP authorisations, so it holds as far as that file does and no further. The write path has been tested with ABAP classes and other object types may need adjustments, there is deliberately no tool that creates or deletes an object, and one server instance serves one SAP system.

Its own README opens by calling the server experimental. It also writes: locking, editing and activating in a system an agent can reach is a permissions decision before it is a tooling one.

Every tool its README lists reads — Get and Search, nothing that writes. Locking, editing, activation and transports are the other server, [mcp-abap-abap-adt-api](artifact:mario-andreschak-mcp-abap-adt-api), and mixing the two is how you end up with two MCP servers pointed at one system.

Real SAP calls need the proprietary [SAP NetWeaver RFC SDK](external:sap-nw-rfc-sdk) and the `pyrfc==3.3.1` release the README calls archived and yanked, on Python 3.11, so without those only the demo backend answers. Not over HTTP as it stands: credentials are read from the environment for stdio, and the README says not to expose the server over HTTP without implementing the MCP authorization specification and deployment-level rate limiting. Multi-tenant auth and RBAC beyond the one server-wide policy, rate limiting, metrics and tracing, and deployment packaging are listed as not built. The result limits protect the client and not the system, since the README states they cannot reduce work already performed inside SAP, and the MCP tool annotations that describe read and write risk are advisory metadata rather than an authorisation boundary, so the service account's `S_RFC` and table authorisations are still what decides.

Its maker offers it commercially.

Reach is the reason to use it and the reason to be careful: reading cluster tables and spool output goes well past what a development tool is normally pointed at. Decide what an agent may reach before granting it, not after.

Read-only in practice, and the documentation is Korean; the tool names are English but the guidance around them is not.

Smart Form content cannot be read or written, and HR Forms (`PE51`) are not implemented. Installing it needs SAP GUI or WebGUI once, to register the OData services in `/IWFND/MAINT_SERVICE` and to redefine the write service in `SEGW`, and the extension is built against a locally linked ARC-1.

No license Neither the package manifest nor the repository tree declares a licence.

Functional boundary It consumes the `@experimental` public API, which the README says may break in any release. The RFC tool dials as one shared technical user with its own credentials, so SAP's log records that user and not the person behind the agent.

Every gate here runs off-system, so what the class does on a real system and what the view does on the oldest UI5 release it has to serve are what the `pitfalls` catalogues carry and no local run can see. It runs abap2UI5 app classes, so ABAP that is not one has nothing here to deploy into. In system mode the sandbox tools are not offered, and an `app_act` event runs on the system as the configured user.

A system that reports itself productive, or whose role the probe cannot prove non-productive, is write-locked with no override, so changing code in production is not something this does. The permission ladder constrains the package, object name and transport request the server itself passes on a write, and is not a sandbox around ABAP it executes: `abap_run`, `abap_test` and the opt-in `core.eval` run under the connected technical user's SAP authorisations, which is where the boundary actually sits. Data preview, dump variable contents and driving a transaction by batch input stay off in every mode, `admin` included, until each is named explicitly.

It puts create, update and delete on business entities behind natural language. Whatever the destination's principal may change, an agent may change — and "create a new customer" is a sentence, not a form somebody signed off.

Its maker offers it commercially.

OData v2 only, and untouched since August 2025 — the same author's [Go port](artifact:oisee-odata-mcp-go) is where v4 support and the tool-explosion work went.

Universal mode trades discoverability for size: one generic tool is harder for a model to pick correctly than a named one, which is why it is not the default. On a small service, standard mode is the better answer.

Real SAP calls need the proprietary [SAP NetWeaver RFC SDK](external:sap-nw-rfc-sdk) and the `pyrfc==3.3.1` release the README calls archived and yanked, on Python 3.11, so without those only the demo backend answers. Not over HTTP as it stands: credentials are read from the environment for stdio, and the README says not to expose the server over HTTP without implementing the MCP authorization specification and deployment-level rate limiting. Multi-tenant auth and RBAC beyond the one server-wide policy, rate limiting, metrics and tracing, and deployment packaging are listed as not built. The result limits protect the client and not the system, since the README states they cannot reduce work already performed inside SAP, and the MCP tool annotations that describe read and write risk are advisory metadata rather than an authorisation boundary, so the service account's `S_RFC` and table authorisations are still what decides.

On ECC the S/4HANA `API_*` services that the three convenience readers default to do not exist, so each one has to be pointed at a Z service of your own or replaced by the RFC tools. `read_table` inherits `RFC_READ_TABLE`'s 512-byte row, so a wide table needs an explicit field list and some fields cannot be selected at all, and the bridge starts a Node process and a fresh logon per call, with no pooling. The audit log is one line per call that includes the call arguments, so every filter and WHERE clause sent to SAP is written to a file that then has to be handled as sensitive.

Read-only does not mean low-stakes: a complete picture of who can do what in an SAP system is exactly what an attacker would want, and the ready-made endpoint is the vendor's rather than yours — the README also documents running the server yourself. The authentication is careful; the question of what leaves your landscape is still yours.

Its maker offers it commercially.

Its maker offers it commercially.

Stateful apps cannot be operated: a stateful session lives in one HTTP request and an MCP call is one request, so `app_start` refuses them. The repository carries no release yet and states the addon has not been run in production use, the 7.02 downport is lint-only with no 7.02 system having run it, and the ABAP Cloud HTTP service setup is written down but still to verify on your own system.

Archived The declared repository is archived.

Functional boundary With one SAP system the README says to point the client at that arc-1 directly. Version 1 exchanges tokens within a single subaccount, so backends spread across subaccounts are out; it keeps its session map in memory, so more than one instance needs sticky sessions or a shared store. It routes deterministically and runs no model, which is a different thing from an assistant that reasons across systems. The `/all` endpoint drops the per-connection isolation, and the maintainer's answer to that is a PROD backend set read-only at the SAP end rather than a tool surface that hides the writes.

Its README says it plainly and so does this entry: this is not a simulation, every tool call reaches a live BW system, and write operations produce real changes. BW modelling objects are the definition of a warehouse — the blast radius of a wrong one is every report built on it.

Development and sandbox systems only: the README warns against pointing it at production. Transport release is never executed, since the tool exists to show the policy stopping it, and separation of duties is checked against the `identity.approvers` list in the policy file rather than against SAP authorisations, so it holds as far as that file does and no further. The write path has been tested with ABAP classes and other object types may need adjustments, there is deliberately no tool that creates or deletes an object, and one server instance serves one SAP system.

Real SAP calls need the proprietary [SAP NetWeaver RFC SDK](external:sap-nw-rfc-sdk) and the `pyrfc==3.3.1` release the README calls archived and yanked, on Python 3.11, so without those only the demo backend answers. Not over HTTP as it stands: credentials are read from the environment for stdio, and the README says not to expose the server over HTTP without implementing the MCP authorization specification and deployment-level rate limiting. Multi-tenant auth and RBAC beyond the one server-wide policy, rate limiting, metrics and tracing, and deployment packaging are listed as not built. The result limits protect the client and not the system, since the README states they cannot reduce work already performed inside SAP, and the MCP tool annotations that describe read and write risk are advisory metadata rather than an authorisation boundary, so the service account's `S_RFC` and table authorisations are still what decides.

It answers about the object catalogue, not about your code: nothing here reads your system, so it will tell you a table is not released and not that you used it. That check is ATC's, and this is what makes ATC's answer actionable.

A Python 3.10+ CLI, installed with pipx rather than through any SAP-provided package manager. Its own README lists what it does not do yet: where-used, syntax check and unit test runs — for those it says to reach for [ADT/Eclipse](external:eclipse) or an MCP server. First release, v0.1.0, and no standalone LICENSE file in the repository — the MIT grant is in the README and in pyproject.toml's project metadata rather than its own file.

In the Eclipse mode the server lives in a developer's IDE, binds to 127.0.0.1 and answers any request carrying an `Origin` header with HTTP 403, so a pipeline or a remote agent has nothing to reach; the standalone mode on the runtime of the ADT for VS Code extension is the documented route with no IDE open. A new connection starts in write mode, so the 11 write tools are live against a connected system until someone presses Toggle Read-Only. The dropins route for the two bundles is documented as untested.

Its maker offers it commercially.

No published releases; repository quiet for 45 months.

A system that reports itself productive, or whose role the probe cannot prove non-productive, is write-locked with no override, so changing code in production is not something this does. The permission ladder constrains the package, object name and transport request the server itself passes on a write, and is not a sandbox around ABAP it executes: `abap_run`, `abap_test` and the opt-in `core.eval` run under the connected technical user's SAP authorisations, which is where the boundary actually sits. Data preview, dump variable contents and driving a transaction by batch input stay off in every mode, `admin` included, until each is named explicitly.

Driving the GUI reaches whatever a user can reach, which is business data and not a development surface. Decide what an agent may do in a session before granting one, not after. Windows only. The HTTP transport is meant for team use but binds to localhost, and unattended multi-user operation is listed as not yet available — a limitation and also the safer default.

Driving the GUI reaches whatever a user can reach, which is business data and not a development surface. Decide what an agent may do in a session before granting one, not after. It has also not been touched since February 2025, which the maintenance reading states — the three later entries here are where the CI, the Web GUI and the testing framing went.

Not reachable Not reachable since 2026-10-20.

Functional boundary Driving the GUI reaches whatever a user can reach, which is business data and not a development surface. Decide what an agent may do in a session before granting one, not after. And a UI test is slower and more brittle than the layer below it: this is for what only the screen can answer.

Neither the package manifest nor the repository tree declares a licence.