Everything in the atlas

Not a system to run a business application on: there is no business application in it, and what it implements of the language, the dictionary and Gateway is a stated subset of each. It is a clean-room reimplementation of the `/IWBEP/` interfaces that bundles no SAP source and no standard DDIC, so a service that reads standard objects has nothing to read, and `ANORMALIES.md` records every place the runtime differs from SAP before any workaround is written.

Archived The declared repository is archived.

Functional boundary The repository is archived, so nothing here will move again. Fine to keep where it already runs; anything new should start from what the current cds deploy leaves open rather than from this.

Node below 22, or [@sap/cds](artifact:sap-cds) below 9: the package declares the first in engines and the second as a peer dependency. Any mail path other than Microsoft Graph, until a provider is written for it: graph is the only kind that sends, and basic, the kind configured by default, is the base class such a provider extends.

The metadata is inconsistent: the declared repository is github.com/acme/search-vocab and the README installs @acme/search-vocab, neither of which matches the published name. One release, November 2025.

Reach for the original unless you know why you are not. This is a republished copy rather than a fork with a direction of its own: the README points at cap-js/notifications for the details, and nothing here says what was changed or why.

The README is one line and the package carries no licence field. Last released July 2023. The repository the package declares has been deleted — verified against the GitHub API, not just a failed fetch. The package is still on npm, so it installs; the source it was published from is no longer readable, which is a harder thing to discover than a stale version number.

No public repository is declared on the package, so the README is the documentation.

The maintainer marks this under active development; public APIs, annotation names and OData contracts may still change.

Not behind a managed approuter: SAP Build Work Zone does not expose the `/$companion/**` routes, so Companion never reaches CAP, and the README names managed approuter and Work Zone as out of scope for v1. Not where help has to be authored in a browser, since the editor, the producer and writes are absent and content lives in files the plugin compiles.

Nothing about it is readable from outside the package: there is no repository, no issue tracker, and the npm page carries no readme, so the README, the examples and the changelog can be read only from the tarball or a CDN mirror, and a bug has nowhere to be filed. Provider URLs are called from the plugin with API keys taken from environment variables in a .env file, so on BTP no call resolves through a destination and the keys live in the environment. The npm line stops at 1.0.1 on 3 November 2025; the changelog shipped inside that version is headed v2.1, so the version npm shows and the version the author counts are not the same.

Not published to npm. Install from source.

The maintainer marks this early development; expect the contract to move.

Last released January 2022 at 0.0.21, against a passport strategy Microsoft has since deprecated.

When user-dependent responses are cached without user-aware or explicit operation keys, or translated responses share keys across locales. These cases require key isolation; locale-aware keys are off by default.

Last released April 2022 at 0.0.2, and no repository is declared on the package.

Quiet Release and repository quiet for 25 months.

Functional boundary It performs no authentication flow of its own. The app must already be protected by Entra ID OAuth 2.0 at the App Service level; this only maps the resulting claims. It is explicitly not intended to run locally.

Alerting by mail is not telemetry — if you need traces and metrics correlated across handlers, that is a different layer. It also publishes no repository, so the package is the only thing to read.

Last released June 2022 at 0.0.6, and no repository is declared on the package.

It declares no peer range on [@sap/cds](artifact:sap-cds) and publishes no repository, so there is nothing to read but the package itself and no CI to look at.

Last released December 2022. Nothing says it fails on current cds, but nothing says it was tried either. The repository the package declares has been deleted — verified against the GitHub API, not just a failed fetch. The package is still on npm, so it installs; the source it was published from is no longer readable, which is a harder thing to discover than a stale version number.

The declared repository is archived.

Last released January 2024 at 0.0.6. The repository the package declares has been deleted — verified against the GitHub API, not just a failed fetch. The package is still on npm, so it installs; the source it was published from is no longer readable, which is a harder thing to discover than a stale version number.

It changes what DELETE means for every client of the annotated projection, so anything that must actually remove a row — an erasure request, a retention job — has to go around it.

The declared repository is on SAP's internal GitHub (github.tools.sap) and is not publicly reachable, so npm is the only place to read anything about it.

Quiet Release and repository quiet for 30 months.

Functional boundary The annotation sits on a single element, so a rule that spans two fields, or one that needs a lookup, has nowhere in it to go.

It is text processing, not an agent: there is no tool calling, no retrieval and no conversation. It needs SAP AI Core, and the backend half needs [@sap-ai-sdk/orchestration](artifact:sap-ai-sdk-orchestration) installed alongside it — an optional peer, so a frontend-only install stays lean.

On the UI5 path what comes back is an XML view or fragment with the data already substituted, streamed as the entity's media content, rather than an HTML page — the README calls this pre-rendering, and only the Vue path produces markup. The view kept under `srv/` has its UI5 bindings replaced by Handlebars expressions, so it is a second copy of the view, separate from the one the application ships. Version 1.0.8 declares `@sap/cds` `>=8` as its peer dependency, which puts a project on CAP 7 outside its stated range.

Not in a project whose dependencies must all carry an open-source licence: KAEV is proprietary software, its licence page states that downloading or viewing the npm package does not by itself grant permission to use, copy, modify, redistribute, sublicense, sell, host or create derivative works, and the LICENSE file shipped with the package carries the controlling terms. Not as the last word on whether a UI5 application is secure: its rule reference states that a heuristic finding is not proof of a vulnerability, and its documentation puts professional security review beside it rather than under it.

Not reachable since 2026-10-20.

No published releases; repository quiet for 45 months.

It audits through npm: a project that resolves its dependencies with another package manager, or has no `package.json`, has nothing for it to run. What it reports is what `npm audit` knows, so a vulnerability outside the npm advisory data is not in its table.

It reads TypeScript exports only; a project written in plain JavaScript has no exported functions for it to extract. A call to the function name in a test file counts as tested, and a call through property access such as `.foo(` does not.

The Markdown is a snapshot of whatever help.sap.com served when the pipeline last ran, and the Standard library is scraped from the `latest` index, so which release a page describes follows from the scrape date rather than from anything the corpus states. `package.json` states ISC and the repository carries no LICENSE file, so what the copied SAP documentation may be used for is not stated in it.

Quiet Release and repository quiet for 27 months.

Functional boundary Not a test-data factory. It writes files at build time to seed a database, so it does not build fixtures inside a unit test. The declared peer range stops at cds 7 — nothing says it fails on 9, but nothing says it was tried either.

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.

The repository the package declares has been deleted — verified against the GitHub API, not just a failed fetch. The package is still on npm, so it installs; the source it was published from is no longer readable, which is a harder thing to discover than a stale version number.

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.

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.

Any run nobody is watching: the drawing tools work only while the draw.io canvas at `http://localhost:3000/` is open and connected, so there is no diagram to produce on a build agent or a server. Nothing checks the result either, because the maintainer keeps a diagram linter on the [roadmap](https://github.com/etosin/arc-draw#-roadmap) rather than in the release. The maintainer marks the status early at v0.x, installs it from source, and records testing with Claude Code alone.

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.

It administers a live Cloud Foundry landscape: `Apps`, `Organizations`, `Spaces`, `ServiceInstances` and `SecurityGroups` all carry create, update and delete alongside list and get. What a caller can reach is set by the role they hold, and the three templates in `xs-security.json` are MCPViewer for read, MCPEditor for read and write, and MCPAdmin for full administrative access.

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 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.

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.

This is the database, not an application in front of it, so what an agent can read is whatever the connection user can read — the guardrails bound the shape of a query, not the sensitivity of what it returns. Grant the connection the rights you would grant a person.

Not for production: the README states local and development instances only, and the server refuses a HAC URL whose host is not private unless `HAC_ALLOW_REMOTE=true` overrides that guard. Masking applies to `config_get` only, so `logs_tail` and `monitoring_info` output, thread dumps included, is unmasked and may carry sensitive data, and whatever a tool returns goes to the MCP client and its model. Certificate checks are disabled whenever `HAC_INSECURE_TLS=true` is set, which the README names as typical for local HAC.

LISA does the translation step only: it does not discover objects or manage transports, and its README pairs it with [an ADT MCP server](artifact:sap-adt-mcp-server) for those. Every write needs a transport request, and which object types it can write differs between public cloud or [the SAP BTP ABAP environment](artifact:btp-abap-environment) and on-premise or private cloud, and by release. Running it locally is meant for development and testing, not production.

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.

It reads documentation, never a system: nothing in it opens a package.json, a CDS model or an ABAP client, so a question about what your own project does has to be answered elsewhere. The offline half is only as fresh as the submodules the last build pinned, and the index answers where something is written down rather than which of two packages fits a task.

It fronts APIs you already have; nothing here reads a system's source or model, and a config file is only as good as the entity sets somebody wrote into it. OData V2 is the query surface it names.

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.

Ninety tools is a large surface to put in front of a model at once, and client-credentials OAuth means the tenant sees one identity rather than the person asking. Content transport and user management sit in the same tool list as reading a story.

The maintainer states it is unofficial, not endorsed by SAP, and that it uses authenticated Hub web and catalogue endpoints and browser session cookies in ways SAP's terms of service, SAP account terms or an organisation's own policies may restrict. The same README asks the reader not to use it for production, broad distribution or shared access without explicit approval, and says that installing it grants no permission to automate SAP services.

Three of its five reference corpora are not shipped: without an api.sap.com key and session cookie, a tenant bearer token and a local SAPUI5 fetch, the REST, MDO and UI5 tools return a message naming the preparation step that is missing. The HTTP transport has no authentication until `MCP_AUTH_TOKEN` is set, so anything past localhost needs that or an authenticating reverse proxy. Packing the ZIP, uploading it through Manage POD 2.0 Extensions and placing the widget in the POD Designer stay manual steps outside the agent, and the SAPUI5 fetch defaults to the SDK's newest version, which the README says is not the version a tenant runs. Node.js 22 or newer.

It needs an S-user with SAP Support Portal access, so there is nothing to search without a support contract behind the login. The maintainer states it uses private SAP APIs behind authentication, asks the reader to check whether that use breaches SAP's terms of service, and disclaims both liability and any guarantee that it keeps working. MFA is handled only by typing the code into a visible browser, so a headless deployment cannot complete a login that demands one.

What it returns is planning material, not a commitment, and the monorepo labels the server's role "future/planned features (planning only)". The maintainer also states it is unofficial, not endorsed by SAP, and that it uses authenticated Road Map Explorer web endpoints and browser session cookies in ways SAP's terms of service or an organisation's policies may restrict, with production, broad distribution and shared access called out as needing explicit approval. An account that requires MFA has to be bootstrapped once through a visible browser.

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

What adt-ls cannot do headless the maintainer puts out of scope, so a consumer that needs an ADT call the language server does not expose is back to speaking ADT itself. The README states the current runtime compatibility as verified on macOS arm64, against adt-ls 1.1.2 as the minimum and `1.1.2.202608131517` as the version tested. An Eclipse installation does not supply that runtime: SAP versions the two separately, so the VS Code extension has to be installed even where nobody opens VS Code.

It stops at the `AuthInfo` and the raw bearer token, and the README lists what stays with the consuming server: rate limiting, the scope and tool policy, the MCP transport, the SAP HTTP client's headers, and helmet-style hardening. The one piece of hardening it constrains rather than defers is the cross-origin opener policy, which it deliberately leaves unset because popup-based OAuth breaks under it. It is ESM-only on Node 22 or later and shares the host's Express and MCP SDK instances as peer dependencies, so a server on Express 4 cannot take it.