LISA

📦 Published to npm as @lisa-mcp/server@0.9.4.

npx @lisa-mcp/server            # run locally
npm install @lisa-mcp/server    # or deploy to BTP from npm (templates/mta)
docker pull ghcr.io/clementringot/lisa-mcp:0.9.4   # self-hosted container

See the server CHANGELOG for details.

📦 Published to npm as @lisa-mcp/server@0.9.3.

npx @lisa-mcp/server            # run locally
npm install @lisa-mcp/server    # or deploy to BTP from npm (templates/mta)
docker pull ghcr.io/clementringot/lisa-mcp:0.9.3   # self-hosted container

See the server CHANGELOG for details.

📦 Published to npm as @lisa-mcp/server@0.9.2.

npx @lisa-mcp/server            # run locally
npm install @lisa-mcp/server    # or deploy to BTP from npm (templates/mta)
docker pull ghcr.io/clementringot/lisa-mcp:0.9.2   # self-hosted container

See the server CHANGELOG for details.

📦 Published to npm as @lisa-mcp/server@0.9.1.

npx @lisa-mcp/server            # run locally
npm install @lisa-mcp/server    # or deploy to BTP from npm (templates/mta)

See the server CHANGELOG for details.

📦 Published to npm as @lisa-mcp/arc1-extension@0.3.2.

npm install @lisa-mcp/arc1-extension@0.3.2

See the extension CHANGELOG for details.

📦 Published to npm as @lisa-mcp/server@0.9.0.

npx @lisa-mcp/server            # run locally
npm install @lisa-mcp/server    # or deploy to BTP from npm (templates/mta)

See CHANGELOG.md for details.

Changed

• OIDC audience validation is now mandatory. When OIDC_ISSUER is set, OIDC_AUDIENCE must also be set or the server refuses to start (it previously warned and accepted any audience). Without an audience check the verifier accepts any token signed by the issuer — including one minted for a different app on a shared issuer (e.g. another Entra application in the same tenant), a token-confusion / confused-deputy risk (RFC 9700). The prior permissive behavior is still reachable, but only via the new explicit OIDC_ALLOW_ANY_AUDIENCE=true opt-out (logged loudly at every start). Action: OIDC deployments without OIDC_AUDIENCE must add it (or the opt-out) before upgrading.

Security

• Bump form-data 4.0.5 → 4.0.6 to patch a HIGH-severity CRLF injection advisory (GHSA-hmw2-7cc7-3qxx), pulled in transitively via arc-1 → @sap-cloud-sdk/connectivity → axios. npm audit now reports 0 vulnerabilities.

📦 Published to npm as @lisa-mcp/arc1-extension@0.3.1.

npm install @lisa-mcp/arc1-extension@0.3.1

See CHANGELOG.md for details.

Added

• TranslateSetTexts per-entry selectors — each texts item may now carry its own field_name/position, overriding the top-level selectors for that entry. All fields of one data_definition/metadata_extension (e.g. every ui_lineitem_label across fields) can be written in a single call.
• The ABAP handler groups entries by field and writes each group under one transport change scenario, so the object is enqueued/locked only once per request instead of once per field — fixing the lock collisions seen when translating field-by-field.

Both handler variants (zcl_i18n_service on-prem and zcl_i18n_service_cloud) are updated. Backward compatible: entries without their own field_name/position fall back to the top-level selectors.

Full changelog: https://github.com/ClementRingot/LISA/compare/v0.2.0...v0.3.0

Added

• Unit test suite (Vitest, 68 tests) over the security-critical pure modules: OAuth state codec, stateless DCR store, redirect-URI allowlist/validation, tool schemas, config parsing, chained token verifier.
• npm test / npm run test:watch + vitest.config.ts.
• CI workflow (lint + test + build) on push/PR.
• ABAP service sources (abap/) and long-form docs (docs_page/).

Changed

• API-key auth now uses constant-time comparison (hash + timingSafeEqual) instead of ===.
• OIDC verifier warns when OIDC_AUDIENCE is unset (audience then not validated).
• Centralised the server version; tool descriptions sourced from the TOOLS registry.
• Corrected stale doc comments; lint is now clean.

Full changelog: https://github.com/ClementRingot/sap-translator/compare/v0.1.0...v0.2.0

Fixed

• cds_entity is now advertised in the tool descriptions automatically. supportedTargetTypesNote() injects the synthetic cds_entity target into an action's advertised target_type list whenever both physical owners (data_definition + metadata_extension) are in the handler's allow-list for that action. Previously the backend allow-list never mentioned cds_entity (it's a LISA-only virtual target the MCP fans out before reaching SAP), so an agent could wrongly conclude it was unsupported. This is read/write-symmetric and works on any handler without each ABAP variant hardcoding the virtual type.

Added

• SAP_BTP_PP_DESTINATION alone is now a valid startup configuration. For a pure principal-propagation backend (S/4HANA Public Cloud, or the same-subaccount BTP ABAP path) the technical SAP_BTP_DESTINATION is no longer required — resolveConfig() accepts SAP_BTP_DESTINATION or SAP_BTP_PP_DESTINATION or SAP_URL, and the BTP transport enters the per-user branch on either destination. Non-JWT (stdio / API-key / system-level) calls still need SAP_BTP_DESTINATION and now fail with an explicit message when it's absent. Matches ARC-1, which needs only its PP destination for this case. Covered by a new config.test.ts case.

Changed

• CLOUD ABAP handler renamed ZCL_I18N_SERVICE_CLOUD → ZCL_I18N_SERVICE. All three platform variants now share the class name ZCL_I18N_SERVICE and are separated by folder only (abap/ABAP_PLATFORM_2022/, abap/ABAP_PLATFORM_2025/, abap/CLOUD/). Renamed the abap/CLOUD/ source files to match and updated all docs.
• BTP ABAP Environment docs: added the same-subaccount OAuth2UserTokenExchange path as the recommended option (XSUAA→XSUAA, no Communication Arrangement / SAML trust / OAuth client registration — values come from the ABAP service key uaa section), with OAuth2SAMLBearerAssertion reframed as the different-subaccount / advanced case. Fixed the token-endpoint guidance (XSUAA uaa.url/oauth/token for UserTokenExchange/ClientCredentials vs. the ABAP host only for SAML-bearer) and documented instance-level destination init_data.
• S/4HANA Cloud Public Edition docs: stated SAMLAssertion principal propagation is the only supported developer path, added the SAML trust setup steps, BAS destination reuse, the full destination property set (default JDK truststore, BAS hint properties), and a verification/troubleshooting block.
• Clarified ABAP Cloud service exposure: on ABAP Environment the zi18n_service HTTP endpoint activates automatically when the HTTP Service object is activated — no communication scenario/arrangement is needed (corrected across the ABAP setup docs).
• mta.yaml: lisa-logs and lisa-connectivity now ship active: false by default. Application Logging hard-fails deploys where SAP retired the service (Note 3557260; LISA logs to stderr regardless), and Connectivity is only needed for the on-premise Cloud Connector path (the on-premise template re-activates it).
• DCR: documented SAP_OAUTH_DCR_TTL_SECONDS=0 for clients that don't auto-re-register (Eclipse Copilot, Cursor), matching ARC-1's ARC1_OAUTH_DCR_TTL_SECONDS=0 guidance.

Added

• S/4HANA Public Cloud per-user auth (SAMLAssertion). When SAP_BTP_PP_DESTINATION points at a SAMLAssertion / ProxyType=Internet destination, the BTP transport now detects the samlAssertionAuthorization token from the Destination Service and forwards it as Authorization: SAML2.0 … with x-sap-security-session: create, routing directly over the internet (no Cloud Connector). Reuses the existing PP env var — no new configuration. Mirrors ARC-1 (arc-mcp/arc-1#524). Requires @arc-mcp/xsuaa-auth ≥ 0.1.4.

• Per-landscape .mtaext templates per backend. Added mta-overrides-onpremise, mta-overrides-btp-abap and mta-overrides-public-cloud .mtaext.example files, plus a backend matrix in btp-deployment.md. The SAP BTP ABAP Environment (Steampunk, OAuth2SAMLBearerAssertion → Bearer token) was already supported by the existing bearerToken path — now documented.

Changed

• Bumped @arc-mcp/xsuaa-auth to ^0.1.4.

— Full changes in CHANGELOG.md. Compare: https://github.com/ClementRingot/LISA/compare/v0.8.1...v0.8.2

Added

• text_table target_type. Translate text tables (delivery-class C/S DB tables with one LANG key field, e.g. T005T) through the existing three tools. Adds two params: language_key_field_name (the LANG key field, e.g. SPRAS) and master_key_fields ([{ name, value }] pinning one record). Each texts entry's attribute is a text column name (e.g. LANDX). Served on all three stacks and advertised via capabilities. See docs_page/text-table.md.

Changed

• ABAP handler split into per-platform folders. abap/ABAP_PLATFORM_2022/ and abap/ABAP_PLATFORM_2025/ (both ZCL_I18N_SERVICE, on-premise / private cloud) and abap/CLOUD/ (ZCL_I18N_SERVICE_CLOUD, BTP ABAP Environment) — pick the folder for your platform. Same wire contract; they differ only in the XCO i18n API surface available on each release.
• cds_entity description scoped to one entity. Clarified that cds_entity covers the named entity and its own DDLX only and does not reach the underlying/parent views of an as projection on chain (e.g. the ZI_ interface view behind a ZC_ projection) — a RAP stack needs one cds_entity pass per distinct entity. No behavior change.

Removed

• Dead get_translation / compare_translations actions. The ABAP handler no longer exposes them (the MCP surface stopped using them — list_texts is the whole-object reader); their mentions are dropped from the wire contract and docs.

Added — Merged CDS entity translation surface (cds_entity)

A new virtual, LISA-only target_type (not a backend type) that treats a CDS view and its metadata extension (DDLX) as one translation surface, fanned out to the two real backend targets.

Read — TranslateGetTexts(target_type: "cds_entity") issues both backend reads (data_definition and metadata_extension), concatenates them (view first), and returns each row carrying the owner the ABAP backend stamps ("data_definition" / "metadata_extension") — read from the row, never derived. DDLX labels are included automatically (no second call). Rows are not deduplicated across owners. Positional UI labels stay as the bare attribute plus a separate position (1-based). If one sub-read fails, the successful rows are still returned with the failure attached under errors (partial success).

Write — TranslateSetTexts(target_type: "cds_entity") groups rows by owner and writes each group to its physical object in one backend call (each locked/transported once). Every row must carry owner — a write with any row missing it is rejected (LISA never guesses). Entity-level texts go out with an empty field_name (fixes the ENDUSERTEXT.LABEL error from an inherited field_name). Writes are not atomic across the two objects: the result reports per-owner { written, success, error? }, and a partial write returns success: false.

The single-object data_definition / metadata_extension (and all non-CDS) targets are unchanged — one 1:1 backend call. Logic is shared in @lisa/core, so the standalone MCP server and the ARC-1 extension behave identically. Includes the coupled ABAP backend change (classic + cloud) that stamps owner on every CDS list_texts row.

Full changelog: https://github.com/ClementRingot/LISA/blob/v0.8.0/CHANGELOG.md

Fixed

• Docs: ARC-1 extension marked as shipped. The roadmap index (roadmap/README.md) and the arc1-extension.md banner/title still said "Planned" / "waiting for v2", and the main README's roadmap row said "Shipped" without a version. All now read ✅ Shipped in v0.7.0, matching the released packages/arc1-extension.

Added

LISA as an ARC-1 extension — a second distribution (lisa-arc1-extension) packages the same three tools as in-process ARC-1 plugins (Custom_TranslateListLanguages, Custom_TranslateGetTexts, Custom_TranslateSetTexts) loaded via ARC1_PLUGINS. It reuses the host ARC-1's authenticated SAP client, safety ceiling, scope policy, audit, and per-user principal propagation — no second auth stack and no second URL. The standalone server and the extension share one wire contract (@lisa/core) and one ABAP handler. See docs: ARC-1 extension deployment.
Startup warning when LISA_DCR_SIGNING_SECRET is set but no XSUAA binding is present — the secret is only consumed by the XSUAA OAuth proxy, so this surfaces a dead-config misconfig instead of ignoring it silently (parity with ARC-1's set-but-unused signing-secret warn).
Reproducible release tooling: npm run release <version> (scripts/release.sh) bumps the synced version fields, rolls the CHANGELOG, build/lint/tests, and stages a commit + annotated tag; a version-sync guard (scripts/check-version-sync.mjs, wired into CI as check:version) fails the build if the product version or the extension version drifts across the files that carry it. Documented in docs: releasing.
Dependabot for the npm workspaces, the Docker base image, and the GitHub Actions, with grouped weekly PRs (arc-1/@arc-mcp/* kept in their own group).

Changed

Restructured into an npm-workspaces monorepo: @lisa/core (the transport-agnostic wire contract + Zod schemas shared by both consumers), packages/server (the existing standalone BTP server, now consuming @lisa/core and bundled with esbuild so the deploy artifact carries no workspace symlinks), and packages/arc1-extension. No behavior change to the standalone server; the deployable surface and the 3 tools are unchanged.
README now presents the standalone server and the ARC-1 extension as two first-class deployment paths (Part 2 / Part 3) instead of mentioning the extension only in passing.
arc-1 extension: pin the arc-1 dependency to >=0.9.20 — the version that ships the gated ctx.http.post (raw write surface) the extension's transport calls (dev floor ^0.9.20, peer floor >=0.9.20, so an older host is flagged rather than failing at runtime on a missing post).
DCR client_id prefix changed sapt- → lisa- (the prior prefix was an undocumented acronym; lisa- is self-documenting and traceable in XSUAA/logs). Changing the prefix re-issues DCR client_ids: already-registered MCP clients re-register automatically on their next sign-in — one-time, transparent, no migration needed since the DCR store is stateless/HMAC.
Bumped zod to v4 across all packages (arc-1 peer-depends on zod ^4; the MCP SDK supports both 3.25+ and 4 — usage was already a compatible subset).
Docs: aligned the LISA_DCR_SIGNING_SECRET generation command across README / BTP deployment / mtaext template on openssl rand -base64 48 (the value @arc-mcp/xsuaa-auth recommends).

Added

• LISA now probes the connected ABAP backend's per-action capabilities allow-list once at startup (process-cached) and injects the concrete supported target_type list into the TranslateGetTexts (list_texts) and TranslateSetTexts (set_translation) tool descriptions. The assistant knows up-front which object types the target system accepts, instead of only learning reactively on rejection.
• I18nClient.getCapabilities() exposes the allow-list to the tool layer.

Changed

• The generic stack-differences caveat is now a fallback only (older handler / SAP unreachable); when the live list is available it is replaced by the concrete per-operation set.
• target_type enum description trimmed (stack prose moved to the per-tool, per-system note).
• README: clarifies the object-types table is the full catalog; the real set is per-system and stated in each tool description.

Also includes: fix(abap) — ISO language codes converted to SAP SPRAS (no more RO→RU).

🤖 Generated with Claude Code

Wording follow-up to v0.5.0 (the per-stack capability guard).

• The target_type tool description now also notes that supported object types can differ between on-premise / private cloud systems depending on the system version (not only between cloud and on-prem).
• Removed speculative "future per-release class (zcl_i18n_service_2022 / _2025)" wording from the tool description, i18n-client, abap/README, and both ABAP handlers.

No behaviour change; capability guard still degrades to permissive until the ABAP capabilities action is imported.

🤖 Generated with Claude Code

Each ABAP handler now declares the object types it can translate (an editable allow-list), and the MCP server enforces it up-front — instead of surfacing a raw error after the call.

Highlights

• ABAP capabilities action (both handlers) returns { list_texts: [target_type…], set_translation: [target_type…] }. One object type per line → removing a possibility is a one-line edit. Cloud omits text_pool from list_texts only (writable but not listable with the released APIs).
• Capabilities differ by stack (public cloud / BTP ABAP Environment vs on-premise / private cloud) and by system release — a future per-release class (e.g. zcl_i18n_service_2022 / _2025) just declares its own list, no server change.
• LISA probes capabilities once (cached) and rejects an unsupported target_type up-front (isTargetTypeSupported). Older handlers without the action degrade gracefully to permissive — the CLOUD_UNSUPPORTED backstop still fires.
• N2: CLOUD_UNSUPPORTED mapped to a clear message; stack/release differences documented in the target_type tool description.

Validation / caveats

build / lint / 30 tests green; deployed to BTP DEV + SANDBOX (permissive). ⚠️ The ABAP changes need import into the target system(s) and live testing — they could not be compiled in this environment; until re-imported the server stays permissive.

🤖 Generated with Claude Code

Adopt the shared @arc-mcp/xsuaa-auth package, retiring LISA's in-tree XSUAA OAuth + DCR + OAuth-state + BTP modules (mirrors arc-1 #456). Net ~-2,100 LOC, behaviour preserved.

Highlights

• Auth + BTP connectivity now sourced from @arc-mcp/xsuaa-auth (incl. the public-PKCE fix, 0.1.2+).
• LISA keeps its own transport wiring, /oauth/callback handler, DCR signing secret, and 3-tool surface.
• Shared toPackageLogger() routes package auth + principal-propagation diagnostics into LISA's (redacted) log stream.
• Preserves LISA's redirect-uri allowlist, api-key:<profile> identity (timing-safe), optional OIDC audience, authenticate-only model.
• express 4 -> 5; MCP SDK floor ^1.18.2.
• New per-landscape deploy tooling: btp:deploy-dev / btp:deploy-sbx, gitignored mta-overrides*.mtaext, per-subaccount xsappname guidance.

Validation

build / lint / 26 tests green, plus a live BTP sandbox deploy (XSUAA OAuth + public-PKCE end-to-end). Code + security reviews clean.

PR: #2

🤖 Generated with Claude Code

Added

• TranslateSetTexts per-entry selectors — each texts item may now carry its own field_name/position, overriding the top-level selectors for that entry. All fields of one data_definition/metadata_extension (e.g. every ui_lineitem_label across fields) can be written in a single call.
• The ABAP handler groups entries by field and writes each group under one transport change scenario, so the object is enqueued/locked only once per request instead of once per field — fixing the lock collisions seen when translating field-by-field.

Both handler variants (zcl_i18n_service on-prem and zcl_i18n_service_cloud) are updated. Backward compatible: entries without their own field_name/position fall back to the top-level selectors.

Full changelog: https://github.com/ClementRingot/LISA/compare/v0.2.0...v0.3.0

Added

• Unit test suite (Vitest, 68 tests) over the security-critical pure modules: OAuth state codec, stateless DCR store, redirect-URI allowlist/validation, tool schemas, config parsing, chained token verifier.
• npm test / npm run test:watch + vitest.config.ts.
• CI workflow (lint + test + build) on push/PR.
• ABAP service sources (abap/) and long-form docs (docs_page/).

Changed

• API-key auth now uses constant-time comparison (hash + timingSafeEqual) instead of ===.
• OIDC verifier warns when OIDC_AUDIENCE is unset (audience then not validated).
• Centralised the server version; tool descriptions sourced from the TOOLS registry.
• Corrected stale doc comments; lint is now clean.

Full changelog: https://github.com/ClementRingot/sap-translator/compare/v0.1.0...v0.2.0

Initial SAP Translation MCP server.

Added

• 5 MCP tools (TranslateListLanguages, TranslateListTexts, TranslateGetTexts, TranslateSetTexts, TranslateCompare) over the ZCL_I18N_SERVICE ABAP HTTP service.
• XSUAA OAuth proxy (stateless DCR + signed callback state), OIDC and API-key auth.
• BTP deployment (MTA), Destination + Connectivity (principal propagation).