Everything in ABAP

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.

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.

The embedded preview needs a system that accepts basic auth: the documentation states that pure SSO or SAML without a basic-auth fallback is not supported, and points at `external` mode, which opens the app in the normal browser with the existing SAP session. On the web only the language half runs; the preview with its proxy, traffic log and screenshot, Ctrl+F3 activation, the render gate, the workspace-wide check and the MCP servers are desktop-only. The agent app tools send nothing until `abap2ui5.agent.enableAppTools` is switched on in User settings, because an event they fire runs as the configured user and changes data on the system for real.

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.

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.

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.

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.

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

Neither suite has been run against an ABAP system: the reference backends are the framework transpiled to Node and cap2UI5 on CAP, so what a check does on a real system is open. The portable profile is a subset of 61 controls, filled from a census of 247 core apps of which 64.8 % run unchanged, so an app outside it renders placeholders in the terminal and Adaptive Cards renderers.