Everything in the atlas

It is a bundle, not a plugin with one job. Depending on it for one feature brings the rest.

The generated files are copied or deployed into the ABAP system by hand, the fourth step of its own usage list, so nothing keeps an activated service in step with the model it was generated from. Its peer dependency is `@sap/cds` ^9.8, so it does not install into a project on an earlier CAP release.

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

Not published to npm. Install from source.

If document versions are required, [@cap-js/sdm](artifact:cap-js-sdm) excludes versioned repositories in its [documented restrictions](https://raw.githubusercontent.com/cap-js/sdm/ad13b61f21816ebead2d08264a74521cfb75846c/README.md).

For deployed environments, the [README](https://raw.githubusercontent.com/cap-java/cds-feature-attachments/302f61c8bb76a0f54f43482ad91d89bf7dc5540f/README.md) excludes the cds-feature-attachments-fs file-system target, which is intended only for local development and testing.

If document versions are required, the [documented restrictions](https://raw.githubusercontent.com/cap-java/sdm/673769f24ef66fd97daa6a6be41262d45065d3fe/README.md) exclude versioned repositories.

It is a bundle, not a plugin with one job. Depending on it for one feature brings the rest.

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

It is a bundle, not a plugin with one job. Depending on it for one feature brings the rest.

When your adoption policy excludes experimental dependencies: the [maintainer’s README](https://github.com/cap-js/cds-federation-synonyms#about-this-project) explicitly labels this plugin experimental.

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

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.

When your adoption policy excludes experimental dependencies: the [maintainer’s README](https://github.com/cap-js/cds-federation-synonyms#about-this-project) explicitly labels this plugin experimental.

It is a bundle, not a plugin with one job. Depending on it for one feature brings the rest.

If you need sub-second fan-out to external consumers this is the wrong layer — reach for [Event Mesh](artifact:btp-event-mesh) or Kafka. Without [Redis](external:redis), periodic processing still works but instant dispatch degrades to polling.

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.

Release and repository quiet for 24 months.

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.

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 maintainer states 0.x is beta with no production SLA, and scopes support deliberately narrowly: direct application-server transport, classic serialization and password authentication on S/4HANA 2023 and NetWeaver 7.50. Anything outside that is untested rather than unsupported.

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.

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.

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.

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.

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.

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.

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.