Distinct from MCP serversServe your application over MCPExposing selected application data and business operations to an AI agent through the Model Context Protocol. An application may also integrate remote services through service integration, connecting its exposed contract with agent access to your systems. Development assistance belongs to agent access to your code.SAP and community, narrow by design, which is a protocol adapter on your own running service, and from agent guidanceAgent guidancePackaged knowledge you hand a coding agent so it gets a framework right unprompted — skills, rule files, instruction packs. Distinct from agent tooling, which is about building agentic features into your application, and from agent access to your code, where the agent reads the real project instead of being handed a file about it.SAP and community, core adopted it, which is knowledge handed over as files rather than read from the thing itself.
AI & Agents
What a model or an agent is given and allowed to do: access to the code, the tools it may call, the retrieval behind its answers, and the guardrails around all of it.
Capabilities
Compare the concerns mapped here and open an ecosystem for its assessment. Artifact counts show providers; content counts show items linked directly to the capability.
Each ecosystem hexagon shows its own coverage assessment. Coverage is never combined across ecosystems.
Artifacts
Providers, examples and other artifacts mapped to this domain, from SAP and the community. Each artifact appears once.
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.
Not as a gateway or proxy for SAP Application APIs: capire's guide states that CAP-level agents are intended only for exposing custom CAP application services and are not an SAP-endorsed architecture or pathway for agentic access to those APIs, and sends the reader to the SAP Architecture Center for the endorsed routes. Not as the screen a user of the application talks to, either — the chat preview in the generic index.html page is marked experimental and for local development.
SAP prohibits gateway/proxy use for SAP Application APIs; the Atlas applies that prohibition to CAP wrappers around those APIs. Data changes require application-defined unbound actions, and the adapter supplies no rate limiting, agent-action audit logging, approval workflows or policy enforcement. In beta, with nine releases in the six weeks after the first, so pin it.
The tools are documented as meant for AI models and not a stable API, so anything built to parse `cds-mcp` output rather than to feed a model can break between releases. Its corpus is the CAP documentation, so Fiori elements, BTP service or ABAP questions are not in what `search_docs` indexes.
It writes and it administers — ETL extraction and database user management are not read operations, and the same connection that profiles a column can move data out of the tenant. Masking is only as good as the configuration naming the fields, so an unlisted sensitive column is an unmasked one.
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.
Not a way to edit Office formats: the author states that access to a file does not automatically provide native editing of Word documents, spreadsheets or PDFs, and suggests starting with text-based content such as instructions, templates and reports. Not a control point either: a prompt telling the agent to ask for confirmation or to leave a template alone needs enforceable application controls where that is a business requirement, and the host application stays responsible for the authenticated request context and tenant isolation.
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.
If your tool reads the open skill standard directly, install [capire/skills](artifact:capire-skills) and skip the wrapper.
It expects a real landscape, not just a project: a `.service.metadata` file naming the Mobile Services app, endpoint and destination, the Cloud Foundry CLI, and access to a BTP Cloud Foundry environment. From 0.4.0 macOS support is ARM64 only — Intel Macs are not supported — alongside Linux and Windows on x64 and ARM64.
It reads a UI5 project and the framework's own documentation, not a running system or a backend: a question about the service behind the app is answered somewhere else. Node.js v20.17 or v22.9 and above.
Not where the UI library itself is expected to bind data: the documentation leaves binding a component's content and events to the host framework. Not from a CDN script tag: the project publishes none, so it assumes a build step.
It answers from documentation and never opens your project, so it cannot tell you whether the component you are asking about is the one your application already uses. Node.js v20.17 or v22.9 and above; on Windows the command needs a `cmd /c` prefix.
No public repository is declared on the package, so the README is the documentation.
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).
No published releases; repository quiet for 28 months.
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.
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 a substitute for testing in a system: the README states that any class calling the database, classic BAPIs or HTTP is shimmed out and stays an on-stack ATC and ABAP Unit concern, and that an off-stack green is CI-grade provenance rather than an in-system pass. It also assumes a particular shape of project. The ABAP has to be abapGit-serialised into a Git repository, Node.js 22 or later has to be available locally and in CI, and the CI has to be GitHub Actions.
No published releases; repository quiet for 34 months.
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.
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.
Configuration over an API you must already have entitled and provisioned; and the smallest of these repositories, so what it covers is what its config file happens to name.
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.
Every skill that touches ABAP needs [arc-1](artifact:arc-mcp-arc-1) itself connected to a real system; nothing else is universal. `modernize-ui5-app` and `convert-ui5-to-fiori-elements` specifically need [the UI5 MCP server](artifact:ui5-mcp-server) for TypeScript conversion guidance and the linter, `convert-ui5-to-fiori-elements` also needs [the Fiori MCP server](artifact:sap-ux-fiori-mcp-server) for its LROP scaffold, and `modernize-ui5-app` needs a browser MCP (Claude in Chrome or Claude's own Preview) for its final render-verification step, since an HTTP 200 alone does not catch a blank page. A skill file alone, without the servers a given skill needs, has nothing to act on.
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.
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.
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.
The diff holds only while the object is inactive, since after activation the previous version is gone and a watched journal directory is what the maintainer points to instead. It adds no write path of its own: the IDE writes through SAP's extension, and the README states arc-1 can stay on `SAP_ALLOW_WRITES=false`. DDIC metadata files are skipped, because SAP's own stub for them says they are not supported in ABAP development tools for VS Code.
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.
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 administers a real account through Core Services, so what it can change is what the caller can change. And the UI half depends on hosts that render mcp-ui or MCP Apps resources; elsewhere those five tools return markup nobody displays.
Neither the package manifest nor the repository tree declares a licence.
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.
No license Neither the package manifest nor the repository tree declares a licence.
Functional boundary There is no licence, so there is no grant to use or redistribute it. Everything else is secondary to that. Note too that its 'verified' claim means the skill text was checked against itself by an evaluation suite — not that the advice was run against a CAP version.
Not where the agent is reached over anything other than A2A: the README states the plugin does not speak anything other than A2A as @cap-js/agents serves it. Not where an upgrade has to be uneventful either — it pins @cap-js/agents to exactly 0.9.1, calls that package pre-1.0 and days old at the time of writing, and says this plugin inherits that instability and to expect breakage on upgrade.
Neither the package manifest nor the repository tree declares a licence.
Neither the package manifest nor the repository tree declares a licence.
Not where the records sit anywhere but [SAP HANA Cloud](artifact:btp-hana-cloud): the similarity search and the single retrieval method are both written against its vector engine, and the embeddings and the chat call go through [SAP AI Core](artifact:btp-ai-core), so a project without both has nothing here to call. Not where the dependency has to be an SAP-supported one either: the README states that the plugin is not an official SAP product and is published as a community contribution.
Not published to npm. Install from source.
Local scaffolding only. Its own Out of Scope list names deployment to Cloud Foundry or Kyma, XSUAA and IAS configuration or any other BTP service binding, the SaaS Registry and subscription flow to real tenants, and automatic migration from the legacy `@sap/cds-mtx`. For the concepts rather than the scaffolding step, the README points at the `multitenancy` skill in [skillOverflow](artifact:dankromp-skilloverflow) by [Daniel Krompaß](actor:dankromp), which covers the MTX sidecar, `xs-security.json`, tenant lifecycle hooks and the deployment path and runs no commands at all.
Neither the package manifest nor the repository tree declares a licence.
It calls the OpenAI API directly with a key in the environment. It was written in early 2023 and last touched in May 2023, which is before SAP AI Core and the CAP LLM plugins existed — so read it for the shape of the application, not for how a CAP service should reach a model today.
Neither the package manifest nor the repository tree declares a licence.
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.
A thin declaration over CPI's APIs: it reaches what those APIs expose and nothing else, and it inherits whatever the tenant's own authorisations allow.
Knowledge with no reach: without an MCP server connected it can tell an agent what to write and cannot let it read or run anything. The rules target the ABAP Cloud development model, so a classic on-premise codebase is not what they are written against.
Not for S/4HANA Public Cloud or [the BTP ABAP environment](artifact:btp-abap-environment), where the README states there is no `SUBMIT`, NAST or SOAP-RFC; the floor elsewhere is SAP_BASIS 7.50, the `/sap/bc/soap/rfc` service active, and an SAP user with `S_RFC` on the kit's function group as well as the authorizations for the reports and the spool. Print output is NAST messages only, so S/4 Output Management through BRF+ or APOC is outside it, and editing covers SmartForms alone, with Adobe Forms and SAPscript previewable but not editable. A report that opens a popup, calls a screen or is a dialog transaction cannot be run at all.
Neither the package manifest nor the repository tree declares a licence.
Design-time only: no message monitoring, no deployment, no runtime status. That is a different server in this same section, and the two do not overlap.
Neither the package manifest nor the repository tree declares a licence.
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.
The README tells you to fork before cloning, because Claude rewrites `references/` and `SKILL.md` in place as you use it, so a clone shared between people changes under all of them. Installing means `git` and `ln` on macOS or Linux and a symlink into `~/.claude/skills`. Fine positioning stays manual: the coordinates Claude writes can be rough apart from the centre coordinates of elements joined by a straight arrow and the containment relationships.
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.
It runs on macOS only. Hammer Core Services, the part installed into the SAP system, needs that system on ABAP Platform 2023 or newer with SAP_BASIS 758 or newer, and installing it needs a user who can create development objects and run background jobs in that system.
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.
Its maker offers it commercially.
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.
The declared repository is archived.
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.
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.
It acts on a real account. Authorisation is the caller's own — single sign-on through the SAP Default Identity Provider, across the global accounts that identity reaches — so what it can change is what you can change, and an agent invoking it is doing administration rather than proposing it. No public source, so what it exposes is what the documentation says it exposes.
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.
Neither the package manifest nor the repository tree declares a licence.
Neither the package manifest nor the repository tree declares a licence.
It deploys and undeploys, and it enumerates credentials, keystores and OAuth2 configurations. Listing security material is a read, and it is still a read of the thing that protects everything else the tenant talks to.
Business Source License 1.1, which is source-available rather than open source: reading and evaluating are fine, and production use is restricted until the licence's change date. That is a procurement question, not a technical one, and it is the thing to settle first. Read-only also means read-only — no modelling, no loads.
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 reads the landscape inventory, not the systems in it — nothing here reaches a running application, and nothing here changes anything. A landscape description is also commercially sensitive in its own right: versions and hosts are what a targeting exercise starts from.
No published releases; repository quiet for 29 months.
There is nothing to clone here: "Access is provided through a registration page. Once registered, you will receive access to the GitHub repository containing the agents, deployment guides, and documentation", and that repository answers 404 to anyone who has not registered, so neither the agent code nor the deployment guides can be read before the form is filled in. AWS states the agents are published as an unsupported solution, with customers responsible for testing and securing the code before deploying in production, and that they are intended for non-production SAP environments rather than production systems. The documentation link in the README is still a placeholder.
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.
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.
A requirement that needs code: the skill generates configuration and states that it says so instead of faking it. Dialog and container targets have no verified enter event, so a dashboard placed there loads only through its Refresh button. Production Processes are outside it — it wires PODs to them and does not design them.
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.
Neither the package manifest nor the repository tree declares a licence.
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.
Every CDS service in both samples is marked `@requires: 'any'` and left publicly accessible, which the README says simplifies the deployment process, and it asks for proper authentication mechanisms to be applied in their place.
It says so itself, in bold, and the atlas repeats it: not legal advice and not a compliance decision. Only SAP, your contract, or SAP support can answer bindingly, and the skill routes legal, commercial and roadmap questions there rather than guessing at them. Treat the output as evidence gathered, not as a verdict.
Every CDS service in both samples is marked `@requires: 'any'` and left publicly accessible, which the README says simplifies the testing and deployment process, and it asks for proper authentication mechanisms to be applied in their place.
Every CDS service in both samples is marked `@requires: 'any'` and left publicly accessible, which the README says simplifies the testing and deployment process, and it asks for proper authentication mechanisms to be applied in their place.
Every CDS service in both samples is marked `@requires: 'any'` and left publicly accessible, which the README says simplifies the testing and deployment process, and it asks for proper authentication mechanisms to be applied in their place.
Every CDS service in both samples is marked `@requires: 'any'` and left publicly accessible, which the README says simplifies the testing and deployment process, and it asks for proper authentication mechanisms to be applied in their place.
Every CDS service in both samples is marked `@requires: 'any'` and left publicly accessible, which the README says simplifies the testing and deployment process, and it asks for proper authentication mechanisms to be applied in their place.
Every CDS service in both samples is marked `@requires: 'any'` and left publicly accessible, which the README says simplifies the testing and deployment process, and it asks for proper authentication mechanisms to be applied in their place.
It reaches a data warehouse, so what an agent can see is business data by definition — the SQL sanitisation and PII filtering in the server are there because of that, not instead of a decision about it. And the guidance is Datasphere-shaped: nothing here transfers to a HANA Cloud database used directly.
Provisioned per plan and per component, so capacity and cost are decisions taken before any model exists. And it is the database, not a warehouse — modelling, loading and cataloguing are the products above it, and reaching it directly bypasses every semantic they add.
This is enterprise-architecture data, not a development surface — it answers what your landscape contains, never what your code does, and nothing in it belongs in a build. Entered here because it is a first-party SAP MCP endpoint and the catalogue that tracks this corner lists it; the atlas maps SAP development, so treat it as adjacent rather than as tooling for a project.
Host-specific: outside Kiro the automatic context activation is the part that does not come with it, and what remains is prose you would have to wire in yourself. Breadth over depth by design — thirty-five skills across six product areas is an orientation layer, not a substitute for the focused sets in each.
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.
A diagram of anything other than an SAP, BTP or on-premise landscape: the skill is tuned to the Horizon style and its 71 templates. It drafts rather than finishes, and its README budgets 15 to 30 minutes of edits in draw.io per diagram. Without Python the validator does not run.
The commands it writes stop production systems, delete data and import transports, which is why execution is deliberately somebody else's decision. BTP and cloud operations are explicitly out of scope and planned as a separate plugin.
Business Source License 1.1: source-available, with production use restricted until the change date — settle that before anything technical. And the governed execution path in v0.2 does act on data, which is a different grant from the discovery the v0.1 baseline offered.
It stops before the artifact: in the README's own words it does not generate or deploy complete iFlow artifacts, so building and shipping the integration flows themselves stays with a person and a tenant. Knowledge beside the work rather than a generator, and it reads nothing from a running tenant.
Not for a project below the 2211-jdk21.1 baseline: older releases and the JSP Accelerator are covered only as explicitly marked legacy material, so a JSP storefront or a pre-JDK-21 platform is outside what the guides are written against. Knowledge with reach only through one script — it can tell an agent what to write and, apart from `query-items.sh`, cannot let it read what a given system contains.
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.
An early alpha release whose README says to pin the version and test recipes against non-production data first. HANA synchronisation is snapshot-only and does not reconcile deleted rows, so a document for a row deleted in the source stays in the index. A recipe's field allow-list does not decide what the service account may read: the README states that field allow-listing does not replace SAP authorization, and that the package infers no SAP module semantics, authorization scope or safe fields from table names. Only Business Partner has a built-in recipe, every other dataset needs a `KnowledgeRecipe` written for it, and [Qdrant](external:qdrant) local mode is stated to be for development and smaller indexes.
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.
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.
Its README calls it early-stage — the core workflows run end-to-end against real systems and packaging, documentation and polish are stated as still evolving. A Rust binary rather than an npm install, so the platform build matters.
Inspection only, and it takes a host, a user and a password from the environment rather than a managed credential. PI and PO are also on their own end-of-maintenance path, which is the context any investment here sits in.
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.
Skills that generate commands are not the commands: everything here still runs against a real BTP account with real entitlements, and the deployment path assumed is Cloud Foundry, with `cf login` and `joule login` done before the toolkit is used. Three of the four skills are CLI knowledge rather than anything Joule-specific, which is worth knowing if you only wanted the agent part.
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.
It works against a tenant, through the REST API, with credentials in the environment — so these skills act rather than advise, and the review skill is a check on generated content rather than a substitute for one. Nothing here is useful without an Automation Pilot tenant to point at.
Enterprise-architecture work, not development: this describes what your landscape records, never what your code does. And the skills assume the server — without [the LeanIX MCP server](artifact:sap-leanix-mcp-server) reachable against your instance, they are instructions with nothing to call.
Knowledge about theming, not a theme build: nothing here compiles a theme or deploys one, and it says nothing about a custom control's own parameters.
Neither the package manifest nor the repository tree declares a licence.
GPL-3.0, which is a licence to read before vendoring any of it into something you ship. Forty plugins is also a lot of always-available surface — the ledger is there because breadth and verification pull in opposite directions, and it does not resolve that so much as report it.
This is HR data — the most regulated business data most organisations hold — reached through a connection that sees whatever its principal sees. Employee records under natural-language query is a decision for whoever owns that data, not a configuration choice.
Its maker offers it commercially.
It is a plugin for one server — its own — so it is a stack rather than a component. And the guard is only as good as the profile labels: a production system registered as `DEV` is a production system with the safety off.
Two skills, narrowly scoped: nothing here scaffolds an application or answers what a component's API is — that is [@ui5/webcomponents-mcp-server](artifact:ui5-webcomponents-mcp-server), which reads the same library's documentation.
Neither the package manifest nor the repository tree declares a licence.
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.
Guidance, not access: these are instructions handed to an agent, and what the agent can then read of your project comes from [@ui5/mcp-server](artifact:ui5-mcp-server) or the editor. A modernisation workflow that runs autonomously across a codebase is also a thing to point at a branch rather than at main.
Neither the package manifest nor the repository tree declares a licence.
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.
Related capabilities
Distinct from MCP serversServe your application over MCPExposing selected application data and business operations to an AI agent through the Model Context Protocol. An application may also integrate remote services through service integration, connecting its exposed contract with agent access to your systems. Development assistance belongs to agent access to your code.SAP and community, narrow by design, which is a protocol adapter on your own running service, and from agent guidanceAgent guidancePackaged knowledge you hand a coding agent so it gets a framework right unprompted — skills, rule files, instruction packs. Distinct from agent tooling, which is about building agentic features into your application, and from agent access to your code, where the agent reads the real project instead of being handed a file about it.SAP and community, core adopted it, which is knowledge handed over as files rather than read from the thing itself.
Serving your application over MCPServe your application over MCPExposing selected application data and business operations to an AI agent through the Model Context Protocol. An application may also integrate remote services through service integration, connecting its exposed contract with agent access to your systems. Development assistance belongs to agent access to your code.SAP and community, narrow by design exposes your own service contract; system access reaches the systems behind it, and one implementation may do both.
Development assistance belongs to agent access to your codeAgent access to your codeLetting a coding agent read the project or the system you actually have, reach its model, its objects and its checks, and act on it. In file-based environments that works out of the box; complex systems need dedicated access capabilities. Whatever the environment, the agent also needs project- and framework-specific context, so it understands the thing in front of it rather than guessing from what it remembers of its training data. The transport is incidental: an MCP server, a language server or a CLI answer the same question, and what differs between them is how much of the real thing the agent can see. Distinct from MCP servers, which is a protocol adapter on your own running service, and from agent guidance, which is knowledge handed over as files rather than read from the thing itself.SAP and community, unassessed.
This is the user-facing experience around agents; building their logic belongs to Agent toolingAgent toolingBuilding an agent into your own application — the tools it may call, the state it keeps between turns, and the framework it runs in. Distinct from MCP servers, which expose an application to somebody else's agent, and from agent guidance, which is knowledge handed to a coding agent.SAP and community, unassessed, and controlling their calls belongs to Tool governanceTool governanceControlling what an agent may call, with which authorisations, and leaving an audit trail of what it did. The authorisation question that MCP exposure raises but does not answer.SAP and community, unassessed.
This is the user-facing experience around agents; building their logic belongs to Agent toolingAgent toolingBuilding an agent into your own application — the tools it may call, the state it keeps between turns, and the framework it runs in. Distinct from MCP servers, which expose an application to somebody else's agent, and from agent guidance, which is knowledge handed to a coding agent.SAP and community, unassessed, and controlling their calls belongs to Tool governanceTool governanceControlling what an agent may call, with which authorisations, and leaving an audit trail of what it did. The authorisation question that MCP exposure raises but does not answer.SAP and community, unassessed.
Distinct from data maskingData maskingReplacing the personal or confidential values in a prompt with placeholders before it leaves for a model, and putting them back in the answer. Anonymisation, where the values are gone for good, and pseudonymisation, where they return, are the two forms; which fields count as sensitive is the application's question, not the module's.SAP only, which hides values: a filter refuses content.
Generating an application's source at design time is generatorsGeneratorsGetting from nothing to a project that runs, and from a project that runs to one that has the piece you just decided you need. Two different moments: the first is a one-time decision about layout, the second recurs for the life of the project.SAP and community, narrow by design.
Agent access to your codeAgent access to your codeLetting a coding agent read the project or the system you actually have, reach its model, its objects and its checks, and act on it. In file-based environments that works out of the box; complex systems need dedicated access capabilities. Whatever the environment, the agent also needs project- and framework-specific context, so it understands the thing in front of it rather than guessing from what it remembers of its training data. The transport is incidental: an MCP server, a language server or a CLI answer the same question, and what differs between them is how much of the real thing the agent can see. Distinct from MCP servers, which is a protocol adapter on your own running service, and from agent guidance, which is knowledge handed over as files rather than read from the thing itself.SAP and community, unassessed works with development objects instead of the user interface.
Free-text search over entities is searchSearchFree-text search across an entity and its compositions, pushed into the database rather than filtered in the service. Declared search, database similarity search and filtering in application code are often lumped together.SAP and community, unassessed; similarity over embeddings is retrieval-augmented generationRetrieval-augmented generationGrounding a model's answer in data retrieved at question time: text split into chunks, each chunk embedded as a vector, and the chunks nearest to the question placed into the prompt. Semantic search is the same retrieval with a person reading the matches, and fine-tuning changes the model's weights, not its input.SAP and community, unassessed.
Distinct from LLM integrationLLM integrationCalling a language model from application code with the tenant, destination and credential handling already solved instead using an SDK call with a hand-rolled key.SAP and community, narrow by design, where a language model generates text, even where both run on the same service.
Computed in the application over data it already holds, which is what separates it from analytical queriesAnalytical queriesGrouped, aggregated and filtered reads for analytical clients, answered by the database rather than in application memory. This concerns the queries a chart or report sends, while analytic modelling defines the measures and dimensions they read.SAP only, where a service answers the grouped read a chart sends, and from predictive modelsPredictive modelsTraining, deploying and calling a model that predicts a value from tabular business data: a classification, a regression, a forecast. Distinct from LLM integration, where a language model generates text, even where both run on the same service.SAP only, which train and serve something that predicts a value.
Across stacks
Content
Content includes reference architectures. Each item appears once; filter by type to narrow the list.
Recent changes
- Agent access to your codecoverage by ecosystem revised
Reassessed against the graph (check:capabilities): independent and partner providers (sap-ai-dev-toolkit, bw-modeling-mcp, Modernization Agents for SAP on AWS) now serve the BTP door beside SAP's @sap/mdk-mcp-server, so the stated core-only contradicted the providers. The note only explained that state.
- Agent access to your codecoverage by ecosystem revised
Reassessed against the graph (check:capabilities): the note and the closing sentence counted providers and claimed an absence in the corpus, which moves with the graph.
- Agent evalscore coverage revised
Reassessed against the graph (check:capabilities): the wording flagged as counting providers or claiming none exist is rephrased; states unchanged.
- Agent evalscoverage by ecosystem revised
Reassessed against the graph (check:capabilities): DanKromp/skillOverflow is independent and lists btp in serves_ecosystems, so the community is present beside the AI Core services the block's sourced what_core_does describes.
- Agent evalscoverage by ecosystem revised
Reassessed against the graph (check:capabilities): albertmink-agentic-abap-evals, an independent set of ABAP tasks and a grader for coding agents, was entered after the block was written; the count is dropped and the second kind named. State unchanged.
- Agent guidancecoverage by ecosystem revised
Reassessed against the graph (check:capabilities): SAP Developers MCP, the sap-official hosted server of developers.sap.com, provides this capability and lists the ABAP door in serves_ecosystems, so an SAP-published provider counts for the door. The earlier reading held when every provider counted for ABAP was independent.
- Agent guidancecoverage by ecosystem revised
Reassessed against the graph (check:capabilities): the state now has a core half, and the block had no what_core_does to say what it is. Sourced from the server's own MCP quickstart, retrieved 2026-10-26.
- Agent guidancecoverage by ecosystem revised
Reassessed against the graph (check:capabilities): "All of it" and the provider count and absence claims no longer hold with an SAP-published provider counting for the door. Fresh providers abap2ui5-vscode-extension, yannick-thirion-klystron and marianfoo-werkbank change the kinds of answer on offer.
- Agent guidancecoverage by ecosystem revised
Reassessed against the graph (check:capabilities): provider counts go stale as providers arrive, and the option list derives them (docs/WRITING.md §3).
- Agent guidancecoverage by ecosystem revised
Reassessed against the graph (check:capabilities): counts of providers and claims that none exist in the corpus are ruled out by docs/WRITING.md §3.