fr0ster/mcp-abap-adt

The RFC transport on @mcp-abap-adt/connection 19 and @mcp-abap-adt/sap-rfc-lite 0.3.2, which compiles nothing on install: a platform without a prebuilt RFC binding no longer gets one from npm install. Migration: docs/MIGRATION-20.0.md. Over Streamable HTTP, state_handle is a declared argument of every tool, and a long session keeps one server instance and its SAP session across calls (#308).

BREAKING

• Dependencies: @mcp-abap-adt/connection ^19.0.0 (@mcp-abap-adt/lib, server-runtime) and @mcp-abap-adt/sap-rfc-lite ^0.3.2 (optional, lib). connection 19 changes no API: it moves its own RFC dependency to sap-rfc-lite ^0.3.2, so the tree holds one sap-rfc-lite, 0.3.2 — the one connection loads. sap-rfc-lite 0.3 has no install script and, from 0.3.2, ships no binding.gyp: npm install and npm ci compile and download nothing for it, also under --ignore-scripts and an npm that runs no unapproved install script. It carries a prebuilt binding for Linux x64 (glibc), Windows x64 and macOS ARM64, loaded at run time; its prebuilt bindings carry no path of the machine they were built on, so the RFC library is found by the operating system's loader. Windows with SAP GUI's 64-bit sapnwrfc.dll in System32 needs no SDK. On any other platform — Linux on ARM, an Intel Mac, Linux with musl (Alpine) — installing no longer builds the RFC binding (0.2.x compiled it with the SDK and a C++ toolchain): the server installs and serves HTTP as before, and RFC is refused with @mcp-abap-adt/sap-rfc-lite is not available until you build a binding from sap-rfc-lite's repository and install the package you built (its README, "Installation"; docs/MIGRATION-20.0.md). The documentation says so where it stated RFC's prerequisites — RFC Setup, Installation, the three platform guides, the package READMEs, Docker, the CLI options, the --help text and the package descriptions: no C++ toolchain and no SAPNWRFC_HOME before npm install; at run time the RFC library — SAP GUI's on Windows, else the SDK, its lib directory on PATH, LD_LIBRARY_PATH or DYLD_LIBRARY_PATH of the server process.

Added

• Streamable HTTP: state_handle is a declared argument of every tool (#308) on mcp-abap-adt-http, -http-ro, -compact-http and -compact-http-ro: an optional string, "The state_handle a long session, a lock or a batch answered: the call runs on the server instance that holds that state. Without it the call runs on a new instance." The pool already routed by a tools/call's state_handle argument, but only the debugger tools declared it, so a model, which sets no header, could not reach a lock taken with HandlerLock or an open batch. The debugger tools keep their own declaration, required where it was; a tool that does not use the argument gets it taken out of its arguments before its handler. The x-mcp-state-handle header still works and still wins when both are sent; a JSON-RPC batch carrying state_handle is still answered 400. The held-lock refusal and the descriptions of HandlerLock, HandlerUpdate, HandlerDelete, HandlerUnlock, HandlerBatch, BatchBegin, DebugBatchBegin and the compact debugger batch name the argument first, the header as the alternative. stdio and SSE register the schemas they registered before.
• Streamable HTTP: the long session (#308). SessionOpen / SessionClose (mcp-abap-adt-http, -http-ro) and HandlerSession with action: 'open' | 'close' (-compact-http, -compact-http-ro), read-only, served by no stdio or SSE binary. Open keeps an instance and its SAP connection and answers { state_handle }: every call carrying it runs on that instance, on its held SAP session — no new connection, no systeminformation lookup, no logoff between the calls; opened with the handle of an instance that already holds state, or of an open session, it answers that same handle and keeps what is held. Close answers { closed: true, held: { locks, batch, debug_session } }; once that answer is written the pool takes the instance out of its index and runs the instance close on it: every connection it owns logged off — which releases the locks taken in it — awaited to each logoff's write and its answer with no timer of the server's; an open batch and its answers dropped with nothing sent; the MCP server closed. From then on the handle answers state is not available at once; the shutdown awaits a close still running. Close without a handle or with an unknown one answers state is not available. A session never closed ends at the idle bound (--state-idle-minutes, default 30). In batch mode — a communication batch or a debugger batch — the session tools run at once and are never recorded: open leaves the batch open, close drops it. No list tool: the model keeps its handles; the handle is a bearer secret and the server does not identify the caller. Tool counts: mcp-abap-adt-http 256, -http-ro 71, -compact-http 39, -compact-http-ro 19 (on premise).
• The tool pages render the Streamable HTTP surface: docs/user-guide/AVAILABLE_TOOLS.md, AVAILABLE_TOOLS_READONLY.md, AVAILABLE_TOOLS_HIGH.md and compact/docs/AVAILABLE_TOOLS.md carry a "Streamable HTTP Binaries" section — the declared state_handle and the session tools, from the registration the HTTP server uses — listed in each page's navigation.
• MIGRATION-20.0, section "Streamable HTTP: held state by argument, and the long session": what a 19.x Streamable HTTP user sees change, and how to adopt the argument and the long session (nothing is required).

Changed

• The portable build takes sap-rfc-lite 0.3's binding as it is (npm run portable:build; PORTABLE.md). 0.3 reads its own package.json through a literal require, which the bundle inlines, so the bundle-time replacement of 0.2's run-time read, and the check that failed the build when that replacement did not happen, are gone. In their place the build refuses a stage holding any copy of sap-rfc-lite older than 0.3.0, naming each: such a copy cannot load inside an executable, and a package that pins an older range loads its own — so a version published before 20.0.0 (--version) is refused. On Linux the prebuilt binding carries no RUNPATH, and nothing beside it found the SDK (measured: ldd finds neither libsapnwrfc.so nor libsapucum.so in its folder): it now gets a RUNPATH of $ORIGIN in place of its SONAME entry, whose string becomes $ORIGIN — the binding is loaded by its path, never by that name, and an image whose SONAME string is shared with any other name is refused; a binding that does carry a RUNPATH has it rewritten as before. --build-from-source is gone: npm compiles nothing for sap-rfc-lite whatever it is told. Measured on Linux x64 with these packages packed before their release and staged together (one sap-rfc-lite, 0.3.2): both executables built, and npm run portable:smoke passes all 18 checks. Not run on Windows or macOS.
• Handles are unique among those the pool holds (#308): an instance's handle (128 bits from randomBytes) is drawn again when the value drawn is already held, at its creation and at every rotation, so two long sessions never share a handle or an instance.

Fixed

• The http and compact-http READMEs said another credential "retires" a held instance; it never did. A request carrying a handle with another credential (a renewed token, a new user and password) works on the held instance: its SAP session and its locks are kept and the new credential is put in force for its next sends (BaseMcpServer.getConnection); the connection is replaced only when SAP ended its session. The docs and a code comment now say so.

Security

The repository's own install, lockfile, workflows and image build; the packages' code and dependency ranges are unchanged by this section.

• The lockfile is refreshed within the declared ranges, under the 7-day release age below: among others @modelcontextprotocol/sdk 1.32.1, express 5.3.0, zod 4.6.7, dotenv 18.0.8, ws 8.22.0, undici 8.12.1, qs 6.16.1, xml-crypto 6.4.0, ts-jest 29.4.15; a few transitive packages resolve one release back (@napi-rs/keyring 2.1.1, jose 6.2.12, postcss 8.5.30), because their newest releases are younger than 7 days. npm audit finds nothing, dev dependencies included.
• overrides: js-yaml@^3 gets argparse ^2.0.1. Jest reaches js-yaml 3 through babel-plugin-istanbul → @istanbuljs/load-nyc-config, and js-yaml 3's argparse 1 brought sprintf-js (GHSA-hp3w-g68c-fv3c, moderate, no fixed release). js-yaml 3 uses argparse only in its command-line bin/js-yaml.js, which nothing here runs; load-nyc-config calls only .load(). The override replaces argparse 1 under js-yaml 3, and sprintf-js leaves the tree.
• @modelcontextprotocol/inspector is no longer a dev dependency, and with it the 131 packages only it pulled (vite among them). It served one .vscode/launch.json configuration, now removed; TESTING_AUTH runs the Inspector as the user's own command (npx @modelcontextprotocol/inspector …), outside the checkout.
• No dependency runs an install script. allowScripts in package.json denies the four that have one: esbuild (its postinstall checks or fetches the binary that its platform package, an optional dependency, already installs — the portable build's suites pass without it), @parcel/watcher (it compiles only when asked to build from source; its binary comes from its platform package), unrs-resolver (its postinstall fetches a binding only when the platform package is missing), and fsevents (macOS, its install runs node-gyp rebuild though the package ships its binary). .npmrc sets strict-allow-scripts=true, so a new dependency with an unreviewed install script fails the install instead of running it (measured: with esbuild left out of allowScripts, npm ci stops with ESTRICTALLOWSCRIPTS). npm reads these settings in full from 11.19.0; npm 10, bundled with Node.js 22, reads none — so CI and the release workflow install with npm ci --ignore-scripts — and install the packed tarballs, outside the checkout and its .npmrc, with --ignore-scripts too — and the from-source instructions (Installation and the three platform guides) say the same. .npmrc does not set ignore-scripts=true: it would also skip the packages' own prepublishOnly gate. docker/Dockerfile and docker/Dockerfile.inspect (the Glama reference image) install with --ignore-scripts too, and the portable build's two installs as well: no package of the production tree needs an install script, and the Glama image's one (tldjs, under mcp-proxy, which would refresh its public-suffix list from the network) is not needed — measured: the image built from core 19.2.0 answers --version, and mcp-proxy starts.
• New versions age before they are resolved (npm 11.19.0 and later): .npmrc sets min-release-age=7, except for the project's own @mcp-abap-adt/* scope, whose packages are released to each other the same day (min-release-age-exclude); their dependencies still wait the 7 days.
• Nothing calls npx, which fetches from the registry what it does not find installed: the scripts of the root and of the seventeen packages call biome and tsc from the installed dependencies, the pre-commit hook calls lint-staged, the workflows lint through npm run lint:check, and the suites that run a script through tsx start this Node with tsx's own CLI resolved from node_modules.
• CI and the release workflow gate on npm audit --audit-level=moderate: any known advisory of moderate severity or above fails the run, dev dependencies included — they run in CI and on every developer's machine. Every job has a timeout-minutes (45 for the test jobs, whose slowest cell takes about 21 minutes; 10 for the release job). src/__tests__/unit/ci/workflowInventory.test.ts holds the workflows, the package scripts, the git hook, allowScripts (one entry per dependency with an install script, each denied) and .npmrc to all of this; GitHub Actions says so.
• The release guide and the migration note say the same: RELEASE.md installs with npm ci --ignore-scripts (then npm run prepare for the hook) and its "What the workflows check" names the whole-tree audit at moderate, the --ignore-scripts installs, the job timeouts and the Glama reference image; MIGRATION-20.0, "Building from a checkout", says what a contributor installing this repository does now.

Changed

• Package listings with include_descriptions: true read the walk as single requests, several at a time, instead of ADT batch envelopes plus a metadata read per object — GetPackageContents, GetPackageTree and compact HandlerGet part contents, on any system. Inside one envelope SAP answers the node structure parts after the first with other parts' DESCRIPTION texts, so the batched walk could not use them and read every object's metadata instead; a node structure sent alone carries its own. Each description is now the node structure's own short description, the one the sequential path always answered — in the logon language; the metadata read answered adtcore:description in the object's master language, so on a system whose objects are mastered in another language the text changes language (measured: 1 057 of the 1 251 objects both describe). Measured on an on-premise system: a flat package of 2 033 objects 24.3 s → 1.2 s, a three-level package of 2 282 objects 36.2 s → 6.3 s; every description equal to the sequential read's, and objects of types the metadata read did not cover (about a third of that flat package) now carry theirs. Without descriptions nothing changes: one envelope per phase of each level.
• Dependencies: @mcp-abap-adt/adt-clients ^37.0.0, @mcp-abap-adt/adt-strategies ^0.15.0, @mcp-abap-adt/interfaces-adt ^20.1.0 (@mcp-abap-adt/lib; compact-modify for interfaces-adt). adt-clients 37's getSystemInformation answers present, absent (404 only) or failed; GetServiceBindingPreviewUrl reads it so: a 404 gives a URL without a client or language, as before, and any other status is reported beside the URL as system_information_failure (a 401 ends the call). A 405, a 501 or a 2xx that is not the record were read as absent before and are now reported as that failure. adt-strategies 0.14.0 refuses an answer to a message read that is no message class document (ADT_OBJECT_NOT_FOUND); GetMessageClassMessage answers that verdict. adt-strategies 0.15.0 adds analyseObjectProperties, which GetTransaction passes.
• A failure a reading raised on a 2xx answer carries raw_body only with detail: 'raw', for every tool. SAP did not refuse there: its body is an ordinary document, and the failure's message, code and messages already say what is wrong with it — measured: GetMessageClassMessage for a number its class does not hold answered 613,386 bytes, now 312. A refusal SAP made (any other status) carries raw_body at every detail, as before; nothing else in a failure changes. A tool without a detail parameter answers such a failure without the body.
• A new package, @mcp-abap-adt/server-runtime: the launch code of every server (#303). The stdio launcher, StdioServer and the destination layer (/stdio, /stdio/server, /auth), the Streamable HTTP launcher and server (/http, /http/server) and the HTTP+SSE launcher and server (/sse, /sse/server) moved there from @mcp-abap-adt/core, http and sse, unchanged. It has no command, and you never install it yourself: every server package depends on it and installs it. The release is eighteen packages; the twelve binaries, their names, options, tool sets and versions are unchanged.
• No server package depends on another (#303). The nine wrappers (compact, compact-ro, core-ro, compact-http, compact-http-ro, http-ro, compact-sse, compact-sse-ro, sse-ro) no longer depend on core, http or sse: each of the twelve binary packages depends on server-runtime, @mcp-abap-adt/lib, background-runs-memory, responsible-rules and its own compact halves. lib is in dependencies of the twelve binary packages only; server-runtime, compact-readonly-entries, compact-modify, background-runs-memory and responsible-rules take it as a peer dependency (and server-runtime takes background-runs-memory and responsible-rules the same way). An embedder that installs compact-readonly-entries (with or without lib) gets one lib as before: npm installs a missing peer.
• The eight Streamable HTTP and SSE server packages — http, compact-http, http-ro, compact-http-ro, sse, compact-sse, sse-ro, compact-sse-ro — now install @mcp-abap-adt/auth-broker, @mcp-abap-adt/auth-stores and @mcp-abap-adt/interfaces-auth-broker, through server-runtime, whose dependencies they are, for the stdio destination layer. None of them loads them: only the runtime's stdio paths reach them (dependencyRule.test.ts).
• @mcp-abap-adt/core (., /launcher, /auth), @mcp-abap-adt/http and @mcp-abap-adt/sse (., /launcher) keep their exports, as re-exports of server-runtime's paths. Their StdioServer, StreamableHttpServer and SseServer still answer their own package's version when constructed without one. Their launcher paths (@mcp-abap-adt/core/launcher, @mcp-abap-adt/http/launcher, @mcp-abap-adt/sse/launcher) take 19.1.0's options: main({ toolSet, program, version }) and launch(config, { toolSet, program, version }, deps) compile and run as before — packageName, the package a second copy of lib asks to reinstall, is optional there and defaults to that path's own package; a value given passes through. On server-runtime's own paths (/stdio, /http, /sse) packageName is required.

Fixed

• GetTableContents (and compact HandlerGetData with object_name) answers the rows asked for and the table's true row count (#302). It read /sap/bc/adt/datapreview/ddic?rowNumber=N, which, measured on an on-premise system (BASIS 816), answers N+1 rows and totalRows 0 — a table of four rows asked for two answered three and total_rows: 0. It now reads the freestyle preview (/sap/bc/adt/datapreview/freestyle?rowNumber=N, as GetSqlQuery does) with SELECT * FROM <table>, which answers at most N rows and the true total_rows (measured: the same table, two asked → two rows, total_rows 4). The answer's shape and detail levels are unchanged; row_number is the max_rows asked.
• GetMessageClassMessage answers the one message, not the whole class (#302). ADT answers a message read with the class document, every message in it (measured: 613,165 bytes for one message of a class of 900), and the tool handed that document on under metadata. It now reads the message numbered msgno out of that one answer and answers its fields under message — msgno, msgtext, selfexplainatory, documented, lastchangedby, lastmodified, name and any other the system gives the message (measured: 280 bytes). New detail parameter: full adds the message element as parsed, its links included; raw answers the class document as SAP sent it. A number absent from the class is still refused (ADT_OBJECT_NOT_FOUND). The answer's shape changed: message replaces metadata and part, and detail: 'raw' gives the class document as SAP sent it.
• GetTransaction reads the transaction (#302): it answered {"message":"Not implemented"} as a success. It now reads the transaction's object properties in one request (getUtils().getObjectProperties of /sap/bc/adt/vit/wb/object_type/trant/object_name/<name>) and answers the transaction under object (name, text, type, package, …) and its facets under properties in the system's order — application component chain, package chain, type, owner, language, creation and the rest, each with facet, name, displayName and, where given, text (measured on premise: 200, 22 facets). New detail parameter: full adds the document's parse, raw the document. The read passes analyseObjectProperties (adt-strategies 0.15.0): a 200 that is no object properties document holding the object (an empty body, a sign-in page, a truncated document) is refused ADT_OBJECT_NOT_FOUND. A name the system does not know is SAP's refusal as it came (measured: 422, ExceptionUnprocessableEntity). It no longer promises the program, screen or authorization object.
• A wrapper installed together with its former base loaded two copies of @mcp-abap-adt/lib, and its tool calls were refused (#303). With 19.1.0, installing a wrapper and its base globally in one command (npm install -g @mcp-abap-adt/core @mcp-abap-adt/compact, likewise http with http-ro, sse with compact-sse-ro, …) put the base at the global root with its own lib: the server entered a request in one copy and the handlers read the other, so no request state was shared (measured for compact + core, http-ro + http, compact-sse-ro + sse), and a compact create was refused with system_context_missing. What made the second copy was one binary package depending on another; 19.2.0 has no such dependency. Measured with the packed release, every layout loads one copy and shares the request state: global, a wrapper with its base in one command or in two (either order); local, hoisted and --install-strategy=nested; a runtime at a later patch than the binary; an embedder's compact-readonly-entries with lib. A second copy now stops the start, before any parameter is read — --version and --help included — with exit 1 and one line on stderr: Two copies of @mcp-abap-adt/lib are loaded in this process (<file>, <file>): reinstall <package> (npm install -g <package>). (lib itself refuses nothing, so an embedder sees no change.) If you installed a wrapper and its base in one command before 19.2.0, update both to 19.2.0 — in one command (npm install -g @mcp-abap-adt/core @mcp-abap-adt/compact) or each on its own: measured, both layouts load one copy on 19.2.0.
• The portable build builds again, and its smoke check checks what it exists to check (npm run portable:build, npm run portable:smoke; PORTABLE.md). With @mcp-abap-adt/sap-rfc-lite 0.2.3 and later the build stopped at the RFC addon was not built: the package installs a prebuilt binding under prebuilds/<platform>-<arch>/ and compiles nothing, and the build looked only for a compiled build/Release/sapnwrfc.node. It now takes the binding the package's own loader resolves (a compiled one first, else the prebuilt), rewrites whatever library search path it carries to its own folder, and keeps --build-from-source for a compile against your SDK; no C++ toolchain is needed otherwise. Inside the executable sap-rfc-lite's run-time read of its own package.json failed, so no RFC call could load the stack; its version is now fixed at build time, as core's is. The smoke's MCP and RFC checks failed since 19.0.0, whose stdio logs on at its start: MCP initialize and tools/list now run in inspection-only mode (no destination, nothing connected; the compact server's count is no longer a fixed 25), and the RFC check reads the start against a host that does not resolve, which must stop at the RFC logon naming its key (RFC_COMMUNICATION_FAILURE) — a module or SDK that does not load reads could not be connected at start: Error. Measured on Linux x64 with the published 19.1.0 (--version=19.1.0; 19.2.0 is not on npm yet): both executables built from the prebuilt binding and every check passed; with the SDK library taken out of nwrfcsdk/lib the RFC check failed. Not run on Windows or macOS.

Changed

• Package listings answer no descriptions unless asked: include_descriptions defaults to false in GetPackageContents, GetPackageTree and compact HandlerGet part contents, which takes the parameter now (#300). GetObjectInfo takes include_descriptions too (default false): its leaves carry a description only when true, on the batched path from each leaf's metadata as before; enrich (the search for each node's description and package) is unchanged. Whether to pay for the descriptions is the consumer's choice; by default the server answers the fastest listing. With include_descriptions: true, on a destination that serves ADT batch, each description is read from the object's metadata, one read per object, in one more envelope after the walk: measured on an on-premise system, about 23 s for a flat package of 2 033 objects whose walk alone takes about 1.5 s. Without a communication batch the node structures are asked with descriptions only when true. Migration: a consumer that relied on the descriptions — of package objects or of GetObjectInfo's leaves — passes include_descriptions: true.

Fixed

• include_descriptions: false no longer reads object metadata on the batched path of GetPackageContents and GetPackageTree: the metadata pass ran for descriptions the answer did not carry. Inside one envelope SAP answers almost every node structure part after the first with other parts' DESCRIPTION texts (measured: 2 023 of 2 033 objects of one package), so those parts' descriptions stay unused and the descriptions come from the metadata.

The server split by transport and tool set into packages of their own — seventeen packages, twelve binaries — on the 6.0 auth chain (auth-broker 5, auth-providers 6, auth-stores 5) and the removal chain (connection 18, interfaces-adt-connection 3, interfaces-adt 20, adt-clients 36): the system type required, the low set gone, a logoff at every session end, no cancellation of a started tool. Migration: docs/MIGRATION-19.0.md.

BREAKING

• A package per transport and tool set; the binary fixes both. @mcp-abap-adt/core (mcp-abap-adt) serves stdio only; Streamable HTTP is @mcp-abap-adt/http (mcp-abap-adt-http), HTTP+SSE @mcp-abap-adt/sse (mcp-abap-adt-sse); the compact tool set is @mcp-abap-adt/compact, compact-http and compact-sse; the read-only sets are @mcp-abap-adt/core-ro, http-ro, sse-ro, compact-ro, compact-http-ro and compact-sse-ro (bins mcp-abap-adt-ro, -http-ro, -sse-ro, -compact-ro, -compact-http-ro, -compact-sse-ro). Publish order: RELEASE.md.
• --transport is gone (and MCP_TRANSPORT, YAML transport): any value stops every binary at start, naming the binary to run. --exposition is gone (either spelling, YAML exposition, compact's ro / rw): passing it stops the start with one sentence per word naming the package that serves what was asked. The debugger is no longer opt-in: every write binary serves it; the -ro binaries serve no debugger, no background run and no high tool.
• Each binary reads only its own parameters: another binary's option stops the start in its CLI and YAML forms, naming the binary that serves it; its environment variable is not read. Values are checked in every form (a bad port or flag is refused at start; TLS needs --tls-cert and --tls-key together). A config file that mixes transport, mcp, http: and sse: keys is refused by every binary.
• The system type is required (--system-type, SAP_SYSTEM_TYPE, YAML system-type: onprem, cloud, legacy): no default, never guessed from the credential (a jwt destination is no longer taken for cloud) or the URL. A stdio destination does not start without it, nor does a Streamable HTTP or SSE binary (exit 1 before anything listens). Inspection-only stdio needs none and filters no tool. system_type_required is new.
• The low set is gone from mcp-abap-adt, -http and -sse (112 tools, the *Low reads of the system group included): use the compact binary of the transport, which does what the low set did, a step at a time; the migration note maps every low tool to its compact call. LowLevelHandlersGroup, HandlerExporter's includeLowLevel and the 'low' handler set are gone from lib.
• HTTP and SSE take credentials only from the x-sap-* headers — of each request (Streamable HTTP), of the GET that opens each SSE connection (SSE). No destination, no broker, no store, no login over HTTP or SSE: x-mcp-destination is answered 400, --allow-destination-header and the default destination are gone, and the service-keys / sessions mounts are not read.
• stdio no longer serves jwt / none (a token you hold): such a destination stops the start, with the hint to send the token in x-sap-jwt-token to mcp-abap-adt-http / -sse, or to create the session with mcp-auth. stdio serves basic, snc and jwt / authorization_code.
• Only the chain's own session format is read (auth-stores 5): a session record of an older format stops the start, naming the destination, with the mcp-auth command that regenerates it. Removing SAP_ISSUED_* is no longer a remedy.
• stdio connects at its start, before the MCP transport opens — the startup check builds the credential, the interactive login happens then, the system information is asked — and any start failure ends the process with exit 1. A shutdown during the start exits 1.
• The responsible person, the user and the system are asked of the system (systeminformation) once per destination, when its connection is created, on-premise and on ABAP Cloud alike, and the system's answer wins over anything configured. On-premise, when the system gives no information, the responsible if stated, else the login, else system_user_unknown; on ABAP Cloud no information is an error (cloud_without_systeminformation for a 404, else system_lookup_failed). A 401 is answered as it came. These rules are @mcp-abap-adt/responsible-rules, which the servers pass; lib applies none: an embedder looks nothing up and requires no system kind unless it passes the resolver and the rules.
• A tool call cannot be cancelled. A client's cancel aborts nothing: the call runs to its end, its tool once. The client's close (stdio's stdin, an SSE stream) and the process shutdown log off every ADT session at once and interrupt the running tools — nothing waits for a running tool, no state undo is sent — then exit; 18.x waited up to 30 s. Over Streamable HTTP a dropped request closes nothing: the instance ends after its work, or at its state's stop or the idle bound. A crash outside a tool runs the forced close too.
• An instance's calls on its connection run one at a time, and only LOCK and UNLOCK are sent stateful: writes under a lock and activation go stateless. The session_id / session_state parameters and GetSession are gone; HandlerLock answers no session_id.
• A tool's failure is the method's error as it is, plus the step where it arose; a method's own throw is client_threw, never SAP's answer; a SAP refusal is no longer turned into an empty result, null or "not found"; tools reading several items carry each item's failure, and a 401 ends the whole call.
• No deadline of the server's or the libraries': SAP_TIMEOUT_* are not read; no login timeout (it was 30 s; --login-timeout is the opt-in bound) and no shutdown deadline (--shutdown-timeout, no default).
• RuntimeRunClassWithProfiling and RuntimeRunProgramWithProfiling are deleted: RuntimeRunClass / RuntimeRunProgram with profile: true. ResumeLeftoverSession does not exist: a stdio process takes up its destination's one leftover session at its start.
• @mcp-abap-adt/compact-readonly is renamed @mcp-abap-adt/compact-readonly-entries (the same exports).
• Docker: one image per binary (docker/Dockerfile, build argument VARIANT, context docker/); the 18.x image (--allow-destination-header over HTTP) is gone. Destinations are served by a stdio image only; every image needs the system type; compose publishes the listener ports on the host's loopback only.
• Embedders: lib's chain takes no request signal (IAbapRequestOptions.signal, IAdtClientOptions.signal, ADT_REQUEST_ABORTED and IAdtError.refusal are gone); AbapConnection answers unknown by default; on an injected connection an operation that needs an ABAP session of its own takes it only from freshConnection (called with no argument), and is refused without it; ConnectionContext replaces the destinations argument; AuthBrokerFactory, IDestinations and the destination layer moved to @mcp-abap-adt/core/auth; StreamableHttpServer and SseServer moved to @mcp-abap-adt/http / @mcp-abap-adt/sse; ServerConfigManager, ArgumentsParser, showHelp and the transport parsing left lib; makeAdtRequestWithTimeout, getTimeout, getTimeoutConfig, restoreSessionInConnection, describeAuthError and maskSensitiveValue are gone. The note lists every change of the public surface.

Added

• Tool search texts beside each description (#270, #271): every tool of every set carries keywords (for lexical search, BM25: the terms, synonyms and object kinds users ask with) and semantic (for vector search: what a user wants when the tool is the answer), from one table, tools/tool-search.json, shipped and bundled. tools/list carries them on each tool as _meta["mcp-abap-adt/search"]; lib exports them as @mcp-abap-adt/lib/tool-search (toolSearchText(name), toolSearchTexts()). A client that knows none of it reads description as before. Two labelled query sets, for a reader and a developer, are run by BM25 over name, parameters and keywords in every test run, and by vectors over semantic through a local Ollama where one answers: the tuning set (the #270 and #271 cases among them) finds every required tool within the top 10 read and top 5 write tools — a regression guard on those queries —, and the held-out set, never used to tune the texts, gets no worse than its recorded baseline. See docs/user-guide/TOOL_SEARCH.md.
• @mcp-abap-adt/lib/adt-headers: the server's ADT request-header machinery for embedders that call adt-clients members themselves — DEFAULT_ADT_HEADERS (the starting pair per operation, with AdtOperation / adtOperation), AdtHeaderPairs / AdtHeaderPort (the pairs a system named in a 406 / 415, kept per system and operation), adtSystemKey (the system key the server uses) and withAdtHeaders (a call with the system's pair, sent once more with the type SAP named). A 406 with T100 SADT_RESOURCE 037 names nothing and is not corrected. See docs/architecture/REQUEST_HEADERS.md.
• Background runs: background: true on RuntimeRunClass, RuntimeRunProgram and compact HandlerProfileRun — the run goes on an ABAP session of its own and the call answers a run_handle at once; GetBackgroundRun, ListBackgroundRuns, DiscardBackgroundRun (compact HandlerBackgroundRun*). Kept by @mcp-abap-adt/background-runs-memory (new), 16 per caller, in the process's memory; an embedder passes an IBackgroundRuns of its own.
• Leftover SAP sessions (stdio): a runtime file per HTTP session the server holds, deleted only once its logoff completed — written, and its flushGoodbye() settled (SAP answered it or its connection failed), never on the write alone; LogoffLeftoverSession deletes its file the same way — so a process killed from outside, or one the forced close ended before its logoffs were answered, leaves a record: the next start takes up the destination's one leftover session, and ListLeftoverSessions / LogoffLeftoverSession (compact HandlerLeftoverSession*) list and log off the rest, sending nothing to SAP to learn who calls. The files are bearer secrets (owner-only on Linux and macOS).
• A timeout on the approved long reads (GetWhereUsed, SearchObject, SearchSource, GetPackageContents, … — the list in the note; compact HandlerWhereUsed, HandlerSearch, …): seconds, no default; each runs stateless on an ABAP session of its own, logged off when it ends; when the timeout passes its session is logged off and the call answers timed_out: true.
• UpdatePackage and DeletePackage (high) for what UpdatePackageLow / DeletePackageLow did; DeletePackage asks the deletion check first.
• Compact as the low set's analogue: HandlerUpdate under a lock_handle, HandlerLock / HandlerUnlock for BEHAVIOR_IMPLEMENTATION, package create / update / delete / check, HandlerValidate and HandlerCheckRun for packages and function modules, source_code to check unsaved source, the creation parameters of a class (superclass, final, create_protected), HandlerGet's object_structure, node_structure and virtual_folders parts; HandlerTransportSortAndCompress, HandlerTransportMoveObjects and HandlerGet of a TRANSPORT; HandlerDeletionCheck (object_type, object_name), the one deletion-check request, SAP's verdict as it came (29 compact tools, 17 that change nothing).
• --renewal=refresh-then-login|refresh-only, --browser mapped by the platform (system, auto, chrome, edge, firefox, none, headless) and --browser-program, --login-timeout, --shutdown-timeout, --auth-debug (stdio, command line or YAML only).
• @mcp-abap-adt/responsible-rules (new): the servers' rules for the responsible, the user and the system, and the system type row.
• RFC through a message server and a logon group (stdio): SAP_MSHOST, SAP_MSSERV, SAP_SYSID, SAP_GROUP, SAP_SAPROUTER — also --mshost, --msserv, --sysid, --group, --saprouter and YAML mshost, msserv, sysid, group, saprouter, with --connection-type's precedence (the --env / --env-path .env joins the environment) — reach connection 18's SapConfig as configured. The server adds no default (group's PUBLIC is connection's) and checks nothing: mshost with neither msserv nor sysid is connection's refusal, naming both, as it came (a stdio start stops with its words). With mshost no RFC host or system number comes from the URL and SAP_SYSNR is not read. lib's getConfig() reads the five from the environment; the HTTP and SSE binaries refuse their CLI and YAML forms like every destination option. Implemented and unit-tested, not yet measured on a live system (as of 2026-10-20).
• Twelve MCP Registry entries, one per server package.
• Compact HandlerProfileSchedule: one POST /sap/bc/adt/runtime/traces/abaptraces/parameters with the profiling flags (all optional), answering { success, profiler_id }; a 2xx without a Location header is a failure with step: "schedule trace". Recorded in batch mode.
• Batch mode, in every binary (the -ro ones included) on every transport: BatchBegin, BatchEnd, BatchAnswers (compact: HandlerBatch with action: 'begin' | 'end' | 'answers'). While a batch is open each call none of whose requests depends on another's answer is recorded instead of sent, answers nothing and takes the next number (from 1, in the order made; one number per call, whatever it put into the batch); every other call is refused (batch_not_recordable, batch_no_timeout) and takes no number. A batch holds one kind of request — LOCK, UNLOCK or stateless, as its first recorded call decides — and a call of another kind is refused batch_other_kind (" is a request; this batch holds requests — record it in the next batch"), no number: each phase (create, lock, write, unlock, read back, activate; a unit-test run's start, status, result; a trace's schedule, then the run under it) is its own batch. BatchEnd (and HandlerBatch end) sends the recorded calls in one ADT batch envelope on the instance's connection with the credential in force then, holds that connection for the whole send, leaves batch mode whatever happens, splits SAP's answer by number into the map and answers { recorded, sent, received } — or its own error, with no map: the envelope's failure as it came, batch_parts_mismatch (" of parts came; the answers cannot be matched to the calls") or batch_unsplit ("the envelope's answer could not be split into the calls' parts"), every number of the batch then answering that error; nothing is retried or sent twice (a part answered 401, 406 or 415 is that call's answer). BatchAnswers (number or numbers) reads the map by number: a number's answer — the answer the tool gives outside batch mode for what SAP answered — is built by its handler when the number is first read (the numbers of one call in parallel) and kept, until the next BatchEnd replaces the map; a request the handler would send then is refused batch_ended. Only LOCK and UNLOCK go stateful, as adt-clients sends them. BatchBegin answers the instance's state_handle; over Streamable HTTP it travels in the x-mcp-state-handle request header on every call of the batch (the header first, else a tools/call's state_handle argument, as the debugger tools send it). Which calls are recorded is tools/batch-handlers.json (170 entries, listed in docs/user-guide/BATCH_MODE.md), and every tool's description ends with one sentence saying how it behaves in batch mode: recordable, recordable for the arguments it names, or run outside batch mode. --batch-keep-raw-parts (MCP_BATCH_KEEP_RAW_PARTS, YAML batch.keepRawParts, default off) keeps SAP's raw parts beside each answer. The instance's end (its client's close, the pool letting it go, the process shutdown) or the held state's idle bound drops an open batch: nothing recorded is sent, the map goes with it. An embedder gives each instance its owner (batch: new InstanceBatch({ keepRawParts })); without one the batch tools answer batch_mode_unavailable. New refusals: batch_mode_unavailable, batch_mode_on, batch_mode_other, batch_mode_off, batch_not_recordable, batch_other_kind, batch_no_timeout, batch_ended, batch_parts_mismatch, batch_unsplit.
• The debugger batch (full set DebugBatchBegin, DebugBatchEnd; compact HandlerDebugBatch with action: 'begin' | 'end' | 'answers'; no -ro binary): at an ABAP stop, step, step to line, stack, variables, child variables, stack position and setting a variable are recorded — one request each, a full-set step with no stack read after it — and the end sends them in one debugger batch envelope on the stop's connection, splits the answer into the map (its numbers read with BatchAnswers or HandlerDebugBatch answers, each built when read), ends the batch whatever happens and answers { recorded, sent, received } or its own error, as BatchEnd; the debug session's stop and view stay as they were. At an AMDP break the same batch records step over, continue and the data preview of a table variable — full set AmdpDebugStep, AmdpDebugGetTable; compact HandlerDebugStep / HandlerDebugMaintain of kind: 'amdp' — and the end sends them on the AMDP session's command connection; begin works on the ABAP stop when one is held, else on the AMDP break, and a batch records at its own stop only. Every other tool is refused while it is open. Begin needs an ABAP stop or an AMDP break; one batch of either kind at a time (batch_mode_on, batch_mode_other). See docs/user-guide/DEBUGGER.md.

Changed

• BatchEnd (and DebugBatchEnd, HandlerBatch / HandlerDebugBatch end) only sends, receives and splits; a number's answer is built when it is read. BatchEnd answers { recorded, sent, received } or its own error — the envelope's failure as it came, batch_parts_mismatch, batch_unsplit — and with its error there is no map: every number of that batch read answers the same error, a credential refusal and a failure before the envelope included. BatchAnswers resumes each asked number's handler with its parts, the numbers of one call in parallel, and keeps the answer, so a handler runs once; a handler never read is awaited by nothing and goes with its map. Over Streamable HTTP a HandlerLock read by number is held by the instance only while the SAP session its envelope went out on is still the instance's; a lock never read, or one of a lock batch whose BatchEnd failed, stays in SAP until that session's logoff, and an unlock never read leaves its handle in the instance's held locks after SAP unlocked it (a later write under it is sent and SAP refuses it; over Streamable HTTP the pooled instance stays held until it ends) — read every lock number and every unlock number before the next phase's BatchEnd.
• Tool descriptions state only what each tool does, its parameters and its result, in every set (full, -ro, compact, batch, debugger); the sentence appended for batch mode is one of "Recordable: …", "When …, recordable: …" or "Runs outside batch mode.", and descriptionsFunctional.test.ts holds every served description to the rule.
• Tool descriptions name the function on what the parameters name (#270, #271): "Reads the CDS view (or classic DDL view) named by ddl_name …", "Lists where the object named by object_name and object_type is used — a class, …, function module (BAPI included), … CDS DDL source …", "Removes the entry of the object named by object_name and object_type from the transport task named by transport_number …"; RuntimeListFeeds leads with the short dumps of a program, a user and a time range; the unit-test writers lead with the carrier and its ABAP Unit test classes. [read-only] means the tool changes no repository object (source, metadata, transports), as in the -ro binaries. Every such tool carries it (every Get<Type>, the Check<Type> syntax checks, the ATC status and findings, the local includes, compact's reads; the runtime reads, the background-run and leftover-session lists beside their [runtime] or [session], every debugger tool beside its [debug], the runs of code and tests (RuntimeRunClass, RuntimeRunProgram, Run…UnitTest, RunATC, compact's HandlerUnitTestRun and HandlerProfileRun), the trace scheduling, the background-run discard, the leftover-session logoff and the batch tools; only a tool that creates, updates, deletes, activates, locks, unlocks or edits a transport lacks it; GetPackageTree was [high-level]), no description names another tool (the Activate<Type>, version, transport, ATC, message-class and background-run tools did), and no first sentence is built around "an ABAP object". descriptionsFunctional.test.ts now also refuses another tool's name, a tool that changes no repository object, or a debugger tool, without [read-only], a first sentence two tools of a set share, and a vague subject in it.
• The auth chain: @mcp-abap-adt/auth-broker ^5.0.6, @mcp-abap-adt/auth-providers ^6.0.2, @mcp-abap-adt/auth-stores ^5.0.1, @mcp-abap-adt/auth-errors ^2.2.1, @mcp-abap-adt/interfaces-auth ^7.5.0, @mcp-abap-adt/interfaces-auth-sap ^3.4.0; only core depends on the broker and the stores. The ADT chain: @mcp-abap-adt/connection ^18.0.1, @mcp-abap-adt/interfaces-adt-connection ^3.0.0, @mcp-abap-adt/interfaces-adt ^20.0.0 (root and compact-modify), @mcp-abap-adt/adt-clients ^36.0.2, @mcp-abap-adt/adt-strategies ^0.13.0. adt-clients 32's two new result slots of the class, program, function group and include sets, enhancementElements and enhancementOptions, are read verbatim.
• @mcp-abap-adt/adt-clients ^36.0.2 (a credential refusal rethrown by every member; a batch corrects and resends nothing; an envelope that fails as a whole rejects every part with its one error, whose request is the envelope's own; the Accept and Content-Type of 32 members — create, update, delete, check, activate, the deletion check, the where-used, node structure and virtual folder reads, the data previews, the transport actions, the debugger's requests, the trace scheduling, abapGit's link and pull — are the caller's options.headers, and no request is negotiated, corrected or remembered; extractSupportedAccept / extractSupportedContentType read the types a 406 / 415 names — only SAP's list after Accepted content types: / Supported Media Types:, never the refusal's own content-type; since 36.0.2 three requests SAP refused are fixed, measured on premise: the enhancement's check sends the chkrun:checkObjectList document under Accept application/vnd.sap.adt.checkmessages+xml, Content-Type application/vnd.sap.adt.checkobjects+xml — application/vnd.sap.adt.checkrun.v1+xml as both was refused 415, and the server's default pair for it is the new one —, the feature toggle's validate sends Accept application/vnd.sap.as+xml, and the application log's getObject / getSource send Accept application/vnd.sap.adt.blues.v1+xml / application/json, where application/xml was refused 406), @mcp-abap-adt/connection ^18.0.1 (a session SAP replaced logs off the session that replaced it before its cookies are dropped), @mcp-abap-adt/sap-rfc-lite ^0.2.3 (prebuilds for Linux glibc and win32-x64), @mcp-abap-adt/interfaces-auth-sap ^3.4.0.
• A tool call that fails on authentication answers JSON (authentication_failed, destination_refused or one of the server's own refusals); no error's message reaches an answer or a log line, and the startup summary shows a secret by its presence only.
• A failed write to the --env / --env-path file fails the request; a named destination's failed write logs one stderr line whatever DEBUG_AUTH_LOG says.
• A function group create that SAP refuses 400 "Interface SAPL… has not been created" reads the group back and answers done when it is there (CreateFunctionGroup; compact HandlerCreate answers the 400 as it came — read the group with HandlerGet part metadata).
• Breaking for compact: HandlerCreate is one request — the POST of the type's adt-clients create() alone, for every type; no flag, no mode. It no longer validates, locks, writes, checks or activates, sends no service-group read for a service binding and no read-back after a function group's 400; the object is created inactive with what the create carries. Chain the rest as calls of their own: HandlerLock, HandlerUpdate with the lock_handle, HandlerUnlock, HandlerActivate. The schema lists only what some type's create sends: activate, fields, source_code, fixed_values and the other domain properties, test_class_source, cds_view_name, a class's abstract, a behavior definition's root_entity and a behavior implementation's behavior_definition are gone from it — their content goes in through HandlerUpdate under a lock, the activation through HandlerActivate; the schema now names the transport's transport_type, target_system, owner and the binding's service_name, service_version, binding_variant, which the create sends. UNIT_TEST and CDS_UNIT_TEST, whose create is a chain, are refused before sending: "HandlerCreate does not create : its create is a chain of requests, not one — use CreateUnitTest / CreateCdsUnitTest of the full set". Recorded in batch mode for every other type (a PACKAGE over HTTP only). The full sets' Create<Type> are unchanged.
• Breaking for compact: HandlerUpdate is one request under the caller's lock_handle, now required — the type's write alone: the PUT of the source, of the class include or of the metadata document, and for SERVICE_BINDING its publication request; no lock or unlock, check, activation, read before or after the write. PACKAGE, DOMAIN, DATA_ELEMENT and FUNCTION_GROUP take the whole metadata document in source_code and send it as given (read it with HandlerGet part metadata). activate, properties, super_package, description, the domain properties (datatype, length, decimals, conversion_exit, lowercase, sign_exists, value_table, fixed_values) and behavior_definition leave its schema; service_version joins it. Chain the rest as calls of their own: HandlerLock, HandlerUpdate, HandlerUnlock, HandlerActivate. HandlerLock and HandlerUnlock take SERVICE_DEFINITION and SERVICE_BINDING; a binding open in an editing session (its LOCK's 403) is a lock with an empty lock_handle, under which HandlerUpdate SERVICE_BINDING sends the publication. Over Streamable HTTP HandlerLock holds the lock as the pooled instance's state and answers its state_handle; HandlerUpdate and HandlerUnlock are refused, sending nothing, under a lock the instance they reach does not hold, and a request on the handle works on the instance's held connection with its own credential — a renewed token or a new basic pair is the same user, in the same SAP session, the locks kept; the connection is replaced only when SAP ended its session. Recorded in batch mode for every type (a PACKAGE over HTTP only). The full sets' Update<Type> are unchanged.
• Breaking for compact: HandlerDelete is one request — the deletion request alone, as adt-clients' delete() sends it, for every type it removes: no lock (a lock held on the object is what makes ADT refuse its deletion) and no deletion check, which is HandlerDeletionCheck now; the answer is SAP's, as it came. The class includes LOCAL_TEST_CLASS, LOCAL_TYPES, LOCAL_DEFINITIONS, LOCAL_MACROS and UNIT_TEST (a DELETE on an include answers 405, measured on premise) are written empty by one PUT under the caller's lock_handle, the class's lock (HandlerLock object_type: CLASS; over Streamable HTTP with its state_handle), with no lock or unlock of their own and no activation. CDS_UNIT_TEST deletes its test class. force_new_connection leaves its schema (compact locks and writes a package in an ABAP session of its own, so the call's session holds no saved package); lock_handle joins it. Chain the rest as calls of their own: HandlerDeletionCheck, then HandlerDelete; for an include HandlerLock, HandlerDelete, HandlerUnlock, HandlerActivate. Recorded in batch mode for every type (an include with its lock_handle), and HandlerDeletionCheck too. The full sets' Delete<Type> are unchanged.
• Breaking for compact: HandlerGet is one request per part — part: source (the default) the source alone, part: metadata the metadata document alone, each answered { part: "source", source } / { part: "metadata", metadata } beside the object's name, the class includes too (GetLocalTestClass, GetLocalTypes, GetLocalDefinitions, GetLocalMacros of the full binaries answer the same shape; their test_class_code, local_types_code, definitions_code, macros_code keys are gone). PACKAGE, DOMAIN, DATA_ELEMENT and FUNCTION_GROUP have no source: part: source, and a call with no part, is refused before anything is sent, naming the type's parts — read them with part: metadata. A FUNCTION_MODULE is read at the group its arguments name: function_module_name as GROUP|MODULE, or with function_group_name; two groups, none, or more than one | are refused before sending. node_structure of a package (DEVC/K) is one request: SAP's blank body (an empty package and a package that does not exist answer alike) is the empty listing with blank stating both readings — HandlerGet part: metadata of the package tells them apart; 18.x read the package itself. urls and contents are unchanged. Batch mode records node_structure of a package too, and no longer lists source for the four types without one.
• Breaking for compact: HandlerActivate starts a run and answers its id; HandlerGet reads the run. One object of CLASS, PROGRAM, INTERFACE, FUNCTION_GROUP, TABLE, STRUCTURE, DDL, DOMAIN, DATA_ELEMENT, BEHAVIOR_DEFINITION or METADATA_EXTENSION is activated as before, one request answering the verdict. Such an object is named by object_type, by its ADT code in object_adt_type, or as a one-entry objects[]. Every other call — objects[] of several objects or of a type the per-object activation does not map (a function module at its group), an object_adt_type of such a code, PACKAGE, SERVICE_DEFINITION, SERVICE_BINDING — is the one POST /sap/bc/adt/activation/runs, answered { run_id }: the run was accepted and has no verdict yet; a start SAP answers without a run id (no Location) is a failure with step: "start activation run", and nothing more is sent. 18.x then polled the run and read its results, answering accepted, run_status, activated and messages — up to six long-polling status reads a second apart, as read from 18.x's code, not measured. HandlerGet gains part: activation_status (GET /sap/bc/adt/activation/runs/{run_id}, answered { run_id, part, status, document }) and part: activation_results (GET /sap/bc/adt/activation/results/{run_id}, answered { run_id, part, messages, document }), by run_id, one request each, SAP's document as it came, on the instance's session and with no timeout (refused, like UNIT_TEST's); how often to ask is the caller's. All three are recorded in batch mode. The full sets' ActivateObjects is unchanged.
• Breaking for compact: HandlerProfileRun is one run request, under a profiler_id or plain. With profiler_id it sends the one POST /sap/bc/adt/oo/classrun/{name}?profilerId=… (a program: /sap/bc/adt/programs/programrun/{name}?profilerId=…) and answers { success, class_name | program_name, output, profile: { profiler_id } }; without it, the one plain run request, answered without profile; an empty profiler_id is refused before any request; a failure is the method's error with step: "run with profiler" (plain: "run class" / "run program"). profiling and the profiling flags (now HandlerProfileSchedule's) are gone from it, and trace_id from its answer. 18.x scheduled the trace and ran under it inside the call, and for a class read the trace feed before and searched it after — up to five reads, 2 s apart, as read from 18.x's code, not measured. The caller schedules (HandlerProfileSchedule), runs, and finds the trace with HandlerProfileList; see MIGRATION-19.0. Recorded in batch mode.
• Breaking for compact: a unit-test run's result is read once. HandlerUnitTestResult, HandlerCdsUnitTestResult and HandlerGet with object_type: UNIT_TEST / CDS_UNIT_TEST send the one GET /sap/bc/adt/abapunit/results/{run_id} and answer { success, run_id, run_result }, the result document SAP answered, parsed (detail: "raw": the document) — whatever SAP answers, a run that has not finished included; a finished run's result carries executionTime on each test method; a failure is the method's error with step: "read unit test result" (CDS: "read CDS unit test result"). Their descriptions say so: "Valid once the status is FINISHED; a finished run's result carries executionTime." 18.x read the status first inside the call — up to five long-polling status reads, back to back, the result only once one said FINISHED, as read from 18.x's code, not measured — and answered finished (with run_status and a message when the run had not finished; HandlerGet also run_status when it had); finished, message and HandlerGet's run_status are gone. The status is the caller's to read, as often as it chooses: HandlerUnitTestStatus / HandlerCdsUnitTestStatus, one status read, with long polling by default as before. All three are recorded in batch mode; HandlerGet with UNIT_TEST / CDS_UNIT_TEST still takes no timeout and runs on the instance's session. The full sets' GetUnitTestResult, GetCdsUnitTestResult, GetUnitTest and GetCdsUnitTest are unchanged.
• Breaking for compact: HandlerDumpList reads one page. It sends the one GET /sap/bc/adt/runtime/dumps (feed_type system_messages / gateway_errors: their feeds) with $top = top (1 to 100; top 101 is refused before any request, naming the cap) and to, and answers { success, feed_type, count, entries, next_to }, next_to the to of SAP's next link as it came. A failure is the method's error with step: "read dumps" ("read system messages", "read gateway errors"). The description says: "The next link's page starts at the boundary second, inclusive: entries of that second may repeat; match them by dump_id." (measured: the feed answers 100 at most, the next page starts at the boundary second and answered 11 entries for $top 10). 18.x took a top up to 1000 and read the pages inside the call, as read from 18.x's code, not measured; incomplete_second is gone. The consumer follows next_to as to and matches by dump_id. Recorded in batch mode. The full set's RuntimeListFeeds still reads the pages inside the call.
• Breaking for compact: the compact debugger is four tools, one request per call. HandlerDebugBreakpoints (ABAP setBreakpoints, syncBreakpoints, deleteBreakpoint, createWatchpoint, listWatchpoints, deleteWatchpoint; AMDP syncBreakpoints), HandlerDebugSession (ABAP checkListener, listen for exactly the caller's hold_seconds, stopListener, attach, detachDebugger — sent with no debuggee id on the attaching session, which releases the debuggee (measured 2026-10-17: with an id SAP answers 200 and releases nothing) —, terminateDebuggee, terminateDebugger, setDebuggerSettings; AMDP start, getEvents, stop, deleteDebuggee), HandlerDebugStep (ABAP stepInto, stepOver, stepReturn, stepContinue, stepRunToLine / stepJumpToLine with the line's address, now required, setStackPosition; AMDP stepOver, stepContinue) and HandlerDebugMaintain (ABAP getStack, getVariables, getChildVariables, getMemorySizes, createMemorySnapshot, setVariableValue; AMDP getDataPreview): kind and operation pick the one AbapDebugger / AmdpDebugger method each call sends; a failure is the method's error with the operation's step. HandlerDebugStart, HandlerDebugWait and HandlerDebugView are gone, and HandlerDebugStep's action with them. No listener polls in the background, no catch is attached for the caller, a step reads no stack (the step answer carries no position, measured 2026-10-17: read it with getStack), and only HandlerDebugSession end logs off: it takes the state_handle, logs off each connection the debug state opened and sends nothing else (measured 2026-10-17: an attached debuggee runs on, the AMDP debug session ends, the user's breakpoints stay set until removed with deleteBreakpoint or stopListener), and the state and its handle end with it, so a debug state of either kind and any identity can open after it. The full set's debugger tools are unchanged. Migration: one row per old tool.
• Breaking for the full binaries: one Get<Type> per type, with part; the Read<Type> tools are gone. A type with a source (class, interface, program, table, structure, DDL, service definition, service binding, behavior definition and implementation, metadata extension, function module, function include) is read by Get<Type> with part: "source" | "metadata" (default "source"): one ADT request per call, the answer carrying only the part asked for, in one shape for every type: { part: "source", source } or { part: "metadata", metadata } beside the name fields (the per-type keys source_code, <type>_data, payload, package, message_class, message are gone; compact HandlerGet answers the same). The metadata-only types (domain, data element, function group, package, message class and its message) keep Get<Type> without part and answer { part: "metadata", metadata }. GetFunctionModule reads at the function_group_name given, one request (it no longer reads the metadata first to check the group); GetProgram reads any program (ReadProgram's invalid_object_type refusal is gone); ReadFunctionInclude is GetFunctionInclude. The -ro binaries serve the Get<Type> tools, the same tools as mcp-abap-adt. Every Get<Type> call, both parts, and compact HandlerGet part: source | metadata of a FUNCTION_MODULE, is recorded in batch mode. ReadVsGetDedupStrategy is gone; EmbeddableMcpServer's readOnlyDedupStrategy defaults to NoDedupStrategy. Compact HandlerGet part: metadata reads the metadata document alone, one request. The note maps every removed Read<Type>.
• DeletePackage with force_new_connection no longer falls back to the current session.
• The enhancement reads go through adt-clients 32 (EnhancementType enhoxhb | enhoxhh | enhsxsb, SAP's codes ENHO/XHB, ENHO/XHH, ENHS/XSB, each subtype its own media type). GetEnhancements reads a host's elements with readEnhancementElements on the class, program, function group or include (an include's read names its main program, from its contextRef or program; a function group's SAPL<fg>), no longer a request of its own. GetEnhancementSpot reads with getEnhancement().readMetadata under enhsxsb's own application/vnd.sap.adt.enh.enhs.v2+xml — the shared application/vnd.sap.adt.enhancements.v1+xml it sent answered 406 (measured by adt-clients 32). GetEnhancementImpl reads a source code plugin with getEnhancement().read (enhancement_spot: "enhoxhh", Accept text/plain) and answers not_found when SAP answers no source; a BAdI spot (enhsxsb) is refused before any request, like a BAdI implementation, and a collection name that is none of these is refused without a request, after the repository search names what the object is when it can. A failed read is the method's error as it is with its step (read enhancements, read enhancement spot, read enhancement source); a 401 ends the call as it came, with no search.
• Since @mcp-abap-adt/adt-clients 33, a credential refused before SAP was asked rejects. Every member now rejects with connection's AuthRefusedError as it came, where it answered ok: false with the refusal's words (a credential SAP refused is a failure carrying SAP's 401). The server ends the call with it as authentication_failed wherever it read many objects or held a lock: nothing after it is requested — not the next include of GetEnhancements (nor an empty includes list for a refused walk), not the next SearchSource object, not the activation after a write's best-effort wait or its unlock; a locked write still tries its unlock, and a credential failure on the write, the unlock or the activation is the answer itself, never a cleanup entry or the held-lock wrapper. GetServiceBindingPreviewUrl ends on it in its system lookup instead of reporting the lookup failed and reading on.
• Every catchable end runs the orderly shutdown. Besides SIGTERM and SIGINT: SIGHUP (the terminal closed, an SSH session dropped; on Windows the console closed), SIGQUIT, on Windows SIGBREAK; on stdio a broken pipe (EPIPE) on stdin or stdout, taken as the client's end of input (exit 0); an emptied event loop (beforeExit). A crash outside a tool (an uncaught exception, an unhandled rejection) now runs the orderly shutdown too — every logoff let finish — and exits 1 (it ran the forced close before); a crash during a shutdown lets it finish. A second signal and --shutdown-timeout still force the end. SIGKILL, a crash of the runtime and a power loss cannot be handled: their sessions live until SAP's security-session timeout.
• The orderly end lets every logoff finish. The process's shutdown (stdio's end of input, a signal), a stdio start that fails after its logon (its exit 1, and a launch that rejects, which the binary's exit follows) and an instance's terminal close (the HTTP pool's eviction, an SSE close) follow every logoff written — at the end and by any site before — until SAP answered it or its transport failed (flushGoodbye(), no timer, the answer not read) before they resolve: SAP ends a security session and its user sessions only once it has received the logoff whole (measured 2026-10-19: logoffs sent right before the process ended left the sessions in SM05 until their timeout). The forced close still stops at the writes, so its sessions keep their runtime files, listed by ListLeftoverSessions of the next stdio process.
• A debug stop deletes the breakpoints before it lets a held debuggee run on, and a debugger's run goes on a stateless session. The ABAP stop sends the listener's stop — which deletes the breakpoints — first, then releases a held debuggee and any release an earlier stop left owed, so a continue from a breakpoint inside a loop runs to the end instead of stopping there again. When the listener's stop fails and a breakpoint's delete by id fails too, no held debuggee is released: each stays held for the next stop, a failure with its step (release the debuggee, release <what>) in fixed words. While a debuggee stays held (or owed a release, ABAP and AMDP alike), the run's connection stays open with it — its logoff would end the session held at the breakpoint — and the stop that releases the debuggee closes it after the release; the instance's close and the process's shutdown log it off whatever is held. The program run of DebugStartListener / AmdpDebugStart opens a stateless connection (measured 2026-10-17: a run on a stateless connection is caught and held as on a stateful one); the listener, the attach, the breakpoints' connection and the AMDP events and commands connections stay stateful, each request on them in its one ABAP session, each logged off by its own SAP_SESSIONID.
• Streamable HTTP: a tool call with an unknown or ended state handle is answered by the pool. state is not available, the same answer for every such handle, before any instance is made — no logon, no system-information read (measured 2026-10-19: such a call made a new instance that logged on and off). A JSON-RPC array holding a tool call with such a handle is answered the same, one answer per request in it with an id (202 and nothing when none has one). A request without a handle, or a protocol request (initialize, a list) carrying one, gets a new instance as before.
• A complete debugger stop ends the debugger batch's kept answers with the state. DebugStop, and an AmdpDebugStop that ends the whole debug state, let the answers of the last batch go when a debugger batch gave them, so the state's handle ends with the stop (state is not available afterwards, as for an unknown handle); a refused or incomplete stop keeps them, and a communication batch's answers keep their lifetime.
• An AMDP stop waits for the cancelled debuggee to end before it stops the session. AmdpDebugStop (and DebugStop's AMDP part) cancels a debuggee standing at a break, waits until the event read reports ON_WARNING, ON_EXECUTION_END or STOP and the run that called it has returned, then sends the stop and logs off (measured 2026-10-19: sent while the cancel was under way, the AMDP debugger's ABAP sessions and RFCs stayed until their timeout; sent after it, nothing stayed). No clock of its own, and it holds no other call: a second stop, the debug state's end (dispose, the instance's close, the shutdown) or the stop call's cancellation ends the wait, and the answer then names the debuggee that had not ended. A cancel SAP refuses sends no stop — the stop answers the refusal and the session stays for the next stop — except at the debug state's end.
• An AMDP stop that SAP accepted logs off every connection of the session, even when the breakpoint clear was refused. The refused clear is answered with its step as before; the clear is not sent again and nothing is kept open for it (SAP removes a breakpoint left behind on its own). A clear refused before a refused stop still stays for the next stop, with the stop.
• A credential failure ends a cleanup too, and a 401 SAP answered is one. The debugger's stop (and a start's cleanup, and the AMDP debugger's) sends no request after the credential was refused — no further breakpoint delete, release or stop: the refusal is the answer as it came with its step, and not_attempted names the steps left in fixed words; they stay for the next stop. A start whose reconciling stopListener the credential refused ends with it, nothing armed. A 401 on a locked write's unlock, or on CreateTransportTask's task type change, is the call's failure with its step, not a cleanup entry. GetInclude, GetObjectNodeFromCache and the enhancement type search (GetEnhancementImpl, GetEnhancementSpot) answer a refused credential as the credential failure instead of rewording it or reading on.
• The read tools that still answered a failure in words answer it in the shape of every other. GetInclude reads through adt-clients (getInclude, analyseException): SAP's refusal is the method's error as it is, no longer its message as text. GetTypeInfo, GetTransport and GetObjectNodeFromCache, which send a request no client method makes, read its failure as adt-clients reads one — status, adt_type, T100 messages, raw_body and the request sent — with the step (read domain … read structure, read transport request, read OBJECT_URI), no longer SAP's body or the error's message as text; GetObjectNodeFromCache fails the call with it instead of answering the node with "ERROR: …" as its object_uri_response. GetPackageContents answers a thrown credential refusal as authentication_failed (it was answered in its words) and a throw of its own as client_threw, as do GetIncludesList, GetAbapAST (step: "parse"), GetAbapSemanticAnalysis (step: "analyse") and GetAbapSystemSymbols outside its walk. A throw while GetAbapSystemSymbols resolves a symbol is that symbol's error (client_threw with its step), not systemInfo.error text, and a thrown credential failure ends the call. GetEnhancements' partial answer after a failed nested walk carries the failure as an entry (step: "list includes"). GetServiceBindingPreviewUrl carries its system lookup's failure as system_information_failure beside the URL (its note says so in fixed words; a 401 there ends the call), no longer its message inside a sentence; a 401 SAP answers to its service URL lookup ends the call with that lookup's error (step: "read service URL") instead of the composed URL answering. A credential failure ends the call before any further request: a 401 SAP answered to one of GetIncludesList's includes (it was listed in unreadable and the walk read on), DescribeByList's typed search (it searched again without the type), GetObjectInfo's enrichment search (the tree was read on).
• Every ADT session the server opens ends with a logoff — a request's instance, a pooled one at its state's end, a debugger's, a long read's, a background run's, a lock session's.
• Every flag row of the YAML configuration refuses a list or a map: [true] (or { … }) was accepted for a boolean option and is now refused at start like any other bad value.
• The paired reads send their two requests at once: GetObjectVersionDiff sends its two version reads together, neither waiting for the other — the second is sent even when the first fails. The answer is unchanged.
• An SAP user id a transport tool names is sent in upper case, trimmed: CreateTransport owner (compact HandlerCreate TRANSPORT too) and CreateTransportTask target_user; ListTransports matches its user filter in upper case. SAP stores user ids in upper case: a lower-case owner was refused 400 "User … does not exist in the system (or locked)" (measured).
• The package walks read in ADT batch envelopes, and take several roots. GetPackageContents (and compact HandlerGet part contents), GetPackageTree, GetObjectsList and GetObjectInfo send each level's independent requests in one envelope (POST /sap/bc/adt/communication/batch, inside the one call): per level the root node structures of its packages or nodes, then their type nodes (GetPackageTree reads the package metadata with the first; GetObjectsList every node of the level; GetObjectInfo with enrich one search per node in a last envelope). The descriptions in the answer come from each object's metadata, read in one more envelope after the walk (each object's read sent as that type's Get<Type> metadata read sends it — the same URL and Accept, a package's /sap/bc/adt/packages/<name>; its adtcore:description), not from the node structure parts: measured on the system, a node structure part after the first in an envelope can carry another part's DESCRIPTION, while metadata reads in one envelope answer as they do alone. An access control (DCLS/DL), which has no Get<Type> tool, is read as adt-clients reads its metadata (GET /sap/bc/adt/acm/dcl/sources/<name>?version=active, Accept application/vnd.sap.adt.dclSource+xml). An object whose metadata read fails, or of a type with no metadata read, has no description in the batched answer; otherwise the answer is the sequential version's. Each takes a list beside its single argument, exactly one of them given, read in the same envelopes and answered one entry per root in the order asked, a root's failure (the method's error with its step) its own entry: package_names (GetPackageContents, GetPackageTree, HandlerGet part contents), objects: [{ parent_type, parent_name }] (GetObjectsList), objects: [{ object_type, object_name }] (GetObjectInfo); the single arguments stop being required. A credential refusal — a 401 SAP answered to any root's read included — ends the call as it came, and nothing is read after it. A destination whose first envelope is answered 404 has no communication batch: that call and later ones run the tool's sequential reads as before, one root after another.
• SearchSource reads in ADT batch envelopes, answers a cursor; concurrency is removed. Inside the one call: the quickSearch of every package mask, one envelope; each level of the package walk (as the package walks above), one envelope each; the source reads of the scanned objects, up to max_objects, in chunks of 300 objects, each chunk's rounds — the main sources and function group structures, then the function groups' includes and function modules — in envelopes of at most 300 reads (fixed, no parameter). The scan targets are ordered by (package, type, name), and the answer carries total_targets, the targets of the walk; a new start_at (default 0) starts the slice [start_at, start_at + max_objects), and a scan that stops before its last target answers next_start_at, to pass as start_at to go on. The hits, no_hits, failures and truncated flags are the sequential version's. time_budget_ms is checked before every envelope: once it has passed nothing further is sent, and the answer holds whole objects only — those of the chunks read to the end — with truncated.by_timeout and next_start_at at the first object not answered (start_at itself when none was); a deadline during the package walk answers next_start_at: start_at and no total_targets, the targets never having been enumerated. After a cut, scanned.objects and scanned.sources count only the objects answered. When next_start_at equals start_at, time_budget_ms passed before the first object was answered: raise time_budget_ms or lower max_objects. Before, a deadline answered the objects read part-way. The sequential version answers whole objects too: those finished before the first one the deadline cut. Closes #89. A credential refusal — a 401 SAP answered to any read included — ends the call as it came, and nothing is read after it. concurrency (parallel source fetches) leaves the schema: an envelope carries a phase's reads at once. A destination with no communication batch runs the sequential reads as before (eight fetches at a time over HTTP, one over RFC).
• SearchSource is available on cloud systems too. It was declared for on premise only, on the grounds that cloud has no indexed source search; it never used one: it walks the packages and reads the sources, and both answer on an SAP BTP ABAP trial (measured 2026-10-21). ADT's own text search (/sap/bc/adt/repository/informationsystem/textsearch) answers "Source Search is not supported" on both the on-premise test system and the trial, so SearchSource does not call it.
• The include, structure and enhancement trees read in ADT batch envelopes, and take several objects. One envelope per phase, inside the one call, one level at a time: GetIncludesList — every object's first read (a program's or include's source, a function group's node structure, then its includes node), then per depth up to 20 the source of every include first reached there; GetStructuresList — per level of the tree the structure source of every node, then the table source of the nodes not found as structures, and with include_extensions the where-used scope pair (structure, table) of every node read, the scoped where-used of every scope that answered, and the source of every append candidate; GetEnhancements — the type probes (class, then program, then include, one per phase), the enhancements of every object with include_nested beside its root node structure, the includes node, the metadata of every include up to max_includes, then their enhancements. Each name is read once for the call; the trees, the cyclic and duplicate marks, unreadable, appends_unavailable, append_candidates_unread and includes_unread are the sequential version's. A phase can carry a read the sequential version does not send: the table where-used beside an answered structure where-used, the root node structure beside enhancements that fail, an include the depth-first walk does not expand. A call that is one request — a class's includes, a named object's enhancements without include_nested — sends it as before. Each takes a list beside its single argument, exactly one of them given, read in the same envelopes and answered one entry per object in the order asked, a failed one { object_name, object_type, error } ({ structure_name, error }): objects: [{ object_name, object_type }] (GetIncludesList, GetEnhancements), structure_names (GetStructuresList); the single arguments stop being required. A credential refusal — a 401 SAP answered included — ends the call as it came, and nothing is read after it; on such an extra read too (on the extra table where-used, only a refusal the connection throws). A destination with no communication batch runs the sequential reads as before, one object after another.
• ListTransports, DescribeByList and GetAbapSystemSymbols read in ADT batch envelopes. One envelope per phase, inside the one call: ListTransports — the search configurations, then the search of every saved configuration (up to 5); DescribeByList — the quickSearch of every object, then the quickSearch without its type of every object whose first answer was empty or failed; GetAbapSystemSymbols — the source of every class and interface symbol found in the code, in one envelope. The answers are the sequential version's. A phase can carry a read the sequential version does not send: ListTransports sends every configuration's search where the sequential version stops at the first that fails, and the first failed one in the order of the configurations is the answer, as before; DescribeByList and GetAbapSystemSymbols read every object or symbol of the phase beside one whose read is refused for the credential. A credential refusal — a 401 SAP answered included — ends the call as it came, the first in the order of the objects or symbols, and nothing is read after it (DescribeByList sends no typeless search). A destination with no communication batch runs the sequential reads as before, one request after another.
• GetWhereUsed and RuntimeListFeeds read in ADT batch envelopes, and take several objects or feeds. GetWhereUsed with a type filter sends two envelopes for any number of objects: the where-used scope of every object, then the scoped where-used request of every object whose scope answered (and, with enable_only_types, offers every type asked). Each scope is read once, where the sequential version reads it twice with enable_only_types (once to check the types, once to search). Without a filter, several objects are one envelope; one object without a filter is its one request, sent as before (compact HandlerWhereUsed too). RuntimeListFeeds reads the paged feeds (dumps, system_messages, gateway_errors) in rounds, one envelope each: the first page of every feed, then the next page of every feed still paging; descriptors and variants alone are their one request, sent as before (compact HandlerDumpList still reads one page per call). The answers are the sequential version's, with one exception measured on premise (2026-10-18): in a where-used answer without a type filter, the usage_information of a few references (Web Dynpro and BSP objects) depends on the requests the ABAP session ran before — over RFC two identical requests sent one after the other answer it differently, and over HTTP a request's part in an envelope answers it differently from the request sent alone; every other field is the same. Each takes a list beside its single argument, exactly one of them given, read in the same envelopes and answered one entry per object or feed in the order asked, a failed one { object_name, object_type, error } ({ feed_type, error }): objects: [{ object_name, object_type }] (GetWhereUsed, the type filters applying to every object; object_name / object_type stop being required), feed_types (RuntimeListFeeds, the filters applying to every feed). A list is recorded in batch mode by neither tool. A phase can carry a read the sequential version does not send: every object's or feed's read of the envelope beside one refused for the credential. A credential refusal — a 401 SAP answered included — ends the call as it came, the first in the order of the objects or feeds, and nothing is read after it; a refusal the connection throws to the scope read that checks enable_only_types is thrown, as the sequential version throws it. A destination with no communication batch runs the sequential reads as before, one object or feed after another.
• A read in an envelope that fails as a whole names the envelope's request. In the tools above that read in ADT batch envelopes, every read of an envelope SAP answers with a failure as a whole is that failure, and its request is the envelope's own (POST /sap/bc/adt/communication/batch) where the sequential version names the read's own request; the rest of the failure is the sequential version's.
• The server sends the request header pairs, and corrects a 406 / 415 once. Every call of an adt-clients member that takes a header pair goes with the server's pair: one default per member and object type — the pair adt-clients 35 sent, completed where it sent one header or none and corrected where SAP refuses it (the enhancement's check) (src/lib/adtHeaders/defaultPairs.ts) — or the pair corrected for the system. A request SAP answers 406 naming the types it serves is sent once more with them as the Accept, one answered 415 naming a type once more with it as the Content-Type; the corrected pair is kept in memory for the system the destination points at and that member — not for the credentials: two destinations to the same system share it — and sent from then on, until a later 406 / 415 corrects it again. A 406 / 415 naming nothing, or what was sent, is the call's answer; the second request's answer is the call's answer. In the tools that read in ADT batch envelopes, right after a phase's envelope answers, the requests SAP answered 406 / 415 go in one more envelope — only those, each sent again by its member with the corrected pair; one round. A read without a header pair (a search, a source or metadata read) is sent as it is and its 406 is its answer: DescribeByList answers an object whose typed search is refused 406 with that search's error and sends no typeless search for it. BatchEnd is unchanged: a recorded call's 406 / 415 is its answer. The correction is the server's, around the member calls, so it applies on any connection — an embedder's injected one included. An embedder shares the corrected pairs between its instances with adtHeaderPairs: new AdtHeaderPairs() (@mcp-abap-adt/lib/embeddable); without it each instance keeps its own. Anything an embedder did with adt-clients' enableAcceptCorrection is gone with it.

Fixed

• SearchSource reads only the sources of a function group, each once. It read every FUGR/* node of the group's object structure as an include: a screen answered 500 (SADT_RESOURCE 028) and ended the group as a failure, a GUI status or title answered 404, and an include was read and scanned once for every field, module or class listed inside it. The structure is now read through an objectStructure strategy, and a node is read only when its objecturi names a function module (/fmodules/) or an include (/includes/); a node without one is read by its type, FUGR/FF or FUGR/I.
• A check runs on the active version unless version is inactive (#181). CheckProgram, CheckFunctionGroup, CheckInterface, CheckBehaviorDefinition, CheckDomain, CheckDataElement, CheckDdl, CheckStructure, CheckTable and CheckPackage (high and low tiers; CheckObject for the same types) passed no status, and adt-clients reads a missing status as inactive, so a sound object with no inactive version reported syntax errors that were not there. CheckTable's new still checks the inactive version.
• ReadTransportObjects on a request answers each task entry once, with its task number (compact HandlerGet TRANSPORT too). A request's document also carries tm:all_objects, the request's aggregate list, and it was collected beside the tasks' entries, so every object came twice (measured: 684 rows for 342 entries). A task read is unchanged.
• stdio logs on again after SAP ended its session (#295). In 18.1.0 the connection the start made was reused after a SESSION_REPLACED, so every later call answered NOT_CONNECTED. Now the call that meets the replaced session still answers SESSION_REPLACED (nothing is retried); the next call ends the spent connection, logs on again and runs on the new session. The session SAP opened for the call that met the replacement is logged off at once (connection 18.0.1), so no session of the spent connection stays in SM05 until its idle timeout.

Measured

• Live measurements of 19.0.0 (2026-10-15; on premise BASIS 816 and an SAP BTP ABAP trial; Linux, Node.js 26.7.0; SNC on Windows): every transport and binary kind answered with basic, a token and SNC; a token refused by the system was renewed with the refresh token and written back; a logoff released the locks on a shutdown and on an SSE stream close; a long read's timeout left the instance's session and its lock in place; the stdio start took up its leftover session. A shutdown during the start's browser login hung and is fixed (exit 1, the callback port freed). Details: docs/development/tests/TESTING_AUTH.md.

Two transport organizer actions on @mcp-abap-adt/adt-clients 30.

Added

• SortAndCompressTransportTask (transport_number, the task): the organizer's Sort and compress — sorts a task's object list and merges its duplicate entries. A task holding the same entry twice refuses RemoveTransportObject with SCTS_ADT_MSG 009 (long text TR292) until it has run. Measured on premise (BASIS 816, 2026-10-12): 200 with an empty body; a task of 161 entries with four held twice re-read as 157.
• MoveTransportObjects (transport_number, the source task; target_number; objects, at least one, each object_name, object_type, position in the source and an optional pgmid): the organizer's Move Objects. Measured on premise (same day): one and two entries per call answered 200 echoing them, and both tasks read back with them moved.
• Neither answer is evidence of the change, so neither says success (as RemoveTransportObject): the terse answer is accepted: true, what was asked, and confirm_with naming ReadTransportObjects on the task — both tasks for a move. A missing argument or an empty objects is refused in fixed words naming the field before anything is sent. Both run under the critical section the other transport object writes have. 159 high-level tools.

Changed

• @mcp-abap-adt/adt-clients ^30.0.0, @mcp-abap-adt/adt-strategies ^0.10.2, @mcp-abap-adt/interfaces-adt ^15.3.0 (root and compact-modify). adt-clients 30's two new result slots, sortedAndCompressed and movedObjects, are read statusOnly and structured. @mcp-abap-adt/core, @mcp-abap-adt/compact and the two compact halves require @mcp-abap-adt/lib ^18.1.0.

The debugger on @mcp-abap-adt/adt-clients 29 (interfaces-adt 15, adt-strategies 0.10): another user's runs, terminal mode, leaving a debuggee running, the debugger settings — and breakpoints armed as one set. Migration: docs/MIGRATION-18.0.md.

Added

• DebugStartListener and DebugTakeOverListener (compact HandlerDebugStart, kind: abap) take request_user (whose requests are caught; needs the debug authorization on that user), debugging_mode (user | terminal) and settings (applied after each attach). Terminal mode catches the requests that carry the session's terminal id and IDE id; the run the server starts carries them in its SAP-PASSPORT, so it needs no configured id (measured on premise, 2026-10-12). The start answers the identity in force.
• DebugStep (compact HandlerDebugStep): detach and release_debugger, ABAP only — the program runs on, the session listens on.
• DebugSetSettings: the debugger settings at the current stop; answers the settings in force. 30 debugger tools.
• SAP_DEBUG_BREAKPOINT_CONFLICT (replace | refuse-if-held): whether a take-over and every later breakpoint change first ask if another debugger listens for the user. The header x-sap-debug-breakpoint-conflict, a destination's .env, the environment, createDebuggerInstance's breakpointConflict.

Fixed

• A second DebugSetBreakpoints removed the breakpoints of the first, and an ambiguous refusal re-asked with validationOnly removed the whole set: the system replaces the key's set on every request (measured on premise (2026-10-11), BASIS 816). The session sends its whole set every time, each breakpoint tagged with a clientId the system echoes, and pairs the answer rows by that tag without re-asking.

• A refuse start (DebugStartListener, compact without take_over) meeting another IDE's listener of the same SAP user replaced that IDE's breakpoints before its listen was refused 409: the user-mode set is the SAP user's with the request user, whatever the IDE id (measured on premise, 2026-10-12). It now asks the system first (checkListener) and is refused before anything is changed; every later DebugSetBreakpoints of that session asks the same way. The check is not atomic; the remaining race is documented.

• CreateFunctionGroupUnitTest and UpdateFunctionGroupUnitTest left the group's main program inactive, so ABAP Unit found no test class and answered an empty run result. Writing the test include regenerates SAPL<group> with the INCLUDE added; the group was then activated alone with the pre-audit, which is answered 200 with the inactive list instead of an activation, and that passed as a success (measured on premise, BASIS 816, 2026-10-12). The include, the group and its main program are now activated in one run without the pre-audit, and a refused or unfinished run is a failure.

Changed

• CreateFunctionGroupUnitTest / UpdateFunctionGroupUnitTest with detail: full answer the activation run (run_id, status) instead of the parsed activation checklist; detail: raw carries the run's results document. terse is unchanged.
• DebugStartListener and DebugTakeOverListener require breakpoints, at least one; a start without them is refused by the schema, and by the session before anything is sent.
• The breakpoints answer is the whole set: placed, refused (this call's, each with its definition), lost, unexpected. A delete by an id the session does not hold is refused before the wire.
• A condition on a non-line breakpoint is refused, naming it.
• DebugStop stops the listener first, which deletes the key's breakpoints, and deletes by id only when that fails; a start that failed after a change does the same. While the listener's open poll has not answered, the stop sends one more stop, which narrows a race of the system's without closing it (documented in DEBUGGER.md). The identity and the settings stay until a stop undid everything, and a new start is refused until then — except when the system refuses the listener's stop for the user (403 notAuthorized, 404 invalidUser): the breakpoints are let go, not deleted, the stop answers a note naming those left on the system, and the session ends when nothing else failed.
• A listener conflict (409) names the holder: the system's conflict text and the IDE user.
• @mcp-abap-adt/adt-clients ^29.1.0, @mcp-abap-adt/adt-strategies ^0.10.1, @mcp-abap-adt/interfaces-adt ^15.1.0 (the breakpoint types lose skipCount and gain clientId; a run takes the debuggee's ids); @mcp-abap-adt/compact-modify declares interfaces-adt, which it imports. @mcp-abap-adt/core, @mcp-abap-adt/compact and the two compact halves require @mcp-abap-adt/lib ^18.0.0.
• DEBUGGER.md: another user, terminal mode, the breakpoint set and its key, leaving a debuggee running, the settings, what ADT cannot do.

Changed

• A terse stop keeps up to 50 frames, not 5 — the ABAP stop (DebugWait, the step answers, compact's HandlerDebugWait) and an AMDP break alike. Real stacks run to some 20–25 frames, and five cut most of an ordinary one. A deeper stack is cut at 50 from the top, and stack_depth then gives the full depth, so a model knows to ask for detail: full.
• The AMDP stack under terse keeps no lines for a caller not compiled for debugging. Measured on premise with nested procedures: the system sends the innermost frame first (so the frames kept are the top ones), and for a caller not compiled for debugging it answers the method's first line and native line 0 rather than where the call stands. Such a frame now answers its procedure and object with not_debug_compiled, without line or native_line. full and raw are unchanged.
• Measured: a catch during a stop. An attach after the listener was stopped still succeeds, so DebugStop releases such a debuggee as it does; a caught debuggee nobody attaches is held about 30 seconds and then runs on. DEBUGGER.md says so.

Changed

• Memory sizes under terse (DebugGetMemorySizes, and HandlerDebugView with what: memory in compact) answer three numbers in bytes — abap_objects_used, internal_used, internal_peak_used — instead of the parsed document; full is the parsed document and raw SAP's, as before. The library reads the whole document as readMemorySizes (numbers, named after its elements) and projects it with terseMemorySizes.
• An AMDP break carries its call stack. AmdpEvent.stack reads the frames of an ON_BREAK (procedure, ABAP position and line, schema and native line, whether the frame is compiled for debugging); the terse event of AmdpDebugWait and compact's HandlerDebugWait keeps the first five, in the order the system sends them, as procedure, address and native_line, marking a frame not compiled for debugging.
• @mcp-abap-adt/core and @mcp-abap-adt/compact require @mcp-abap-adt/lib ^17.2.1.

The debugger: ABAP and AMDP debugging as an opt-in tool set, a debug session that lives between tool calls on every transport, and the instance state that holds it. Five schemas now refuse values their handlers used to bend (see Changed).

Added

• The debug set (--exposition=…,debug; opt-in, never part of the default, because a breakpoint catches every request of the connected SAP user), 29 tools:

  • ABAP: DebugStartListener and DebugTakeOverListener (arm breakpoints, listen, attach the first program caught, optionally run a class or report in the background; refuse, or displace, another debugger of the same user), DebugWait, DebugSetBreakpoints, DebugDeleteBreakpoint, DebugListBreakpoints, DebugGetStack, DebugSetStackPosition, DebugGetVariables, DebugSetVariable, DebugStep, DebugStepToLine, DebugTerminate, DebugCreateWatchpoint, DebugListWatchpoints, DebugDeleteWatchpoint, DebugGetMemorySizes, DebugCreateMemorySnapshot, DebugStop;
  • AMDP: AmdpDebugStart (a background run starts once the system confirmed the breakpoints), AmdpDebugSetBreakpoints, AmdpDebugWait, AmdpDebugStep, AmdpDebugGetTable, AmdpDebugCancel, AmdpDebugStop (releases a suspended debuggee first);
  • memory snapshots: MemorySnapshotList, MemorySnapshotGet, MemorySnapshotDelta (need the memory snapshot authorization; the list is empty without it).

  It debugs what it starts itself, in the system's user mode; terminal debugging, other users' requests and attaching to a process it did not start are not offered. Every answer takes detail (terse, full, raw). See docs/user-guide/DEBUGGER.md.

• A debug session is named by a state_handle (128 random bits) that the starting tool answers and every other session tool takes; an unknown handle and an ended session's get the same answer, state is not available. The handle is a bearer secret: keeping it safe is the deployer's (SECURITY.md, new). The state lives in the server instance: stdio keeps it in the process, SSE in its session, and Streamable HTTP in a pool of instances that routes each tools/call by its state_handle (one request at a time per instance; a batch carrying a handle is refused). Every host stops what an instance holds before letting it go.

• The idle bound on held state: --state-idle-minutes, env MCP_STATE_IDLE_MINUTES, YAML state-idle-minutes — default 30, at least 30, at most 35791. Held state ends after that many minutes without a tool call on its instance; a call in flight pauses it, a listener's own re-poll does not count. The end is a complete stop, logged on stderr without the handle.

• The debugger's SAP ids can be stated: headers x-sap-debug-terminal-id and x-sap-debug-ide-id, SAP_DEBUG_TERMINAL_ID and SAP_DEBUG_IDE_ID in the destination's .env or the environment; otherwise random per instance. The system keys its listener conflict by the IDE id, so sharing one is a deliberate choice; with stated ids, a restarted server's first start ends the listener its predecessor left.

• Library (@mcp-abap-adt/lib): subpaths ./debugger (the debug sessions, their readings and schemas) and ./state (InstanceState, the idle bound); DebugHandlersGroup, defineTool and the ArgsOf type from ./handlers; HandlerExporter option includeDebug (default false); EmbeddableMcpServer options stateIdleMinutes and stateLogger (default: the logger passed, else stderr), and its state, stateHandle, holdsState(), dispose(), shutdownState() and idle(); requestContextFromHeaders reads the two debug headers; readStateIdleMinutes and its names from ./config.

• Compact: --exposition=ro,debug or rw,debug adds four verbs — HandlerDebugStart (kind: abap|amdp, take_over, run), HandlerDebugWait, HandlerDebugView, HandlerDebugStep (stop ends the session) — 29 tools in all. debug alone is refused.

• docs/user-guide/DEBUGGER.md; the generated tool reference has a Debug group.

Changed

• Tool arguments are checked at any depth, with their ranges. The JSON schema of a tool becomes one zod schema recursively — nested objects and arrays included — with integer as a whole number, and minimum and minItems enforced. What that changes for callers:
  • a fraction is refused where an integer is declared on five tools, whose handlers used to truncate it: RunATC (max_findings), RuntimeRunClass and RuntimeRunClassWithProfiling (max_trace_attempts, trace_retry_delay_ms), GetObjectInfo (maxDepth), GetPackageTree (max_depth);
  • RuntimeRunClass and RuntimeRunClassWithProfiling refuse an out-of-range max_trace_attempts (under 1) or trace_retry_delay_ms (under 0), which their handlers silently replaced with the defaults; the schema always declared these minimums;
  • nested values are validated: GetVirtualFoldersLow's preselection[].values must be an array of strings, as its handler already assumed.
• Versions: @mcp-abap-adt/core and the three compact packages require @mcp-abap-adt/lib ^17.2.0, and @mcp-abap-adt/compact requires @mcp-abap-adt/core ^17.2.0 — the releases that ship lib/debugger and lib/state.
• On @mcp-abap-adt/adt-clients 27.0.0 (with adt-strategies 0.8.1, interfaces-adt 13.2.0 and interfaces-adt-connection 2.0.0). Every factory of the client now answers a contract; what that changed here:
  • CreateServiceBinding's last step reads the service group. It called generateServiceBinding, which sent that very read and generated nothing; 27 removed the name. The step stays — after an activation, a binding whose service group cannot be read is reported as the refusal it is — and the activate parameter now says what it does: activate, then read the group.
  • A class and a behavior implementation create carry no responsible person (adt-clients 26.0.1): SAP stores that attribute on them as the creator. The responsible person still travels on every other create; the system-context tests now drive a message class, and pin that a class create sends none and is not refused.
  • The result-set table gives the new slots (ATC check variants, the ABAP and AMDP debuggers, memory snapshots) a reading.

A personal portable build of both servers; no change to what the servers do.

Added

• A personal portable build: one executable per server (mcp-abap-adt, mcp-abap-adt-compact) and platform (Windows x64 and macOS arm64: HTTP, RFC, SNC; Linux x64: HTTP, RFC) — Node.js 24 inside as a single executable application, the builder's SAP NW RFC SDK and the RFC module beside it in nwrfcsdk/lib. Unpack and run: no Node.js, npm, compiler or SAPNWRFC_HOME on the machine. Built from this repository for the platform it runs on with npm run portable:build, portable:build:full or portable:build:compact, from the published packages of the version; checked with npm run portable:smoke. It carries the SDK, so it is never published or handed on. Verified on Linux in a clean container, on Windows 11 with SNC and on macOS arm64 (SNC not verified there). See docs/installation/PORTABLE.md. The build needs only the repository's production dependencies (npm ci --omit=dev --ignore-scripts): it installs esbuild and postject, at the versions the repository declares, into its own cache.
• @mcp-abap-adt/sap-rfc-lite 0.2.2, picked up by the existing ^0.2.1 range, builds the RFC module on a current macOS (its minimum was 10.15, which current Xcode's libc++ refuses) and under FORCE_COLOR (its binding.gyp read the N-API version through node -p, which colours numbers). The portable build still runs its nested npm install with colour off.

Removed

• @mcp-abap-adt/core no longer declares dotenv. The server never imports it; .env files are read by @mcp-abap-adt/lib, which keeps its own dependency, so an install of core carries dotenv once, through lib.

Documentation and release metadata; no change to what the servers do.

Changed

• The registry and Glama metadata is part of a release. releaseMetadata.test.ts fails until server.json, server-compact.json and the Glama image (docker/Dockerfile.inspect) name the version the manifests carry, the registry entries name their package and mcpName, their descriptions stay within the MCP Registry's 100 characters, and every sibling range is on the current major. The Glama image is pinned to the release of @mcp-abap-adt/core (it installed latest). glama.json names the variants. docs/deployment/RELEASE.md makes these a step of the release PR and gives mcp-publisher one command per registry entry.
• The compact tool counts are the ones the server lists: 25 tools, 16 that change nothing (@mcp-abap-adt/compact-readonly, --exposition=ro) and 9 that write (compact-modify). The READMEs and the package description said 22 and 13; the generated tool page takes its count from the tool list.

The dependency update to @mcp-abap-adt/adt-clients 25 and @mcp-abap-adt/connection 11, which verifies the HTTPS certificate of the SAP system. The installation documentation is rebuilt around the variants — the full or the compact server, over HTTP, RFC or SNC — and the Docker image installs the published server from npm. All five packages (lib, core, compact, compact-readonly, compact-modify) are 17.0.0.

Migration: docs/MIGRATION-17.0.md.

Breaking

• The HTTPS server certificate is verified (@mcp-abap-adt/connection 11). Up to 16.0.x the server accepted any certificate unless TLS_REJECT_UNAUTHORIZED or NODE_TLS_REJECT_UNAUTHORIZED was 1; a system with a self-signed or company-CA certificate is now refused at its first request. Trust the CA with NODE_EXTRA_CA_CERTS, or opt out with TLS_REJECT_UNAUTHORIZED=0 — both in the process environment: a destination's .env is not copied into it, so a line there is not read (it was not on 16.x either). RFC, SNC and plain http:// are unaffected.
• CreateMessageClass and CreateProgramUnitTest need a responsible person, like every other create since 16.0.0. @mcp-abap-adt/adt-clients 25.0.1 sends adtcore:responsible from the system context for a message class and for an include, where 24.x sent none and the system filled its own default; with no responsible found (SNC or a token you hold, no SAP_RESPONSIBLE) both are now refused with system_context_missing before the create is sent.

Changed

• @mcp-abap-adt/adt-clients ~25.0.1 (was ~24.1.0; still pinned to a minor, for the same reason), @mcp-abap-adt/adt-strategies ^0.7.0 and @mcp-abap-adt/interfaces-adt ^12.0.1, which move together — one copy of the contract in the tree. From adt-clients 25: getVersions() reaches the history of DDL sources, access controls, function includes and table types (it asked an address SAP answers 404); a namespaced enhancement is no longer encoded twice; a function module reference without its group is refused by the client too, before any request. RunATC takes the same seven object types: interfaces-adt 12's program and include kinds are not offered by the tool yet.
• @mcp-abap-adt/auth-broker ^4.1.0, auth-providers ^5.4.0, auth-stores ^3.3.0, interfaces-auth ^3.2.0, interfaces-auth-broker ^1.2.0. Nothing the server serves changes. A malformed service key file no longer puts its bytes — a client secret, a private key — into the thrown error and the log (Node's JSON.parse quotes its input); a log line about a failed SNC library lookup or a failed probe carries fixed words instead of the error's message. The x509 service keys these releases add are not served yet.
• @mcp-abap-adt/interfaces-adt-connection ^1.0.1, interfaces-network ^2.0.1, interfaces-utils ^1.1.1 (built from the registry, contract unchanged); @modelcontextprotocol/sdk ^1.32.0, dotenv ^18.0.5, fast-xml-parser ^5.11.2, pino ^10.4.0, pino-pretty ^13.2.0; dev: @biomejs/biome ^2.5.15, @modelcontextprotocol/inspector ^2.9.0, @types/node ^22.20.5. TypeScript stays on 6.x and @types/node on 22, as SAP's toolchain does.

Documentation

• Installation variants, in one place: docs/installation/INSTALLATION.md opens with the full (@mcp-abap-adt/core) and the compact (@mcp-abap-adt/compact) server, and with what HTTP, RFC and SNC each need on the machine; the README, the platform guides, the compact READMEs and the package descriptions point at it.
• RFC: the SDK, a C++ toolchain and SAPNWRFC_HOME come before npm install. @mcp-abap-adt/sap-rfc-lite ships no prebuilt binary and is compiled during the install; when it cannot be, npm leaves the optional dependency out and reports success, and the server refuses only the first RFC call. Measured 2026-10-05 on clean installs from the registry. RFC_SETUP.md now gives the toolchain per platform, the check (npm ls -g @mcp-abap-adt/sap-rfc-lite), the runtime PATH on Windows, SAP_SYSNR for a port that does not say the system number, how the SNC library is found, and a troubleshooting entry per failure. It installed sap-rfc-lite locally for a global server and checked it with a require that resolves from the working directory; both are gone.
• The platform guides no longer put TLS_REJECT_UNAUTHORIZED=0 in their sample .env (it was never read from there), no longer install from a .tgz or through git submodules, and no longer advise --no-optional. The README's development commands (npm start, npm run start:http) named scripts that do not exist; running a build from a checkout is described instead.
• Client configuration examples (docs/installation/examples/, the Cline and client guides) use --env-path for a path (--env takes a sessions-store name), and cover the variants: full and compact server, RFC/SNC with the process-level env block, a company CA. Checkout-based configs (dist/index.js, bin/mcp-abap-adt.js) and duplicate npx variants are gone; the HTTP and SSE examples carry their paths (/mcp/stream/http, /sse).
• Docker and release docs match the files: the image has no RFC SDK, so RFC and SNC are not available in it; NODE_EXTRA_CA_CERTS / TLS_REJECT_UNAUTHORIZED are container environment; npm publishing is npm run release:publish of the five packages in dependency order; MCP_REGISTRY.md covers server.json and server-compact.json.

Fixed

• @mcp-abap-adt/compact can be registered in the MCP Registry: it had no mcpName, and server-compact.json still named 14.0.1 with a description over the registry's 100 characters.
• server.json / server-compact.json described a .env in the working directory as a fallback; nothing has been read from there since 16.0.0.
• The Docker image starts again, and installs the server from npm. docker/Dockerfile built only the library (build:fast) and ran dist/server/launcher.js, which no build produces, so docker-compose.yml and docker-compose.headerless.yml could not start. Nothing is built now: stage 1 installs the published @mcp-abap-adt/core and @mcp-abap-adt/compact with npm install -g into their own prefix (build argument MCP_ABAP_ADT_VERSION, default latest), stage 2 copies that installation into a clean runtime image and runs mcp-abap-adt as the node user. The Node inspector is no longer open on 0.0.0.0:9229 by default. The build context is docker/, and its .dockerignore sends only the Dockerfiles — never service-keys/, sessions/ or a .env. Dockerfile.inspect installs the published core behind a pinned mcp-proxy instead of building a fixed commit from 2025. Dockerfile.package and docker-compose.package.yml, a second way to the same npm package, are removed. Built and run on 2026-10-05: HTTP initialize and the tool list answer, the health check reports healthy.
• npm run docker:* and npm run smoke:mcp:* run from the repository root. They were declared in server/package.json with paths relative to server/, where neither docker/ nor tools/ is; so were start, start:http, start:sse, dev, dev:http, dev:sse and kill-ports, which ran a checkout that cannot run and are removed, with the tools/dev-*.js launchers they called. tools/mcp-crud-smoke.js spawns the installed mcp-abap-adt for stdio by default.
• CI packs and installs all five packages and checks that no package took a sibling from the registry instead of this build; it packed only lib and core. It also builds the Docker image and runs both commands in it.
• --help: a message class is no longer described as the exception to the responsible rule, and the RFC requirement says the module is compiled by npm install.
• The compose health checks asked /health; the server answers /mcp/health.
• The integration tests read no .env from the working directory or the repository root. environment.env in tests/test-config.yaml is a sessions-store name, as the docs said, resolved exactly as --env=<name> (under auth_broker.paths.service_keys_dir, else the platform directory); it was resolved against the repository root, and a missing destination fell back to a .env in the working directory or the root — the lookup the server dropped in 16.0.0. Hard mode passes the same file to the server (--env / --env-path, with --auth-broker-path) and refuses to start without a destination instead of defaulting to ./.env. ClassCrudClientDirect, which builds its own connection, primes the system context itself; it passed only through what an auth-broker setup left in the process, and failed the responsible guard with a destination read from environment.env.
• A test that creates and deletes its own object never touches a shared one. assertNotSharedDependency refuses, before any request, a name listed in shared_dependencies: the function-include suite was configured onto the shared function group, which it would have created and deleted, and the views a BDEF suite creates are checked the same way. deleteView runs in cleanup whether or not the run created the view, so it no longer deletes a shared one — it reports it, and the run fails naming it. A BDEF suite whose test case lacks root_view_name / root_view_source says so, instead of view undefined; the profiling suite requires its class to be the shared, runnable one and shows the answer when no trace id comes back.
• npm run shared:setup and shared:teardown fail when they cannot reach the system or the config has no shared_dependencies. They passed, having done nothing — a green run that read as "set up".
• The release notes linked doc/installation/…; the workflows checked out submodules the repository no longer has (the empty .gitmodules is removed).

Fixed

• initialize reports the installed version in serverInfo.version. Every transport read npm_package_version, which npm sets only for a process it starts itself (npm run, npx); started by an MCP client, by node, or by mcp-proxy (as Glama's image does), the server answered 1.0.0 whatever was installed. mcp-abap-adt now reads @mcp-abap-adt/core's own manifest, and mcp-abap-adt-compact reports its own version, as --version already did. The bin smoke test now checks initialize from an installed tarball as well.
• @mcp-abap-adt/core carries mcpName again, so the MCP Registry can take it. mcpName stayed in the root manifest — @mcp-abap-adt/lib — when the server moved to server/, and the registry reads it from the package server.json names. No core from 10.0.1 to 16.0.0 had it, and the registry entry stopped at 8.8.1. docs/deployment/MCP_REGISTRY.md now says where it lives and that npm publish precedes mcp-publisher publish.

Migration: docs/MIGRATION-16.0.md.

Breaking

• Authentication runs on @mcp-abap-adt/auth-broker 4, connection 10, auth-providers 5 and auth-stores 3, and the server serves exactly four authentications: basic (HTTP or RFC), SNC (RFC only, no user and no password), jwt / authorization_code (browser login; an ABAP or XSUAA service key) and jwt / none (a token you hold). A destination that states anything else — certificate, kerberos, saml or another jwt grant — is refused at startup, naming the authentication (a saml destination with no grant is refused with lacks: grantType).
• A .env states its authentication. SAP_AUTH_TYPE has no default, and a jwt .env states SAP_GRANT_TYPE; without them the destination is refused (Destination "X" lacks: authType / grantType, with a hint to regenerate it with mcp-auth generate-env --grant). The mcp-auth command comes from @mcp-abap-adt/auth-broker-cli.
• An XSUAA service key needs XSUAA_MCP_URL in sessions/<destination>.env: the key carries the UAA, not the system.
• An --env / --env-path .env is read and written back with a renewed token, whatever --unsafe says. A destination is read once per process: a changed .env takes effect on restart. A named destination's session is read from sessions/<destination>.env only with --unsafe: a jwt / none token there is refused without it (lacks: authorizationToken, with a hint).
• Nothing is looked up in the working directory. Finding configuration where the process happens to start is a vulnerability: a server started inside someone else's project took their settings and credentials. A .env there is no longer read — pass --env-path=./.env (or --env=<name>, --mcp, YAML); without one there is no default destination (stdio: inspection-only). The working directory is gone from getPlatformPaths too.
• --auth-broker, MCP_USE_AUTH_BROKER and YAML auth-broker are removed; their only purpose was to switch the working-directory .env off. A leftover form stops the start, naming the form used ("was removed in 16.0.0 — remove it from the configuration") — drop it from client configs.
• The master system is determined from configuration, or by a request in the cloud. The setup-time master-system lookup is gone (setting a destination's context up builds no connection), and cloud versus on-premise is the kind the connection was built for (SAP_SYSTEM_TYPE, else jwt is cloud), never a guess from the URL. On-premise nothing is asked: the master system is SAP_MASTER_SYSTEM, or left out of the request when none is set. A cloud destination without SAP_CLIENT uses the system's default client.
• A created object always carries a responsible person; the master system only when known. The responsible comes from, first found: the tool's own argument (CreateTransport's owner); the x-sap-responsible header; SAP_RESPONSIBLE in the destination's own .env (the --env / --env-path file or sessions/<destination>.env), then in the process environment; else the login — on-premise the destination's SAP_USERNAME, the x-sap-login of an x-sap-url connection (not of a destination request), the process SAP_USERNAME; on a cloud system only systeminformation's user. A create (or a transport without an owner) that finds none (SNC or a token you hold, with no SAP_RESPONSIBLE) is refused before any request — "error": "system_context_missing", naming SAP_RESPONSIBLE, the header and the login (or, when a cloud system could not be reached, saying to retry when it is available) — where it used to be sent with an empty or missing responsible. CreateBehaviorImplementation, whose adt-clients class is built with an empty system context, now passes the responsible and master system itself. The one exception is a message class: it is created with the system's own default responsible (adt-clients' message class create takes none, as in 15.x). The master system comes from x-sap-master-system (no tool takes it as an argument), SAP_MASTER_SYSTEM (destination .env, then process), else a cloud system's id; otherwise it is left out of the request, as before — never refused. Reads are unaffected. On a cloud connection an empty value is filled from systeminformation even when a host's request scope carries its key as undefined. SAP_RESPONSIBLE from any source now wins over every login, outside a request scope that carries responsible. The process environment is read once: a change while the server runs is not picked up. The --env file's SAP_RESPONSIBLE, SAP_MASTER_SYSTEM and SAP_USERNAME are no longer copied into the process environment: they are that destination's own, and over HTTP/SSE they had become every other destination's fallback. getSystemContext() no longer reports SAP_USERNAME as responsible.
• @mcp-abap-adt/adt-clients is pinned to ~24.1.0: the refusal relies on its protected systemContext being read where a value is sent, which a minor release could change. Its service definition, transformation and access control builders write adtcore:responsible="" when the value is empty; the refusal is what keeps that from being sent.
• An embedder's own cloud connection is no longer recognised by its URL. A connection the factory did not build is cloud only when the server's systemType option or SAP_SYSTEM_TYPE says so; otherwise nothing is asked of the system, and a create without configured values is refused.
• The browser callback port is 61001 unless --browser-auth-port says otherwise (it was 5000, 4000 and 4001 by transport).
• x-sap-destination, x-sap-auth-type and x-sap-refresh-token are no longer read; a direct connection is x-sap-url with x-sap-jwt-token, or with x-sap-login and x-sap-password.
• AUTH_BROKER_PATH is one base directory (the value is not split).
• DeletePackageLow lost connection_config; a connection comes from the destination alone.
• @mcp-abap-adt/lib public API: registerAuthBroker, getAuthBroker, ConfigLoader, buildRuntimeConfig and AuthBrokerConfig are gone; AuthBrokerFactory has a new surface (defaultDestination, getBroker, settingsFor, getProvider, settle) and needs a browserStrategy; ConnectionContext carries credential: IAuthProvider; BaseMcpServer.setConnectionContext and the three transport servers take IDestinations. @mcp-abap-adt/core no longer depends on @mcp-abap-adt/auth-broker.

Added

• SNC logon over RFC (SAP_AUTH_TYPE=snc, SAP_SNC_PARTNERNAME, optional SAP_SNC_QOP, SAP_SNC_LIB, SAP_SNC_MYNAME): passwordless, through an installed SNC product such as a Secure Login Client. @mcp-abap-adt/sap-rfc-lite stays an optional dependency.
• Every authentication and connection parameter in three forms, in one table: CLI, YAML and, for seven of them, an environment variable (--browser, --browser-auth-port, --allow-destination-header, --system-type and the rest); precedence CLI, environment, YAML. An invalid port, enum or flag value is refused at startup, naming the parameter. YAML holds configuration only: a key that looks like a secret is refused, naming the key.
• One connector construction, three credential sources: a destination's provider, the request's headers, or a credential an embedder hands over.
• requestContextFromHeaders (@mcp-abap-adt/lib/request-context) and the optional IDestinations.systemContextFor: the request scope a request's headers state, and the responsible, login and master system a destination's own .env states. RequestContext gains login (the destination's SAP_USERNAME, or an x-sap-url basic connection's x-sap-login): the responsible when none is stated, on a connection that is not cloud. A resolver's {} means a cloud system that gave nothing; null means not asked.
• ListTransports filters by the effective responsible alone, no longer by a raw SAP_USERNAME.
• Shutdown that settles: on SIGTERM, SIGINT or the end of stdin the server stops accepting, waits up to 30 s for logins and refreshes in flight, and flushes every session; a secret that could not be stored, a login or refresh still running at the deadline, a server that did not close, or a failed settle exits 1 with one stderr line per fact (the destination and the error class, never a secret).
• Destination names are vetted before any file is read (letters, digits, _, ., -), and an env file named with --env / --env-path that does not exist is refused naming the parameter and the path.
• Errors in the server's own words: Destination "X" lacks: <fields> with a hint, and Destination "X" uses <type> / <grant>, which this server does not support; never a value read from a file. Under HTTP and SSE a refused credential is answered with the provider's own fixed words (status 500) instead of Internal Server Error.

Changed

• The docker files documented MCP_DESTINATION, which no code ever read. They now show the real ways: --mcp=<name> in the container command, YAML mcp through --config, or x-mcp-destination with --allow-destination-header; the compose files set AUTH_BROKER_PATH=/app.
• The documentation describes the four authentications, the parameter table, the .env write-back and the restart rule; the stale npm install -g @mcp-abap-adt/auth-broker and the 5000/4000/4001 port defaults are gone, in the help text as well.
• The npm tarball carries no working documents: docs/superpowers/ is excluded from files.
• The tests are type-checked in CI and in the release workflow (#268). npm run test:check ran nowhere, so a test that used a type it did not import ran green while the type check failed; both workflows now run it after the build.
• MCP_TEST_CONFIG names the integration-test config a run reads (#266), so one checkout carries a config per system; a named file that does not exist fails the run instead of falling back to the template.

Fixed

• x-sap-responsible and x-sap-master-system are read. They were written to the connection's metadata and read by nothing; they now enter the request scope over HTTP and SSE, for destination and x-sap-* connection requests alike, and a request with x-sap-* connection headers reads the process configuration too.
• SAP_LANGUAGE from --env-path reaches the objects it creates (#182). The env file goes to the auth broker's session store, which never fills process.env; the launcher bridged six system-context keys from it and not the language, so every object created through such a session took the library's default language. The bridge now lives in @mcp-abap-adt/lib/config (hydrateSystemContextFromEnvFile, ENV_FILE_CONTEXT_KEYS) and carries SAP_LANGUAGE; a value already in the process environment still wins. The responsible and master system are no longer among its keys: they are read as the file's destination's own (see Breaking).
• SAP_SYSTEM_TYPE in the --env / --env-path file beats YAML system-type. The argument parser wrote the YAML (or CLI) system type into the process environment before the env file was read, and the file's value, which never replaces one already set, was lost: YAML cloud beside SAP_SYSTEM_TYPE=onprem in the file built the cloud connector. The precedence is now resolved after the file joins the environment, as for the connection type: the CLI, then the environment (the file's value included, never over one set before), then YAML. A word in the environment that is not onprem, cloud or legacy stops the start, naming the key without quoting it. ArgumentsParser.parse() and ServerConfigManager (@mcp-abap-adt/lib/config) no longer write SAP_SYSTEM_TYPE into process.env: an embedder that parses the configuration itself reads systemType / systemTypeSource from the parsed config.
• The login URL reaches stderr without DEBUG_AUTH_LOG. The browser strategy prints the URL to open (--browser=none / headless, or auto when it could not open one) through the broker's logger, which is silent unless DEBUG_AUTH_LOG=true: the user never saw it and the login timed out. The strategy now gets a logger whose prompts are lines on stderr always; its warnings, errors and debug lines stay behind DEBUG_AUTH_LOG. Nothing goes to stdout.
• GetInactiveObjects reads the older document and keeps a function module's group (#266). BASIS 7.40 answers adtcore:objectReferences, which the reader did not know: it answered count: 0 over inactive objects. It now reads that document, refuses a root it does not know instead of answering an empty list, and gives each entry its parentName (the group of a function module, from adtcore:parentUri), so the entry can be handed to ActivateObjectLow as it is.
• The shared test setup activates a function module through its group (#266). The module's own name stood in the group's place in the address, and the whole activation batch answered 500 invalidFunctionGroup.
• Enhancement types ADT does not expose are named as such (#267). GetEnhancementSpot on a plain enhancement spot, and GetEnhancementImpl on a class enhancement, answer that the object is not available through ADT (Eclipse opens it in SAP GUI) instead of passing a raw 500 on; a BAdI implementation is answered as having no source, and a source code plugin asked under a spot name gets the hint to read it with enhancement_spot "enhoxhh". A plugin read under enhoxhh that fails keeps its own failure. What worked keeps one request and its answer.

Added

• Compact reads: search, where-used, data and a package's contents (#259). Compact serves a host without a pipeline of its own, and these are ordinary investigation steps it could not take at all: the command launches without the search group, and nothing routed where-used or data.

  • HandlerSearch — objects by name or mask, optionally by type, capped.
  • HandlerWhereUsed — the objects that use one object, capped with the total kept (on premise, a standard class answered 107,141 references); a function module is addressed under its group.
  • HandlerGetData — rows of a table or CDS view, or what an ABAP SQL SELECT names with its columns, conditions and order.
  • HandlerGet part: contents for a PACKAGE — its members, one line each: name, type, description, capped by max_results (default 100) with the total said (a package of 257 members on premise: 11,260 characters, against 45,705 as the core reader's JSON; the trial's top-level local package lists 11,619 entries and answers 100 of them in 3,491 characters).

  All four read, so they live in compact-readonly and serve --exposition=ro as well: compact is 25 tools, 16 of them read-only.

• Dumps filtered by what they are about (#261). RuntimeListFeeds with feed_type: dumps and compact HandlerDumpList take runtime_error, exception, object_name, package and component (each contains) beside user (equals), from and to — sent as one $query on the attributes the dumps feed's descriptor declares. contains ignores case: on the BTP ABAP environment (2026-10-01) three spellings of one runtime error matched the same dumps, 66 of 200, and an unknown one none. A value with a blank, a comma or a parenthesis is refused before the request, and a dumps filter on another feed is refused rather than dropped. Needs @mcp-abap-adt/adt-clients 24.1.0.

• Every dump entry carries its dump_id, the id RuntimeGetDumpById takes; that tool accepts the entry's URI as well.

• GetUnitTestResult in the readonly group too. Fetching an ABAP Unit run's result by its run_id only reads, so a read-only caller may do it. It is a copy of the high tool — the same name, schema and handler — and stays in high.

Changed

• A feed list follows SAP's pages (#261). SAP answers at most 100 entries per feed request whatever $top asks (the descriptor declares paging max="100"; $skip is ignored) and offers the next page as a rel="next" link bounded by to. max_results (compact: top) now reads page after page up to the count asked, at most 1000, and answers next_to when more remain — pass it back as to to read on. Without a count it reads 50, the feed's own page size, the same way. to is inclusive: a page starts with the entries of the previous page's last second again (four on one boundary on the BTP ABAP environment, 2026-10-01), so an entry is answered once, and a page asks for its repeats as well as the entries still wanted. Nothing is remembered between calls, so an answer never ends inside a second: it holds entries newer than next_to, and reading on from it starts with that second whole — nothing repeats, nothing is skipped. An answer may therefore hold a few entries fewer than asked. A second holding more entries than asked is answered whole instead, more than asked, and reading on starts from the second before it; SAP pages by time alone, so a second holding more than one request's 100 is answered as far as SAP gives it and named in incomplete_second.
• A dump's summary is the dump's own root (#261). RuntimeGetDumpById's summary is read from the default view's dump:dump attributes — runtime error, exception, title, terminated program, time, user — and the source position where it terminated, from the …/runtime/dump/termination link, whose adt://<system> prefix is dropped so the URI is the ADT path. It picked keys by name out of the whole document before, and answered chapter titles. Compact HandlerDumpView view: summary answers that summary alone; ADT's own summary view answered a document without the root.
• GetPackage and ReadPackage answer a summary of the package — name, description, type, super-package, software and application component, transport layer, ABAP language version, responsible, and the number of sub-packages; with detail: full every sub-package by name and description as well; and the metadata document itself with detail: raw. The document carries every sub-package: a top-level package answered about 950,000 characters on the cloud trial (5,815 sub-packages, no member object), which an MCP client refused, and ReadPackage sent it twice. The same package now answers 327 characters (sub_package_count: 5813); on premise a structure package with 1,222 sub-packages answers 351.
• A tool present in two groups is exposed once, from high. When a readonly tool shares its exact name with a tool of an exposed high/low group, ReadOnlyHandlersGroup withholds its own copy, whatever dedup strategy is passed — one server cannot register two tools under one name. readonly alone → from readonly; readonly + high → once, from high. HandlerExporter now hands the read-only group the high/low names as well (with NoDedupStrategy, so it still lists Read<X> beside Get<X>), and tools/generate-tools-docs.js documents such a copy under Read-Only.

Changed — BREAKING

• ABAP Unit tools are one simple operation per test carrier. A tool does one thing to one kind of object, with the fewest parameters that say which; a general tool with an object type and a dozen optional parameters is harder for a model to call right and for a tool search to find. On adt-clients 24, which runs tests per object type.

  carrier	write the tests	run them
  class	CreateUnitTest, UpdateUnitTest, DeleteUnitTest (class_name, test_class_source)	RunUnitTest (class_name)
  CDS view	CreateCdsUnitTest (view check, test class, tests — one call), UpdateCdsUnitTest, DeleteCdsUnitTest	RunCdsUnitTest (class_name)
  report	CreateProgramUnitTest, UpdateProgramUnitTest (program_name, test_class_source)	RunProgramUnitTest (program_name)
  function group	CreateFunctionGroupUnitTest, UpdateFunctionGroupUnitTest (function_group_name, test_class_source)	RunFunctionGroupUnitTest, RunFunctionModuleUnitTest

  Every Run* starts the run, waits for it within a bound and answers the result; a run that outlasts the bound answers its run_id, and GetUnitTestResult fetches the result later. Every write locks, writes, unlocks and activates. A report's tests go into a test include the tool creates in the report's package and pulls into the report; a function group's into a test include whose INCLUDE ADT adds to the group itself. Measured on premise (2026-09-30) through all four integration suites, soft and hard mode.

Removed — BREAKING

• GetUnitTest, GetUnitTestStatus, GetCdsUnitTest, GetCdsUnitTestStatus, GetCdsUnitTestResult. A Run* tool answers the result itself; GetUnitTestResult answers about any run by its id, whatever started it. The functions stay exported from @mcp-abap-adt/lib for the compact facade, which keeps its granular status and result tools.
• The low-tier unit-test tools — RunClassUnitTestsLow, GetClassUnitTestStatusLow, GetClassUnitTestResultLow, LockClassTestClassesLow, UnlockClassTestClassesLow, UpdateClassTestClassesLow, ActivateClassTestClassesLow. The lock pair addressed members adt-clients 24 no longer has.

Migration

• CreateUnitTest used to start a run (tests[]); it now writes a class's tests. To run them call RunUnitTest with class_name.
• RunUnitTest takes class_name instead of tests[] and answers the result, not a run id to poll.
• UpdateUnitTest and DeleteUnitTest took a run_id and always failed; they now take class_name (and test_class_source for the update).
• CreateCdsUnitTest now also writes the tests (test_class_source) and activates the class; description is gone.
• Instead of GetUnitTest/GetUnitTestStatus/GetCdsUnitTest*, read the Run* answer; for a run that had not finished, GetUnitTestResult with its run_id.
• GetUnitTestResult takes run_id alone: with_navigation_uris and format left the tool (the compact result facade still takes them).
• Compact: HandlerCreate/HandlerUpdate for UNIT_TEST take class_name and test_class_source, and HandlerDelete takes class_name (they took tests[] and run_id); HandlerUnitTestRun and the status and result facades are unchanged.
• Integration config: the unit-test cases changed and two were added (program_unit_test, function_group_unit_test) — copy them from tests/test-config.yaml.template.

Changed

• Eleven tool descriptions say what the tool does, and nothing else — no denials, no other tools' names, no protocol notes. A description is read by a model and indexed by a tool search, and every word it carries pulls the tool toward queries with that word. GetWhereUsed, ReadFunctionModule, GetFunctionModule, RuntimeListFeeds, CreateServiceBinding, CreateServiceDefinition, GetLocalTestClass, UpdateLocalTestClass, DeleteLocalTestClass, AddTransportObject, RemoveTransportObject; and the transport_number, object_name and position parameters of the two transport tools. The …LocalTestClass tools describe the include they read and write; "the unit tests of a class" belongs to the ABAP Unit test tools. No name, schema or behaviour changed.

Fixed

• Publishing an OData V2 service binding could not succeed. UpdateServiceBinding took service_name and service_version — service_name is required on the tool surface — and dropped both, because the library had nowhere to put them. A V2 publication job resolves the service from them, so the job answered 200 with SEVERITY ERROR naming an EMPTY service and version 0000: "Activating Local Service Endpoint of service ␠ with version 0000 failed". The binding was active and srvb:allowedAction named the very action asked for.

  @mcp-abap-adt/adt-clients ^23.0.5 (was ^23.0.4) takes them per protocol, so this handler now passes them for odatav2 and not for odatav4, where the request names its target on its own. Measured there on all four binding variants: both V2 ones refuse without the fields and succeed with them, both V4 ones succeed without them — so the axis is the protocol, not the UI/Web API category. See that package's ERRATA, "A V2 publication job resolves the service by name and version".

  The two parameter descriptions said the job "no longer carries" these fields. It carries them again for V2, and they now say which protocol uses them and that V4 ignores them.

  Found while removing the probe objects from #248: two V4 bindings unpublished through this tool and the V2 one did not, which made the comparison single-variable.

• A binding anybody had open could not be published or unpublished at all. UpdateServiceBinding passed analyseLock to its LOCK, so the 403 that means an editing session holds this binding was a refusal: "User … is currently editing ZMCP_E2E_V2". adt-clients' ERRATA is explicit that this one 403 is to be ignored — the publication job needs no lock of the caller's, and Eclipse posts it after its own LOCK's 403 — and names the strategy for it, analysePublicationLock, which answers a lock without a handle instead.

  But analysePublicationLock alone would have opened a second hole, found in review: it forgives by STATUS — 403 — and is built on analyseException, which sees only documents. A 200 naming no lock handle is therefore no failure to it either, and the caller is handed the same empty handle as for the 403. A login page on an expired session is a 200, so "publish when there is no handle" would publish after a lock that never happened — exactly the check analyseLock had been doing.

  So the handler passes its own composed strategy, analysePublicationLockAnswer: analyseLock first, so a 2xx without a handle stays a refusal, and the 403 forgiveness after it. An empty handle then means one thing only, which is what lets the handler publish without a handle and send no UNLOCK — there is nothing to release. withLock is untouched.

  Measured the hard way. A publication whose client gave up at 120 s — the job takes ~133 s — left the lock behind, and the unpublish that followed was refused. With the two changes the same call went through, and the wire shows both fixes at once:

  POST …/bindings/zmcp_e2e_v2?_action=LOCK&accessMode=MODIFY  -> threw 403
  POST …/businessservices/odatav2/unpublishjobs
  params {"servicename":"ZMCP_E2E_V2","serviceversion":"0001"}
  

Fixed

• The documented way to generate a .env from a service key did not run. Four places told a reader to install @mcp-abap-adt/connection and then invoke mcp-auth auth -k <service-key> — a command from a different package, with flags it does not have. Measured: mcp-auth auth -k … answers Unknown command: auth. Two more places, the runtime help in utils.ts and the launcher's, named sap-abap-auth instead, which is coherent — @mcp-abap-adt/connection really does ship that bin, and it really does still work — but it is the superseded path: token handling moved to @mcp-abap-adt/auth-broker, which is a direct dependency here and ships mcp-auth and mcp-sso.

  All six now say the same measured thing:

  npm install -g @mcp-abap-adt/auth-broker
  mcp-auth --service-key path/to/service-key.json --output .env
  

  Worth naming because half of this was in the RUNTIME help — what a user reads when the connection failed, which is the worst moment to hand them a command that does not exist. Reported from the README; both halves were wrong, in different ways, and neither would have been found by fixing only the name.

Added

• GetServiceBindingPreviewUrl — the browser URL for a published service binding, which no document carries. ADT's Preview button does not ask the server for a URL: it builds one, and the path segment after feap/ is not a token but a ##-joined descriptor of the service, shifted by 20 (0x14) and percent-encoded as UTF-8 — which is why bytes above 0x7F arrive as %C2%XX. The rule was derived from a URL Eclipse produced for an on-premise V2 binding and verified by re-encoding it byte for byte; that pair is the fixture in feapDescriptor.test.ts, and the handler test asserts the tool reproduces that exact URL.

  What it reads, and why each one is needed, all of it measured rather than assumed:

  descriptor part	where it lives
  service	srvb:services/@srvb:name — not the service definition: a trial binding answered services="ZUI_TRAVEL" with definition ZTRAVEL_SD
  version	srvb:content/@srvb:version (minorVersion/patchVersion belong to neither URL)
  protocol	srvb:binding/@srvb:version: V2 → odatav2, V4 → odatav4
  entity set, target	expose … as <alias> in the service definition — the ALIAS is the entity set
  navigation	an association or composition of the exposed root view
  annotation service	<service>_VAN, the generated Gateway Vocabulary Annotation (object type IWVB)

  Of the segments, the server reads two — and that was measured, not assumed. The page at …/feap/<segment>/flp.html is static; the resource that decodes the descriptor is <segment>/manifest.json, reachable with the ordinary ADT token, which is how every claim below was settled without a browser. Asking one descriptor after another on a trial (OData V2): the service becomes the manifest's service uri; the entity set becomes ListReport|<entitySet>, and a bogus one answers a list report with no page under it. The navigation, the target entity set and the _VAN segment are not read — empty, bogus and plain wrong values all answered the same nested page, because the server derives the navigation from the service's metadata, and it normalises the CDS name while doing so (_children came back as to_children). So only the entity set is required; the other segments are still filled, because that is the shape Eclipse produces.

  It still refuses to invent what it cannot read. Without an entity set there is no preview_url — the answer carries missing, the entity sets to choose from, the service and $metadata URLs, and, when the binding is unpublished, a note saying nothing answers until it is. A URL with one guessed segment is indistinguishable from a working one until it opens nothing.

  OData V4 is a different descriptor, and the first version of this shipped the V2 one for both. Seven parts, the service's URL PATH first and the BINDING last:

  /sap/opu/odata4/sap/<binding>/srvd/sap/<service>/<version>/##Root##_children##Child##<service>##<version>##<binding>
  

  Decoded from two URLs Eclipse produced for one binding — its root entity set and its child — and both are byte-exact fixtures. Part 5 is the service (a wrong one answers 200 with the nested pages gone), part 7 the binding (the service there answers 401, the authorisation check reads it); the navigation is not read here either. A V4 binding has no _VAN object at all: publication creates a service group (SCO2/SIA6), no IWVB.

  On BTP the preview opens on the browser host. <id>.abap.<region>.hana.ondemand.com serves ADT and answers a browser 401 WWW-Authenticate: Basic — unanswerable, since the credential is a propagated token and the bearer header a pasted URL cannot carry; <id>.abap-web.<region>.hana.ondemand.com serves the BTP logon and then the page. So preview_url carries the abap-web host and the service URLs keep the ADT one. On premise there is no such split and nothing changes.

  client and language are not the caller's to supply. They come from /sap/bc/adt/core/http/systeminformation, which this server already reads for a request's system context, so the URL ends …&sap-ui-language=EN&sap-client=100 by itself. The parameters remain as overrides and an empty client suppresses it. The lookup cannot fail the tool: that endpoint answers null where absent but THROWS otherwise, so a failure is reported in note beside a URL that is still answered.

  The service URL is read from ADT when ADT names one. …/businessservices/<protocol>/<BINDING>?servicename=…&serviceversion=… is what the Service Binding editor reads for its own "Service URL" field; when it answers, that answer wins and service_url_source says system, otherwise the composed URL stays and says composed. Measured on a trial it answers empty even for a service whose $metadata answers 200, so it only adds information.

  A Web API binding has no preview at all — srvb:binding/@srvb:category is 0 for UI and 1 for Web API — and says so, with the service and $metadata URLs, instead of carrying a FEAP URL that opens nothing.

  The exposed root view is read only when a navigation is wanted and none was given, so the usual cost is two requests. A projection spells its navigation a third way — _children : redirected to composition child X — which the first version did not read, and answered associations: [] for a view that has one.

• part on the compact HandlerGet: source, metadata or urls. Compact is one tool per OPERATION, so "which aspect of this object" is an argument of the read rather than a twenty-third tool — and it is the same parameter the object-oriented tiers still lack, where eight Get* tools fetch a metadata document and discard it while the Read* that would answer it is hidden by the Read-vs-Get dedup.

  metadata routes to the readers that actually return the document (sixteen object types have one); urls routes to GetServiceBindingPreviewUrl and therefore exists for a service binding alone, which is the honest size of it.

  A part the type does not offer is refused by name, never substituted. Asking for urls on a class answers part=urls is not available for object_type=CLASS. It offers: source, metadata. — the refusal carries what to ask instead, and answering the source would be a success meaning something other than the question. The refusal is returned the way the router returns an unsupported operation, so both paths through the surface have one shape. A missing object_type stays the router's own refusal rather than gaining a second voice.

  @mcp-abap-adt/lib/handlers/read grew from 35 to 54 exports for this: the metadata readers and the preview tool. The read-only half still reaches no write route — compactCapabilitySplit checks that against the import graph, not the intention.

Fixed

• Hard mode could not start the server at all. The integration harness spawned it with --exposition=readonly,high,low, and high and low are mutually exclusive — correctly so — which validateExposition refuses, so the launcher exited before serving anything: Invalid exposition: 'high' and 'low' are mutually exclusive. Hard mode is the only mode that proves the server starts and registers its tools, so it was the one check that could not run. It went unnoticed because it is opt-in: soft mode, the default for mass regression, calls handlers in-process and never spawns MCP. The exposition is now a config key, integration_hard_mode.exposition, defaulting to readonly,high; one run covers one tier and readonly,low serves the other. Asking for both was never a test of anything.

• The --exposition help advertised a combination the launcher refuses. The examples listed readonly,high,low (all handlers), so a reader who followed the documentation got a startup error. They now list readonly,low and say in one line that no value serves every handler at once.

Fixed

• The help text described a surface neither command has, and the compact command had no exposition of its own. 14.0.0 moved the facade out and taught validateExposition to refuse compact, but --help still listed it among the sets — --exposition=compact (compact facade only) — and mcp-abap-adt-compact printed that same help, offering readonly/high/low, which it does not serve, under a USAGE line naming the other command.

  • mcp-abap-adt --help lists readonly, high, low, and says in its place that the compact facade is its own command with its own default.

  • mcp-abap-adt-compact --help names itself in USAGE and documents its sets.

  • mcp-abap-adt-compact --exposition=ro|rw: rw is the default — all 22 tools, every access, which is what a local server gives — and ro serves the 13 that change nothing. ro is not a filter over one list: no create, update, delete, activate, lock, unlock, unit-test run or profiler run is IN the list, so a client cannot call one (verified from installed tarballs: 22 tools with 9 writes against 13 with 0). A set of the object-oriented surface is refused by name, pointing at mcp-abap-adt.

  • ServerConfigManager.generateHelp takes program and expositionSection, so a sibling command documents its own vocabulary instead of inheriting one that does not apply.

  • An empty value is refused, not defaulted. The first version treated "no flag" and "flag with nothing in it" alike, so --exposition="$MODE" with an unset variable opened all 22 tools — writes included — and --exposition=ro --exposition= overrode a deliberate ro the same way (found in review). The default belongs to an ABSENT flag; a flag that is present but says nothing is a caller who meant something and lost it in a shell, so it fails at startup. --exposition with a following flag rather than a value counts as empty too.

  Two mistakes of mine while writing this, both caught before release: the first version REFUSED --exposition on the compact command instead of giving it ro/rw (the user's correction), and the ro branch first wrapped the entries in an object literal, which closes over the startup context — the P1 from PR #240 review, in a new place. It builds a real CompactReadOnlyHandlersGroup now, so the per-request context reaches the handlers.

Migration: docs/MIGRATION-14.0.md.

Changed

• The compact facade left lib for three packages of its own. It exists for a host that cannot build a retrieval pipeline — a small context, no tool-RAG, no way to select tools per request — and must still drive ABAP through MCP. Such a host needs a tool list short by construction, and a package whose default IS that list cannot be misconfigured into something else.

  package	carries	bin	licence
  @mcp-abap-adt/lib	handlers, registries, embeddable — minus the compact tools	no	Apache-2.0
  @mcp-abap-adt/compact-readonly	the 13 compact tools that change nothing	no	Apache-2.0
  @mcp-abap-adt/compact-modify	the 9 that write, lock, activate or execute	no	Apache-2.0
  @mcp-abap-adt/core	transports, launcher, mcp-abap-adt	yes	AGPL-3.0-only
  @mcp-abap-adt/compact	the compact server, mcp-abap-adt-compact	yes	AGPL-3.0-only

  Versions move in lockstep: the compact packages are one decomposition of the same lib, and independent numbers would create combinations nobody has run.

• core no longer serves --exposition=compact. The value is recognised and refused, naming the package that serves it — a configuration asking for a tool list it will not get should fail at startup rather than start with tools missing. This breaks nobody in practice: the consumer that drives this repo indexes all the tools itself and never wanted the facade, and whoever does want it installs the command.

• One launcher, two commands. main() in @mcp-abap-adt/core/launcher is exported and takes extraGroups, exposition and includeSearch, so mcp-abap-adt-compact is a twenty-line bin over the same configuration, transports and auth rather than a second copy of four hundred lines. It self-starts only when it is the program, so an import does not start a server, and each bin calls main() itself. --version on the compact command answers the compact package's version, not core's.

Added

• @mcp-abap-adt/lib/handlers/read and /write — the 35 and 69 handler functions the facade routes to, in halves, because one barrel of all 104 would relink every write route into compact-readonly and defeat its own split. @mcp-abap-adt/lib/compact-shared exports the facade's kernel: object types, the CRUD matrix, the schemas, the lifecycle helpers and dispatchCompact — data and dispatch, no handler, which is what makes it shareable by both halves.

• The capability split is asserted against the module graph, across packages. compactCapabilitySplit.test.ts walks the imports from each package's entry — relative files AND bare specifiers — and holds that compact-readonly never names @mcp-abap-adt/lib/handlers/write or the modifying package, that its manifest declares only lib as a dependency, that the modifying half DOES reach the write routes (so a split that lost them fails too), and that each of the 22 tool files belongs to exactly one half.

• The compact surface has its own frozen fixture and its own generated page. lib's surface.json lost 22 rows; they moved to compact/tests/fixtures/, where compactSurface.test.ts freezes them from the packages' entry builders — a ratchet that loses its subject silently is worse than no ratchet. compact/docs/AVAILABLE_TOOLS.md is generated from the BUILT packages (npm run docs:tools in compact/), refusing a stale build, and lib's generator no longer writes a compact page.

• binSmoke covers the third bin. It packs all five packages, installs the tarballs into an empty directory and runs both commands: mcp-abap-adt --version answers core's version and mcp-abap-adt-compact --version answers compact's.

Changed

• No parameter description names a transport request, and nothing in the tree names the system it was measured on. The rule is the user's and it is about agnosticism, not retrieval: we do not know who will use this, where, or how, so we state only what we know. A tool's text says what the tool does and what its parameters mean; a request number from somebody's landscape is not part of that.

  • 78 transport-number literals removed from parameter descriptions, across 78 files — one real request 73 times, four more once or twice each. Transport request number (e.g., …). Required for transportable objects. now reads Transport request number. Required for transportable objects., and the three transport tools whose text turns on the request/task distinction keep the distinction and lose the example. The worst case was not retrieval: an example request number is a value a model can copy into a write, and it addressed a real transport.
  • The system id is gone from the whole tree — descriptions, code comments, test comments, test data, captured fixtures, the installation guides, the test template and this changelog's own history. What a measurement note knows is the platform and the date, so on E19 (2026-09-26) reads on premise (2026-09-26), and Measured on E19 (BASIS 816) and E98 (BASIS 756) reads Measured on BASIS 816 and on BASIS 756 — the release is the fact that mattered. --env=…/e19.env reads --env=…/your-system.env; a SAP_MASTER_SYSTEM example reads the three-character SID; captured fixtures carry SID, beside the SAPUSER01 they already carried. Test data keeps its numbers under a placeholder prefix (SIDK9…), so every assertion still pairs with its input.
  • One of these was a live defect rather than a wording problem: GetNodeStructureLow's node_id description explained "0000" by naming the system that answered an empty body for it.
  • And then every other name went with them: 255 of 370 tools, 350 parameter descriptions, 169 distinct strings. Class name (e.g., ZCL_MY_CLASS). reads Class name.; Package name (e.g., ZOK_LOCAL, $TMP for local objects). reads Package name.; Optional for local objects ($TMP). reads Optional for local objects. — ABAP Cloud has no $TMP anyway. Constraints that change the call stay word for word ("must already exist", "required for validation", "start with Z or Y", the REQUEST/TASK distinction). What goes is only the example. A couple needed a sentence rather than a deletion: the software component no longer names two components, and the search pattern explains "*" as a prefix match instead of listing masks.
  • Naming rules left with the names, and so did the CTS lesson. A tool works with any object the caller is authorised for, whatever it is called, so "must follow SAP naming conventions", "start with Z or Y", "for the customer namespace", a behaviour pool's conventional name and the worked ABAP snippet in the function-module source parameter are all gone (28 descriptions). The consumer's skill carries the naming rules and answers for the validity of what it sends. The same cut trimmed 104 transport_request descriptions: request is a word a description may use, a number never is, so the text keeps not a task — the one fact that decides whether this call succeeds — and drops how CTS works, which tool to call after it, and CTS_WBO_API 020 / SADT_RESOURCE 017. What stays is a limit that says what fits in the parameter ("up to 26 characters", the field-label lengths) and the transport tools' own text, where request against task IS the subject of the tool.

Fixed

• The tool docs now show the text the model receives, not the text a regex could parse out of the source. Three reviewer findings on PR #244 were one defect in three costumes: a Zod .description is a prototype getter and was invisible; a description built as '…' + '…' was cut at the first literal; a template literal printed ${commonObjectTypeSchema.description} verbatim, because no regex evaluates an interpolation. generate-tools-docs.js keeps the source parse for structure — which tools exist, their files, tiers and schema shape — and takes every description from the BUILT definitions through HandlerExporter, the same strings a consumer's RAG indexes. Beside the interpolation, this filled in five compact parameters that were documented as empty because their schema is a shared constant the regex could not follow.

  And reading dist is only correct while dist is current, so that is checked rather than assumed. A reviewer edited DeleteClass's description, ran docs:tools and got success with the previous text in the documents, because the script did not build. docs:tools now builds first, and the generator refuses to run when dist is missing or older than any source file, saying how far behind it is and what to do. The check throws rather than exiting: a unit test requires this module, and a generator that kills the process from inside a test run is its own defect. The "fall back to the parsed text" path is gone — it was the mechanism that let wrong text look like success.

• The generator dropped everything after the first string literal of a concatenated description. It reads source with regexes rather than importing the built definitions, and the pattern stopped at one literal — so five tools lost a whole sentence each from the generated docs: the legacy refusal notes on GetCdsUnitTest, GetCdsUnitTestStatus, CreateCdsUnitTest and GetStructuresList, and the polling bound on GetCdsUnitTestResult. What made it visible was cosmetic — git diff --check flagged two trailing spaces, which were the seam where the text had been cut (found by a reviewer on PR #244). The generator reads the whole + chain now, in the tool description and in every parameter description.

Added

• The description ratchet covers parameter descriptions too, in every class. toolDescriptionsCarryNoLiterals.test.ts checks every description anywhere in an input schema, not only the tool's own text: three classes (a package, a customer-namespace object, a transport number) over both, six assertions. The transport class carries two shapes — <SID>K9… and a plain letters-and-digits number like ER121235, named by the user — and a message number, a release and a short SAP code (CTS_WBO_API 020, BASIS 816, TK127) sit in the self-check as text that must stay allowed. Two more refinements came out of running it:

  • A format placeholder is not a name. YYYYMMDDHHMMSS matched the customer-object pattern on its leading Y; a token built only from the letters of a date is allowed by rule, and the self-check states it.
  • The generated prefixes count. A function group's includes are L<group>… and its main program SAPL<group>, so the customer name starts one character in. The first pattern missed LZOK_FG_MCP01F01 in five descriptions and the widened one found them — the ratchet caught what the sweep did not.

  And it read one shape of schema only, which a reviewer found. Eight tools declare a flat map of Zod fields rather than JSON Schema — no properties wrapper, and in Zod 4 .description is a getter on the prototype, so Object.entries never saw it. CreatePackage and seven others were not checked at all: the literal was put back into CreatePackage's transport_request and every assertion stayed green. The walker now reads description by access instead of by enumeration and recurses through Zod's wrappers, and the coverage guard asserts PER TOOL — the only tools with no parameter text are the two that take no parameters (TAKES_NO_PARAMETERS), because a total of ">500" hid a whole shape reading as zero. Two things the fix immediately caught: SearchSource's packages named a package and a prefix mask in its examples, and ListServiceBindingTypes' response_format was a bare enum with no description at all.

Fixed

• A tool description is search text, and an incidental literal in it retrieves the wrong tools in bulk (#241). "Transport request optional for $TMP objects" sat in 30 Delete* descriptions, so any request mentioning $TMP pulled the delete tools into the top of a consumer's tool-RAG. Measured in cloud-llm-hub's retrieval — two collections, 0.7/0.3 fusion, translation, k=15, developer role:

  query	Delete* in the top 15, before	after
  "Які пакети в $TMP маємо?"	12	1
  "Create class … in package $TMP"	3, CreateClass third	1, CreateClass second
  create CDS / program / update in $TMP	3–4	1–2

  The wording without the literal was never worse on any query.

  $TMP objects reads local objects now, which is also the more accurate sentence: ABAP Cloud has no $TMP at all. The other incidental literals went with it — a sample mask in SearchObject, a message class in ReadMessageClassMessage, a namespace example in SearchSource. Parameter descriptions are untouched here: the calling model reads them, retrieval does not index them, and the literals in them are a larger replacement of their own (254 of 370 tools, 464 occurrences — the follow-up).

Added

• toolDescriptionsCarryNoLiterals.test.ts — the rule is kept by a test. No tool description names anything concrete: a package ($TMP, $ANY), a customer-namespace object or prefix (ZCL_DEMO, ZOK*, YFOO_BAR), or a transport number. A bare mask names nothing and stays allowed — Z*, Y*, /NS/Z*, any-namespace — and the test's own self-check pins both lists, so neither a new literal nor a regex tightened against a legitimate mask passes silently.

  Ranking is not what it measures: that is measured by loading the descriptions into a RAG and querying it, which is where the table above comes from. The test keeps the rule in the repository where descriptions are authored and where no RAG runs — without it the next $TMP returns and nothing here notices until a consumer's retrieval degrades. Green on arrival: 370 descriptions, none naming anything concrete.

Changed

• docs/user-guide/AVAILABLE_TOOLS*.md regenerated, which also picks up the CheckPackage wording 13.0.1 changed and did not regenerate.

Fixed

• mcp-abap-adt --version died on every installed copy. The launcher read path.join(__dirname, '..', '..', 'package.json'): from server/dist/ that reaches the repo root in a checkout — whose manifest is @mcp-abap-adt/lib, so it answered the LIBRARY's version — and from an installed package it reaches node_modules/@mcp-abap-adt/, the scope directory, which never has a manifest. So the CLI the MCP registry points at answered [MCP] launcher failed: ENOENT … node_modules/@mcp-abap-adt/package.json for anyone who installed 13.0.0. One level up is server/ in a checkout and the package root when installed, and in both it is @mcp-abap-adt/core's own manifest, which is what this CLI should state.

  Found by installing the published 13.0.0 tarball into an empty directory and running each bin — which is how @mcp-abap-adt/auth-broker 3.0.4 had found the same class of defect one release earlier, and 13.0.0 took that fix without performing that check. release:dry reporting Published: 2 Skipped: 0 does not cover it: packing proves a tarball builds, not that anything inside it runs. The three other bins in the installed tree were healthy — mcp-auth and mcp-sso 3.0.4, sap-abap-auth 9.4.2.

Added

• binSmoke.test.ts — a bin that does not start is now a failing test. It packs both packages, installs the two tarballs into a temporary directory and runs mcp-abap-adt --version from there, asserting it answers core's own version. Verified in both directions: it fails with the old path (the same ENOENT) and passes with the fix. SKIP_BIN_SMOKE=true skips it where packing is not available, and says so.

Migration: docs/MIGRATION-13.0.md.

No MCP tool changed — not a name, not a parameter, not an answer shape; the generated tool docs moved only their date, which is the check for that. What changed is what a refusal does: a number of them now arrive as refusals where they arrived as success.

Changed

• @mcp-abap-adt/adt-clients 22 → 23.0.4, and the release interprets nothing. Every member takes an options.analyse; no member applies a verdict of its own; the readings four of them had built in now ship as named strategies in @mcp-abap-adt/adt-strategies. 79 members grew the parameter in the same release.

  Here that took the call sites accepting an analyse from 275 to 513 in src/handlers alone, and every one of them carries a strategy now. handlerInvariants.test.ts resolves them from the type checker, so a call added without one fails the build; its exception list is gone, because all four entries were members whose tailored default 23 removed — the reason to pass nothing inverted into a reason to pass exactly analysePublication, analysePublicationLock, analyseMessageClassMessage(msgno) and analyseUnitTestStart.

  A call with no strategy has no verdict at all: whatever HTTP accepted is a success, including the refusals ADT embeds in a 200. That is the class of defect this repository has been closing since 8.10.0, and 23 moved the responsibility for it from the library to us.

• Every reading 22 applied by default is injected now — ATC, the profiler, the feeds, the executors, transports, object versions, run ids, and the read-edit-write of a message class. Most of those defaults are typed unknown, so the compiler flagged none of them: a result set left to its default answers the document, and a projection that reads .length or walks an array runs over a string without complaint.

• analyseLock refuses a 2xx that names no lock handle and returns SAP's answer as raw_body, on every lock including the LockX tools.

• A high-level delete runs checkDeletion first and sends no delete for an object the check reports as absent.

• The rest of the contract: interfaces-adt 9 → 11, the new interfaces-adt-connection 1.0.0 (IAbapConnection and IAdtWireResponse moved there), interfaces-network 2.0.0 as a direct dependency, interfaces-auth 1 → 2, auth-broker 2 → 3.0.4 (one options object, the token provider inside it as provider, and it requires refreshTokens), auth-providers 2 → 4.2.1, auth-stores 1.2.4, connection 9.2.1 → 9.4.2, adt-strategies 0.6.0, logger 0.4.1.

  The last two of those are packaging fixes in the family's own CLIs rather than anything this project calls differently: auth-broker 3.0.4 made @mcp-abap-adt/logger a runtime dependency, because mcp-sso imported it while it was only a dev dependency and died on Cannot find module from an installed tarball; logger 0.4.1 stopped printing PinoLogger initialization error at import, building its PinoLogger on first call instead. Both are worth taking here so this project's tree holds one copy of each at the fixed version.

• sap-rfc-lite ^0.1.0 → ^0.2.1 is load-bearing on RFC. It is the range connection itself declares, and adt-clients' ERRATA.md says why: a package can be saved only once per ABAP session (PAK/058 — the message says locked, but it is CL_PACKAGE's in-memory instance buffer, not an enqueue), and the connector is what keeps a non-stateful request out of the stateful context — over HTTP from 9.3.1, over RFC from 9.3.2, and from 9.3.4 on a reused conversation whose server context is reset after each call.

  0.2.1, not 0.2.0, and the difference is invisible at run time. 0.2.0 was packed from a stale lib/, so its JS client has no resetServerContext: the connector found no reset and fell back to a new RFC connection per stateless call — correct, and about 1010 s for a full RFC run instead of about 684 s. connection 9.4.2 raises its own minimum for exactly that, which also makes npm replace a 0.2.0 already in a lockfile. Declaring ^0.1.0 at the root, as this project did, put 0.1.x there for an RFC consumer to load; the root range has to move with the connector's.

• Third-party, in range: @modelcontextprotocol/sdk 1.30.1, axios 1.20.0, express 5.2.1, fast-xml-parser 5.11.1, pino 10.3.1, zod 4.6.5, dotenv 18.0.4, biome 2.5.14, jest 30.5.2, ts-jest 29.4.14, tsx 4.23.15.

  Not taken, and not an oversight: typescript 7 and @types/node 26 (on versions we follow SAP — ts-jest 29.4.14 still declares peerDependencies.typescript: ">=4.3 <7"), and lint-staged 17, which wants node >=22.22.1, above the floor this project declares. Node 26 is supported by auth-broker 3.0.2 and auth-providers 4.2.1 as an install fix — under Node 26 npm skips a release whose engines excludes it and silently takes an older major — and this project's open >=22.0.0 was never subject to that. It is still not a deployment target: the CF buildpack lists 20, 22 and 24.

Fixed

• GetInactiveObjects dropped every entry it was meant to list.

• GetObjectVersions answered {"ok":true} instead of the versions.

• --browser and --browser-auth-port had stopped reaching the login — ignored since auth-providers 2.0. AuthorizationCodeProviderConfig replaced both fields with an authorization strategy, and TypeScript runs no excess-property check on a const passed to a constructor, so every OAuth callback landed on the package default (61001) rather than the port the IdP has registered.

• An untyped deletion message is not an error, and every del:message of a deletion answer is read.

• LockClassTestClasses answered a response object as the lock handle — lockTestClasses answers an IAdtResponse in 23 where it answered the bare handle, and the call goes through an as any. UnlockClassTestClasses had the other half: a refused release reported as success.

• RuntimeListFeeds lists feed variants, read out of the feed list, and the profiler no longer wipes its own defaults for options a caller did not give.

• A package is saved once per ABAP session, and over RFC each save gets its own.

• The polygon and the suites that build their own fixtures stop reporting success over a refusal. 69 calls in src/__tests__ and src/lib/search-source had no strategy; 25 awaits dropped an IAdtResponse entirely, so ensureSharedPackage logged "Created" over a refused create and safeDelete — which classified a thrown message — reported deleted for every object a teardown failed to remove. Two unlocks in a finally ignored a refused release, the shape that left an enqueue on ZMCP_SHR_I_BDFL and locked every later run out; they report it by name now.

• A group activation is three requests, and only the third says what happened. POST /activation/runs answers 202 with the run id in Location and an empty body — which parses to zero messages and reads exactly like "no errors". So shared:setup logged "Group activation completed successfully" over eleven objects that stayed inactive, with not one SAP message to say why, and ActivateObjectLow's group path answered activated: null for every call. lib/strategies/activationRun.ts waits on getActivationRun (long-polling, bounded) until runs:status settles and then reads getActivationResults, where the chkl:messages are. The tool answers run_status, messages and a real activated now — null only for a run that has not settled — and the setup's retry is driven by the inactive list rather than by the accept. Re-run on a BTP trial 2026-09-28: runs:status finished, 8 message(s), all eight warnings (Key must have the type Inverted Individual on the database), Confirmed active: all 30 object(s).

• CheckPackage/CheckPackageLow required a super_package they never sent. The guard refused before any request, so a package with no parent — super_package: "", which is what a top-level package has — could not be checked at all: measured on a BTP trial 2026-09-28, the suite's own ZMCP_SHR_PKG answered isError: true with nothing on the wire while the other nine check tools passed. The member takes check({ packageName }, status?, options?), and the parameter's own description had said it does not reach the endpoint all along. It stays accepted and is no longer required; the surface ratchet records the relaxation rather than having its fixture edited.

• DEBUG_HTTP_WIRE — there was no HTTP wire log at all. @mcp-abap-adt/connection logs the session, the CSRF token and the critical section and nothing about a request, and logWire is an RFC transport option the HTTP transports do not take, so DEBUG_CONNECTORS answered nothing when the question was what did we send and what came back. Finding the CheckPackage cause needed a throwaway script that wrapped makeAdtRequest by hand. The switch lives in connectionFactory now, symmetric with DEBUG_RFC_WIRE: method, URL, params, headers with their values redacted by name, and bodies clipped at DEBUG_HTTP_BODY_CHARS, on stderr.

• A refused check says what it refused. expect(response.isError).toBe(false) printed Expected: false / Received: true and nothing else, so the CheckPackage refusal was invisible from the suite; all fifteen assertions in that file raise the handler's own payload now.

Removed

• fetchNodeStructure from @mcp-abap-adt/lib/utils — a deprecated stub that threw fetchNodeStructure not implemented in AdtClient yet on every call, for a member that has existed for several majors.
• src/lib/strategies/atcRun.ts — its answering() turned the AdtSAPError that resolveCheckVariant and createWorklist threw back into a response; both answer an IAdtResponse in 23, so it had no callers left.

Verified

• On premise, soft mode (PR #230): HTTP 47/47 suites, 105/105 tests; RFC 43/47, 100/105, the four failures all one finding — RfcTransport keeps one ABAP session for the connection's lifetime, so a stateless read after a create on the same connection answers 400 SADT_RESOURCE 007 while a fresh connection answers 200. That is the connector's decision to make, and connection 9.4.x with sap-rfc-lite 0.2.0 is where it is made.

• On a BTP trial, cloud, on this branch's own versions: the full soft-mode sweep, 48/48 suites and 108/108 tests, nothing left on the system. Two skips remain and both are the platform saying no — programs do not exist on ABAP Cloud. Within it: the auth-broker path (Session ready, every suite on a connection from the broker), the class unit-test workflow including the test-classes lock and its release, the feed descriptors and dump entries parsed, the group activation read from its run's results, and the BDEF+BIMPL suites creating, activating and deleting their own views.

• The dumps test reads the feed rather than one user's dumps. It required params.dumps_user and skipped without it, so on a machine whose config named no user it never ran; a user filter is not what it is about. It lists what the system shows, picks a dump and reads it — measured on the trial: 5 dump(s) in the feed. The only skip left there is a system with no dumps at all.

• Unit: 111 suites / 1704 tests. tsc --noEmit clean on all three projects, biome check clean, release:dry reports Published: 2 Skipped: 0.

Migration: docs/MIGRATION-12.0.md.

Added

• Five tools for a transport request's object list, which is what fr0ster/mcp-abap-adt#221 asked for: ReadTransportObjects, RemoveTransportObject, AddTransportObject, CreateTransportTask and ReadTransportActionLog.

  The problem they answer: deleting an ABAP object does not free its name. The CTS object-directory entry stays on the request that carried it — on purpose, so that transporting the request deletes the object in the target system too — and until it is detached, creating the same name again is refused with CTS_WBO_API 019, even passing that same request as the transport. The ways out were releasing the whole request, shipping everything else in it, or SE09 by hand. It was found the hard way: two shared function groups in an on-premise integration polygon became permanently unusable.

  Two things the tools cannot soften, both measured against an on-premise system on 2026-09-21:

  • position is required for a removal, and is what makes it do anything. Twenty-two objects asked for by pgmid/type/name alone each answered 200 with the usual echo document, and a re-read found all twenty-two still on the task. ReadTransportObjects is where the number comes from — there is nowhere else.
  • target_user is required for a task. Without tm:targetuser the server resolves an empty owner and refuses with 400 SCTS_ADT_MSG 009, "User does not exist in the system (or locked)" — two spaces where the name should be.

  And one thing the answers say rather than hide: a 200 from a user action is not evidence. The endpoint echoes whatever it was asked about, for an entry that exists and for one that never did, so RemoveTransportObject and AddTransportObject answer accepted: true, removed/added: "unknown" and the reading that would settle it — ReadTransportActionLog, or a re-read of the objects.

  Neither carries success, though every other write in this repository does. There it means the write happened; here it would contradict the field beside it, and a reader who stopped at success would skip the re-read that is the only thing establishing the outcome.

  Objects live on tasks: a request displays its tasks' entries and refuses to detach one, saying the entry "does not exist in request/task". Every tool says so where a caller will read it.

Changed

• BREAKING: the contract comes from the packages that declare it. @mcp-abap-adt/interfaces is gone from this project's dependencies. It last shipped 51.0.0 and nothing further will: adt-clients 22.0.0, connection 9.2.1 and adt-strategies 0.4.0 all take interfaces-adt@^9 directly, while the facade carries ^7. Keeping it would have put two majors of the contract in one tree, and they differ — 9's IAdtWireResponse extends IHttpWireResponse from interfaces-network@2, 7's does not.

  111 import statements in 108 files under src/, plus server/src/AuthBrokerConfig.ts, now name the package the contract lives in:

  package	names taken
  @mcp-abap-adt/interfaces-adt@^9.0.0	18, from IAdtError and IAdtResponse down to TRANSPORT_SEARCH_CONFIGURATIONS_URL
  @mcp-abap-adt/interfaces-utils@^1.1.0	ILogger, LogLevel
  @mcp-abap-adt/interfaces-auth@^1.2.0	ITokenRefresher, ITokenProvider, ITokenResult
  @mcp-abap-adt/interfaces-auth-sap@^1.0.0	SapAuthType, IServiceKeyStore, ISessionStore, IAuthorizationConfig, IConnectionConfig

  Nothing was renamed, so a consumer of this library changes an import path and installs the packages it names. interfaces-network is not among them because nothing here imports from it.

  @mcp-abap-adt/lib/utils no longer re-exports the contract. The star export was described as re-exporting the header constants; those live in interfaces-network now, and measured before removing it, nothing in this repository imported one through there. A consumer who did takes them from @mcp-abap-adt/interfaces-network directly — which is also where cloud-llm-hub already takes them from.

• BREAKING: a write's body has one channel, options.source. interfaces-adt@9 merged what used to be options.sourceCode (ABAP text), config.document (an XML metadata document), config.ddlCode, config.ddlSource, config.testClassCode and an options.xmlContent that nothing ever read. Every member in adt-clients 22 reads options?.source.

  - await domain.updateMetadata({ domainName, document: patched }, { lockHandle });
  + await domain.updateMetadata({ domainName }, { source: patched, lockHandle });

  This reaches a caller of the MCP tools not at all — no tool parameter changed — and a caller of @mcp-abap-adt/lib's handlers not at all either. It is recorded because of how it was found: the compiler flagged 8 of the ~38 call sites, the ones whose member has two overloads. The rest would have compiled and silently sent no body, so they were found by reading the contract instead of the error list.

• @mcp-abap-adt/adt-clients ^22.0.0, connection ^9.2.1, logger ^0.4.0, adt-strategies ^0.4.0. The adt-clients major is what carries the five transport members above, with the two required arguments their first run against a server measured. connection 9.2.1 also drops its optional kerberos dependency, so an install no longer builds a native module for a code path nothing reached.

  taskTypeChanged joins READING_BY_SLOT for changeTaskType, new in adt-clients 22. resultSets.test.ts is what found it — resultsFor throws on a slot with no reading, and every transport tool failed until it was declared.

• Dependencies removed that nothing imports, measured over every .ts, .js, .mjs and .cjs outside node_modules, plus the npm scripts and the husky hooks: xml-js and @mcp-abap-adt/header-validator (both runtime, so both shipped in the tarball), cors, express-rate-limit, serve-handler, commander and open, and the @types/diff and @types/js-yaml stubs that duplicate declarations those packages now ship themselves. pino/pino-pretty lose their duplicate dev entries and stay as runtime dependencies, because @mcp-abap-adt/logger declares them as peers and this repository's .npmrc sets legacy-peer-deps=true.

  jest-util looked like the same case and is not: with install-strategy=nested in .npmrc, ts-jest cannot find it unless this package declares it, and npm test fails before a suite runs. It stays, with that reason written beside it.

• Third-party majors: js-yaml 5, diff 9, dotenv 18, @modelcontextprotocol/inspector 2. All three runtime majors keep a CommonJS entry, which this build needs.

• Node and TypeScript versions follow SAP, and CLAUDE.md now says so. @types/node moves down to ^22, matching engines.node rather than the newest release, and the CI and release matrices run 22 and 24 instead of 22/25 and 22/24/25: SAP BTP Cloud Foundry supports 22 and 24, 20 was removed on 2026-04-30, and odd-numbered releases are not on the platform. typescript stays on ^6.x — no CAP package declares a typescript peer, but cds-typer and cds-types are developed on ^6.0.3, ts-jest 29.4.13 declares typescript: ">=4.3 <7", and cloud-llm-hub type-checks against this project's declarations on 6.

• overrides is gone. It pinned @hono/node-server to ^2.0.5 against an sdk that declared ^1.19.9; sdk 1.30.1 declares ^1.19.9 || ^2.0.5 itself, and a clean resolve of the sdk alone lands 2.1.1 with no help.

• The earlier statement of this release's dependency set — adt-clients ^20.0.0, adt-strategies ^0.3.0, interfaces ^46.0.1 — is superseded by the rows above; it was written when the five transport tools landed, before the contract split reached this repository.

  adt-strategies 0.3.0 brings analyseActivation reading activationExecuted as three states, so an activation with nothing to do is no longer answered as a refusal.

  Five slots arrive with the client — removedObject, addedObject, createdTask, actionLog, objects — and each gets a reading in READING_BY_SLOT, which is what resultSets.test.ts insists on: a slot adt-clients adds arrives at the table, not as an unshaped answer at a call site.

Added

• DEBUG_RFC_WIRE and DEBUG_RFC_BODY_CHARS — the RFC wire can be asked what it carried: the request headers and both bodies on the debug channel, off unless asked for.

  It exists because an investigation stopped for want of it. #222 reports CreatePackage losing superPackage over RFC while the identical call succeeds over HTTP, and the connector logged RFC → POST /sap/bc/adt/packages and a status — nothing about the document, so whether what this repository builds reaches SADT_REST_RFC_ENDPOINT intact could not be answered at all.

  Setting the variable is enough. RfcTransport writes only when it has both the option and a logger, and the server's own path builds its connection with none — so asking for the wire brings one at debug where nothing else supplied it. It writes to stderr: in stdio transport stdout carries JSON-RPC, and a debug switch that interleaves RFC HEADERS: … with the protocol would take the session down, which is worse than printing nothing. A logger the caller already has is used as it is and never redirected.

  An environment variable rather than an argument: the question is asked by whoever is sitting in front of a misbehaving on-premise system, not by code, and an argument would have to be threaded through every call site for a switch nobody sets in production. DEBUG_CONNECTORS already works this way.

  @mcp-abap-adt/connection ^8.1.0 is what makes it possible, and is also why the output is safe to paste into an issue: it replaces the values of Authorization, Cookie and anything matching token, secret, password, credential or an API key with [redacted], keeping the names. Bodies are clipped, not redacted — DEBUG_RFC_BODY_CHARS sets the ceiling, default 2000, 0 for the size alone and Infinity for all of it — so a body carrying a credential would still be logged. This is for a payload under suspicion, not for routine logging.

Added

• ABAP Test Cockpit, as three tools. RunATC composes the three calls an ATC run is — the check variant, a worklist for it, then the run — because AdtAtc deliberately stopped being IAdtRunnable in 19.0.0 and left the composing to whoever calls it. GetATCRunStatus answers the server's own word for the state and the one flag the client derives from it; GetATCFindings reads the worklist into findings a caller can act on — object, source position, priority, which check ran and what it said — with the counts per priority beside them. wait decides only whether the server holds the request: the findings are written into the worklist either way, so worklist_id is in every answer and run_id only when there is a run to poll. A worklist a run has not filled yet says so, rather than reading as a clean check.

• CheckMetadataExtension and CheckMetadataExtensionLow take version (active | inactive, default active). The DDLX checkruns endpoint does not fall back to whichever version exists, unlike the DDLS one: measured on a live system, an activated extension answers processed for active and notProcessed — "Error while reading the object … from the database" — for inactive, and an extension that was never activated answers the mirror image. The shipped default is inactive, so every activated extension was unanswerable through these tools. Reported by @eseuve in #178.

Fixed

• A blank cell no longer moves every value below it up a row. ADT sends an empty cell in a data preview as a self-closing <dataPreview:data/>, which the regular expression reading the document could not match. The cell was dropped, its column came back short, and every value below the first blank attached itself to the wrong record — silently, with nothing in the answer to say so. GetSqlQuery and GetTableContents both carried it. The reading is a parser now, injected on the query and contents slots rather than called from inside the handler, so entities are decoded as well and a short column is padded instead of shortening the rows after it. Found by @mpauspor (#179) and @anggakharisma (#180), each on their own system.

• The answers that had become refusals. Five behaviours turned into failures during the migration, each because something an adt-clients method used to do inside itself became this repository's job. A check reports its findings again instead of refusing on them (27 CheckX tools — and CheckFunctionGroup, which could not answer at all, since SAP reports MESSAGE(G46) for every function group); a pre-write check informs a write rather than being turned into a false failure by the wrong reading; a write that landed is a success even when the unlock afterwards was refused; a create that worked is confirmed by reading the object back; and a name that is not free is an answer rather than an error. Reported as #183 by @azzarabe for the function-group half.

• A lock nobody released now reaches the caller. When an unlock fails, the write still succeeded — and the note about the held lock travels on the answer that is actually returned, across the activation that follows, across the steps of a sequence, and out on an exception when the next call throws rather than answers. Previously it was reported instead of the result, then dropped on every path that answered something afterwards.

• The installation guides no longer recommend a 45-second deadline. .env.example shipped SAP_TIMEOUT_DEFAULT=45000 uncommented and the three platform guides told readers to copy it. @mcp-abap-adt/adt-clients removed that default deliberately: an aborted request is retried into a new session while the ABAP session underneath keeps the enqueue locks, leaving the object locked and inactive. Nothing in the code was cutting anything at 45 s — only our own documentation could arm it.

• Three development-scope advisories resolved in range — js-yaml (high), browserslist (high) and baseline-browser-mapping (moderate), all transitive under jest. One lock update rather than three separate bumps, and no overrides entry: an override pins a version the tree never asked for and keeps pinning it long after the advisory is history.

• AUTH_BROKER_PATH survives a Windows drive letter. The value was split on both : and ;, which tears D:\tools\project in two. Quiet on the same drive, invisible from another. Contributed by @mpauspor (#185).

Changed

• Legacy support (BASIS < 7.50) is parked, on parked/legacy-support, until it can be tried against a live system. available_in declared legacy on 142 tools and nothing here had ever run against such a system — an environment nobody has verified is a claim rather than a fact. The documentation page regenerates itself the moment any tool declares it again.

• detail: 'full' on a data preview answers the whole document's parse, not a chosen few of its fields, so nothing a caller could reach through the generic parse before is missing from it.

• The corpus gained the documents these changes are written against: an ATC worklist with findings in it, a data preview carrying both cell shapes, a transport listing with ?targets=true (where ADT inserts a tm:target level the flat listing has no sign of), and a DDLX checkrun in each version. A reading designed without one is a guess about a shape.

• Two patterns run through the whole migration and are worth stating once, in general, rather than only inside each task's own entry below.

  A read that used to answer success: true with a null body now answers an error. Every migrated read-modify-write handler — a domain, a data element, a package, a table's metadata, and the rest — goes through sequence(), whose whole discipline is stopping at the first failed step and handing back that step's own answer, untouched. A failed read used to mean "nothing to patch, so write whatever came back" on more than one pre-migration handler, which is the shape null/empty success: true answers came from; a read step that fails now stops the chain before any write is attempted, and the caller sees the read's own failure — origin, message, and (where the strategy fills it in) the server's own T100 key — instead of a write silently confirming nothing happened.

  A write that succeeded under a failed unlock now answers an error carrying operation: 'succeeded'. Every migrated high-tier write holds its lock through the shared withLock (see the eighteen-writes entry below): the body runs, and the release always runs after it, on every path out — a refusal from the body, a throw from it, or neither. When the body itself succeeded but the unlock is refused or throws, the object's change is real and on the server, but the call now answers a failure rather than the write's own success — with operation: 'succeeded' on the error payload, and a cleanup field carrying what the release actually said, so a caller does not read "failed" and conclude nothing happened. This is the most arguable decision in the spec this migration implements: a lock left behind on an object whose new content the caller can no longer see as a success. Surfaces in integration runs as new failures that are not regressions — see the pull request for a fuller account.

• Six unit-test tools gained the detail parameter, and what they answer changed with it. GetUnitTestStatus, GetCdsUnitTestStatus, GetUnitTest, GetCdsUnitTest, GetUnitTestResult and GetCdsUnitTestResult answer a JSON object built from a parsed document, which is the shape detail exists for — but they had been left without it, each hardcoding a level, so an audit keyed on the shared projection helper could not see them.

  They split two ways, and the change is not the same for both.

  The two status tools read the run's status directly. They used to answer success, the run id, a finished flag, and the whole parse as run_status, at every level. Now terse answers the run id, the finished flag and run_status as the status string itself — "FINISHED" rather than the parsed document; full answers the bare parse, without the surrounding envelope; and raw answers the wire document.

  The four polling tools go through the shared run poller. They used to answer the parse as run_status and, as run_result, the reading object itself with the wire document inside it. Now terse and full answer the parse in both fields and raw answers the wire text.

  Named fields did move, so a caller reading one is not automatically safe: success is gone from both status tools at every level, run_status is a string rather than an object at terse, and at full and raw the status tools answer a document with no named fields at all.

  No test pinned the old shapes, which is why this is recorded here rather than discovered by one.

• A compiler-pinned ledger of the eighteen adt-clients legacy-class members that ignore what a caller passes them, and what it found (#207, #208).

  AdtClientLegacy (BASIS < 7.50) substitutes four classes — AdtPackageLegacy, AdtUnitTestLegacy, AdtRequestLegacy, AdtUtilsLegacy — whose overridden members ignore arguments a caller passes them, because the factory that returns them is typed as the modern class: the compiler cannot see the mismatch, so nothing before this caught it. Not all eighteen drop the same thing, and calling all of it "the failure strategy" overstates nine of them: nine genuinely drop analyse, the caller-supplied failure verdict modern accepts and legacy ignores (five of AdtPackageLegacy's six members — create/readMetadata/ validate/updateMetadata/delete; four of AdtRequestLegacy's five — create/readMetadata/updateMetadata/delete). The other nine never accepted analyse on modern either: AdtPackage has no public read member at all (it implements metadata-readable, not readable, so legacy's read override is dead code from the type's perspective, not a dropped strategy); AdtRequest's list takes IListTransportsOptions, one configUri field and never an analyse; AdtUnitTest's run/ getStatus/getResult (three) and AdtUtils's activateObjectsGroup/ getTableColumns/getTableContents/getSqlQuery (four) never declared one either. What legacy drops on those nine is something else instead — a positional argument, a run identifier, a table name — a different failure mode. legacyExposure()/legacyEnabledHandlers() (scripts/lib/analyseOmissions.ts) resolve every handler legacy is offered (144 of 326) through the compiler's own type checker — not a syntax walk of specific call shapes, so a receiver reached through a shared helper, a destructured binding, or an awaited factory is seen the same as a direct chain — and name the exact (handler, factory, member) pairs that land on one, pinned by tests/fixtures/legacy-handlers.json and tests/fixtures/legacy-exposure.json and asserted in src/__tests__/unit/legacyExposure.test.ts.

  Sixteen pairs across thirteen files remain, and none can be moved to a sibling member that does accept a strategy: AdtPackageLegacy refuses every package operation (create/read/readMetadata/validate/ updateMetadata/delete) unconditionally, before any request is made, so GetPackage, ReadPackage, UpdatePackageLow and DeletePackageLow always answer a clean UNSUPPORTED_OPERATION refusal on legacy — no masking risk, but the operation reaches nothing, and their descriptions now say so. getUtils().activateObjectsGroup (ActivateObjectLow's multi-object path) never accepted a strategy on modern either — tracked already in #200, now cross-referenced from #207. Each affected tool's description states the limitation and the tracking issue.

  A second, separate ledger — legacyThrows(), pinned by tests/fixtures/legacy-throws.json — names every handler that reaches a factory AdtClientLegacy declares never available (getDomain/getDataElement/getStructure/getTable/getCdsUnitTest/…): the no-arg overload throws synchronously there, rather than answering a failure. Five tools declared legacy in available_in and reached one of these with no disclosure and no guard — CreateCdsUnitTest, GetCdsUnitTest, GetCdsUnitTestResult, GetCdsUnitTestStatus (getCdsUnitTest()) and GetStructuresList (getStructure()/getTable()) — and in three of the four CDS handlers the call sat before answer()'s callback with nothing catching it, so the throw would have escaped as an unhandled rejection rather than a tool error. All five now guard with a new isLegacyConnection() (src/lib/utils.ts) and refuse with a message before making any call, tested the way the program family's cloud guard is (src/__tests__/unit/legacyThrowingFactoryGuards.test.ts): refuses and never reaches the factory on legacy, reaches it on every other system. ActivateObjectLow/DeleteObjectLow also reach several of these factories for specific object types (getDomain/getDataElement/getStructure/ getTable/getBehaviorDefinition/getMetadataExtension), but only when a caller names that type through the generic dispatcher; recorded in legacy-throws.json, not guarded here.

  Building the ledger surfaced a third, more severe defect (#208, not fixed here — out of this ledger's scope): on a legacy system, RunUnitTest, CreateUnitTest and RunClassUnitTestsLow answer their run's result synchronously, but AdtClientLegacy.getUnitTest() returns a new instance every time it is called — even on the same client — and the synchronous result is cached on that instance, not on the client or the connection. So the client that answers GetUnitTest, GetUnitTestStatus, GetUnitTestResult, GetClassUnitTestStatusLow and GetClassUnitTestResultLow afterwards has no memory of the run and always refuses, regardless of whether it passed, failed, or errored — reusing the client across calls would not fix this; the factory call itself would still need to be the same one. Verified by construction against the installed @mcp-abap-adt/adt-clients package with a stub connection, no live SAP system needed: the same AdtClientLegacy instance, asked for getUnitTest() twice, answers the refusal from the second call even though nothing about the client changed. All eight affected tool descriptions (the five named above plus RunUnitTest, CreateUnitTest and RunClassUnitTestsLow themselves) now disclose this; the fix itself needs a design decision (embed the full result in the run tools' own answer on legacy, or cache the factory's own returned instance rather than the client) tracked in #208.

• The eighteen high-tier writes that hold a lock now release it through one shared withLock, and three genuine behaviour changes survive that migration.

  CreateStructure's syntax check now gates the answer; before, a genuine check failure was logger.warn'd only — the create still answered success and still went on to activate a structure with a known syntax problem. A refused check now fails the call, the same as every other check in this migration (analyseCheck, same as CreateDomain/CreateDataElement/ CreateBehaviorDefinition/CreateMetadataExtension already had).

  UpdateDdl, UpdateInterface, UpdateProgram, UpdateServiceDefinition, UpdateStructure and UpdateTable no longer carry an activation_warnings array in their terse (default) answer — the chkl:messages parse that array came from still happens, but only detail: 'full' or detail: 'raw' on the activation reads it now. Terse writes answer the literal string SUCCESS or a failure payload uniformly across every write tool in this migration; keeping one family's warnings in the terse channel while every other write tool's terse answer carries none would have been the inconsistency, not the fix.

  Everything else that changed shape during the underlying withLock migration and still holds after review: the long-polling wait for write visibility is restored, in its pre-migration position, on every handler that had one. The pre-write syntax check on UpdateClass, UpdateDdl, UpdateInterface, UpdateProgram, UpdateStructure and UpdateTable is restored too, gated by activate exactly as before — it runs only when activate is set, and a refusal there stops the write. No handler restores a post-unlock check: the pre-migration one existed only on these same six, its own catch never rethrew, and it is dropped rather than restored — every check in this migration now carries the check strategy, so a refusal is reported the way every other refusal is, and a check that could never have changed the answer is not worth the round trip. config.packageName is no longer sent on UpdateDomain/ CreateDomain/UpdateDataElement/CreateDataElement's metadata write — the shipped wire function never read it. CreateStructure no longer holds a lock while it creates — nothing between create and check ever wrote through it.

• ActivateObjectLow (multi-object activation) now answers acceptance, not a verdict. Activating a single object still reads a real pass/fail straight from ADT. Activating more than one object at once — or one object of a type this tool has no dedicated family for — goes through group activation, and ADT's answer there has always meant "the request was accepted and a run was queued," not "activation finished." The tool now says so explicitly: accepted (from whether a run id came back), run_id, and activated: null (there is no verdict on this path — acceptance is not completion). It does not wait for the run. To learn what actually happened, call GetInactiveObjects afterwards — an object still listed there did not activate — keeping in mind that a check made immediately after acceptance can still show an object as inactive that goes on to activate a moment later, since the run has not necessarily finished yet.

  Separately, and left open: group activation cannot judge a refusal the way every other write path in this migration now does — activateObjectsGroup accepts no error strategy at all, so a refusal ADT embeds in its answer is not caught on this path. Tracked as issue #200 in @mcp-abap-adt/adt-clients (giving the member the <E extends IAdtError> shape every sibling member already has); not fixed by this change.

• RuntimeRunClass and RuntimeRunClassWithProfiling now find a profiled run's trace themselves, and two fields they used to answer are gone. adt-clients 19 split the old composite runWithProfiling into scheduleTrace + runWithProfiler, neither of which waits for a trace or answers a traceId — a run only schedules and executes, and reading a trace is IProfiler.list()/read(), whenever the caller is ready. Both tools still advertise trace_id, max_trace_attempts and trace_retry_delay_ms, so this repository now composes what the library no longer does: it snapshots the profiler feed before scheduling, runs, then polls the feed for an id that was not in the snapshot — by set difference, ordered by the library's own compareRecordedAt (never by feed position, and never by sorting recordedAt as a string, both of which pick the wrong trace on a real feed). max_trace_attempts and trace_retry_delay_ms keep bounding that search exactly as before. A run that finishes before its trace is written still answers success, with trace_id absent rather than fabricated — poll RuntimeListProfilerTraceFiles or RuntimeAnalyzeProfilerTrace afterwards in that case.

  trace_lookup_uris is now accepted and ignored: adt-clients 19's IProfilerListOptions is { user?: string }, the whole interface, so there is nowhere left to put a URI — the profiler feed is one endpoint, not one per lookup URI.

  run_status and trace_requests_status are gone from both tools' answers and cannot come back under any of the three options considered: run and runWithProfiler answer IAdtResponse<string> and ClassExecutor takes no result strategy in its constructor, so there is no transport envelope left to read a status from.

• RuntimeRunProgram and RuntimeRunProgramWithProfiling (Task 23) no longer answer run_status, and RuntimeRunProgramWithProfiling gained an output field it never had before — neither was documented at the time. ProgramExecutor.run()/runWithProfiler() answer IAdtResponse<string> with no transport envelope to read a status from, the same reason the class tools above lost it; run_status is gone from RuntimeRunProgram's non-profiled answer, its profiled answer, and RuntimeRunProgramWithProfiling's answer — three answers across the two tools. Unlike the class tools, the program tools never had max_trace_attempts, trace_retry_delay_ms, trace_lookup_uris or a trace_id to begin with (program execution has always been fire-and-forget; a trace is located afterwards via RuntimeListProfilerTraceFiles), so none of those were removed. RuntimeRunProgramWithProfiling is deprecated and, by the rule this repository otherwise follows (a deprecated tool gains no field — applied correctly to RuntimeRunClassWithProfiling above), should not have started answering output. Recorded here rather than fixed by this entry.

• The rest of the profiler/dump/feed readers (Task 25) lose the same transport fields the class/program runners above lost, and two of them answer a genuinely different shape.

  RuntimeListProfilerTraceFiles used to hand response.data — the raw feed XML — to a hand-rolled parser and answer {success, status, payload: <whatever that parse produced>}. IProfiler.list() answers IAdtResponse<IAbapTraceEntry[]> now — already the parsed entries, with named fields (id, recordedAt, user, objectName, state, expiresAt, system, client, host, size, runtime/runtimeABAP/ runtimeSystem/runtimeDatabase, isAggregated, amdpFileSize) — so the tool now answers {success, count, entries: IAbapTraceEntry[]} instead, and drops the status field along with it (see below — it is not only the three tools originally named here). What that costs a caller: the old hand-rolled parse of the raw Atom feed carried whatever the document had — each entry's own <atom:title> and its <atom:link> navigation hrefs (to the trace's hitlist/statements/dbAccesses views and its delete link), and the feed's own metadata. IAbapTraceEntry is a curated, measured field list and carries none of that; a consumer that read those fields off the old freeform payload has nothing left to read them from.

  RuntimeGetProfilerTraceData and RuntimeAnalyzeProfilerTrace read the same view differently too: Profiler.getHitList/getStatements/ getDbAccesses are gone (IProfiler composes ITraceReading since 31.0.0 — one read(traceId, view, options) over three named views instead), and each view already answers its own typed, parsed shape (IAbapTraceHitList's entries, IAbapTraceStatements's statements, IAbapTraceDbAccesses's accesses) rather than the free-form attribute-prefixed object the old hand-rolled XML parser produced. Both tools' payload field now carries that typed shape. What that costs a caller, same as RuntimeListProfilerTraceFiles above: the old hand-rolled parse turned every attribute and element the raw XML document carried into JSON; IAbapTraceHitList/IAbapTraceStatements/ IAbapTraceDbAccesses are curated, measured field lists too (each one says so in its own doc in adt-clients' runtime/traces/types.d.ts), not the whole document — a consumer reading a field the old freeform payload had that one of these three types does not name has nothing left to read it from. RuntimeAnalyzeProfilerTrace's summary (total_records/ top_records) now reads the view's own named collection and ranks by that collection's real numeric field (grossTime.time for hitlist/statements, accessTime.total for db_accesses) — a fix-round-1 correction: the first pass walked the whole typed document for "anything with a number on it", which counted each row's own timing sub-object as a second row and ranked against a fixed list of key names ('runtime', 'calls', 'hits', …) that do not exist on any of the three typed shapes, so top_records was document order with roughly half its slots taken by timing objects rather than real entries.

  RuntimeListProfilerTraceFiles, RuntimeGetDumpById, RuntimeGetProfilerTraceData, RuntimeAnalyzeProfilerTrace and RuntimeCreateProfilerTraceParameters all drop the status field they used to answer (the HTTP status of the underlying request) — IAdtResponse carries no transport envelope to read it from any more, the same reason the class/program runners above lost run_status.

  RuntimeCreateProfilerTraceParameters also changes mechanism: Profiler.createParameters() is gone (IProfiler no longer composes ITraceScheduling as of 19.0.0 — scheduling a measurement moved onto IClassExecutor/IProgramExecutor, the same scheduleTrace member RuntimeRunClassWithProfiling already calls), now reached through AdtExecutor.getClassExecutor().scheduleTrace(...). profiler_id is still answered; status is not (see the paragraph above — this is one of the five, not an exception to it).

  RuntimeGetGatewayErrorLog's error_url branch was silently wrong before this task touched it: the pre-19 code handed the whole envelope object to error: with nothing unwrapping it, which — once gatewayErrorDetail() started answering IAdtResponse<T> instead of T directly — would have serialised as {"ok":true} (its getResult/getError methods dropped by JSON.stringify) rather than the actual detail document. No tsc error ever named this, because nothing in the old code read a field off the envelope that IAdtResponse didn't have. Fixed as part of this task's pass over the same file for its one genuine compile error (errors.length).

  RuntimeListFeeds's variants feed_type now refuses locally rather than calling the library at all: IFeedRepository.variants() gained a required category argument as of 19.0.0 (ADT's own endpoint always required one on the wire; the type simply did not say so before), and the frozen tool surface has no parameter this branch could take a real category from. A fix-round-1 correction: the first pass sent category='', reasoning that an empty category reaches "the same refusal" a categoryless call always did — but the pre-19 wire sent no category parameter at all, and the 19.0.0 wire always appends one, so category='' is a request nobody has measured, not a preserved behaviour. This feed_type now answers a local error explaining why, instead of guessing at what an unmeasured request would do.

  GetPackageTree (Task 25) wording: its pre-check for whether the target package can be read now says "could not be read" rather than "not found" for every refusal — a fix-round-1 correction. The pre-migration code branched on the wire status (404 said "not found"; anything else rethrew the original error unworded); readMetadata's default error strategy carries no status/code to branch on the same way, and the first pass here said "not found" for every refusal regardless of cause (a lock, a permission failure, a connection error), which is wrong for all but one of them.

  handleGetClassUnitTestResult/handleGetClassUnitTestStatus — a fix-round-1 correction, not a shape change: the first pass at these two Task-14-carve-out files cast the answer as AxiosResponse, believing getUnitTest()'s members still answered the pre-19 transport frame. They do not — ITestRunInformation already declares them IAdtResponse<T>, and the shipped class implements exactly that. IAdtResponse has no .data, so both tools answered success with empty content regardless of .ok — a refusal reported as success. Both now unwrap through answer(); neither tool's answer shape changes for a caller once the masking is removed. A fix-round-2 correction on top of that: fix round 1 dropped the outer try/catch both handlers had before it, so a thrown error from createAdtClient/restoreSessionInConnection (unreachable through the server, which always calls a handler inside its own guard, but reachable from a direct caller — a soft-mode integration test, or an embedder) would reject the returned promise instead of answering an error result. Restored.

• ListTransports asks which saved search to run. A transport listing is a saved search: list() takes a configUri, and when it is not given one it resolves a configuration itself — a second request, behind a protected member, whose answer no strategy of ours could read. On a system holding several saved searches that resolver throws, telling the caller to pass a configUri — which this tool has no parameter for and is not getting one.

  Fixed where it belonged: adt-clients 19.1.0 answers getRequest().searchConfigurations(options), one request with the caller's analyse over it. This handler asks, then lists with what it was given. The request count is unchanged for the ordinary one-configuration system; what changed is that both requests carry a strategy, and that a system with several is searched rather than refused — each of them, merged, capped at five, reported as searched_configurations and configurations_capped. A system with no saved search at all gets a sentence naming the endpoint that answered none, instead of a resolver's internal error.

  A new searchConfigurations slot came with that release, and READING_BY_SLOT declares a reading for it — the ratchet that exists so a slot adt-clients adds arrives in the table rather than unshaped at a call site is what caught it.

• An activation with nothing to activate is a success, and says so. SAP answers POST /activation with activationExecuted="false", generationExecuted="true" and no msg at all when the object is already active — activating a class twice, or a function group straight after creating one, since a function group is created active (adtcore:version="active" before anything is activated). Every such call used to answer an error.

  The verdict was wrong in @mcp-abap-adt/adt-strategies, and it was fixed there: 0.2.0 carries the reading and the corpus case that proves it (activation-nothing-to-activate). This repository ran its own narrowing strategy in the meantime, with a test asserting that the package still disagreed so the day it stopped would be a red test rather than a discovery — that test went red on the upgrade, and the local module is gone. All 46 handlers are back on the package's analyseActivation.

  What stays here is the consumer's half: a caller sees activated: false with nothing_to_activate: true beside it, rather than a bare false under a success.

• GetNodeStructureLow no longer reports an error for a node that is simply empty. The migration added a guard for the one ambiguity the corpus captures: /repository/nodestructure answers HTTP 200 with zero bytes both for a package that does not exist and for one that exists and holds nothing, and the two fixtures are byte-for-byte identical. For a DEVC/K parent the handler still pays one extra readMetadata round trip to tell those apart, and still forwards the package's own refusal when the package is gone. For every other parent type it used to throw, on the grounds that no fixture settled the question — which made an ordinary request answer client_threw. It is settled now: CL_ABAP_CHAR_UTILITIES, a standard SAP class, answers CLAS/OC node 0000 with zero bytes on a live system, so outside the package case a blank body is an empty node and is answered as one.