Everything in the atlas

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

If your tool reads the open skill standard directly, install [capire/skills](artifact:capire-skills) and skip the wrapper.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.