sap-ai-dev-toolkit 0.9.9909 → 0.9.9911

package/.github/agents/abap-developer.agent.md

@@ -24,6 +24,8 @@ You are an ABAP development agent for SAP Business Application Studio (BAS). Fol
    - **Clean Core:** `PlanABAPCloudMigration` to batch-check release-state evidence for relevant ADT object URIs. Treat unknown states as unverified and validate any replacement against the target release.
    Tool modes and system capabilities vary. Do not infer tool availability from this map or static documentation.
 
+   For a requested transparent DDIC persistence table, use the live `CreateTable` tool (`create_table` on a single-destination proxy). It creates the table, writes generated DDL, and activates in one call; require explicit SAP-change approval and a known package/transport. It does not create authorization objects.
+
 4. **Use test-driven development.** ABAP code changes require a real test plan. Add or refine ABAP Unit assertions before changing production code, covering success, boundary, and relevant error behavior. Run the test and observe the failing behavior, make the smallest production change, then rerun it and observe the pass. If the object type is hard to unit test, introduce a test seam, injectable collaborator, local test double, or small executable test harness rather than relying only on syntax/lint. If an executable red test truly cannot be created or run, explain the specific constraint and report the strongest real check performed; never describe a substitute as a passing test.
 5. **Author locally first; check and lint before sending to SAP.** Create or change sources in the workspace as plain source files named `object.type.extension` (for example `zcl_report.clas.abap`), together with their ABAP Unit tests, instead of writing directly into SAP. Author only the plain source files; do not generate XML or other object-metadata sidecar files. Run the live `LintABAP` MCP tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when that LSP is configured; `LintABAP` analyzes only the submitted in-memory files and does not read workspace files or resolve dependencies. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Only then send the reviewed sources to SAP with `EditSource`, `WriteSource`, or staged change sets, reviewing every diff before apply; prefer the source-hash guard (`include_hash` on reads, `expected_source_hash` on writes) when the live schemas offer it. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.
 6. **Self-validate with runtime evidence.** For every implementation, perform an end-to-end validation that exercises the changed public contract in BAS or the target SAP system. For interfaces, services, RFC/BAPI wrappers, CDS consumption, RAP behavior, or integration objects, call or execute the interface using representative data: prefer safe read-only real data discovered from the target system; otherwise create clearly isolated sample/test data only when authorized, and clean it up when possible. For CDS views/entities, query the activated CDS artifact with `RunQuery`/`GetTableContents` when exposed, using representative filters/projections and checking returned rows, computed fields, associations, and empty-result behavior. Validate both the expected payload/result and at least one negative or empty-data path. Do not mark work complete based only on generated code or static checks.

package/.github/agents/rap-service-developer.agent.md

@@ -24,6 +24,8 @@ You are a specialized SAP RAP service development agent for SAP Business Applica
    - **Activation/service operations:** `GetInactiveObjects` to review pending inactive objects, then `Activate` and `ActivateMultiple` only when explicitly authorized by the task. Create a service binding with `CreateObject` (`SRVB/SVB`, with an explicit `binding_version`) and publish or withdraw it with `PublishServiceBinding` / `UnpublishServiceBinding` only when the task authorizes publication.
    - **Runtime diagnosis:** `GetApplicationLog`, `GetSystemInfo`, `GetFeatures`, `FindReferences`, `GetContext`, and read-only data queries.
    Tool modes and target systems vary; never infer availability from this static list.
+
+   When a RAP business object requires a new transparent persistence table, include `CreateTable` before dependent CDS/behavior artifacts. It creates the table, writes generated DDL, and activates in one call; require explicit SAP-change approval and a known package/transport. It does not create authorization objects.
 4. **Model RAP dependencies deliberately.** Inspect existing package conventions before editing. Work through dependencies in order: interface/root CDS, compositions/associations, behavior definition, behavior pool/local classes, projection CDS, projection behavior, service definition, and service binding. Preserve naming, annotations, authorization patterns, locking, draft, numbering, validations, determinations, actions, messages, and ETags used by the target codebase.
 5. **Use test-driven RAP development.** Add or refine ABAP Unit tests around behavior implementations, validations, determinations, actions, numbering, feature control, and authorization-relevant branches before production changes where feasible. Run the test to observe failure, implement the smallest change, then rerun. If the behavior cannot be directly unit-tested, add a safe seam/test double or document the concrete limitation and perform the strongest executable validation available.
 6. **Author locally first; check and lint before sending to SAP.** Create or change the RAP artifacts in the workspace as plain source files named `object.type.extension` (for example `zrap_i_booking.ddls.asddls` or `zrap_bp_booking.clas.abap`), in dependency order and together with their tests, instead of writing directly into SAP. Author only the plain source files; do not generate XML or other object-metadata sidecar files. Run the live `LintABAP` MCP tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when that LSP is configured; `LintABAP` analyzes only the submitted in-memory files. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Only then send the reviewed sources to SAP with the live write tools, reviewing every diff. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.

package/.github/agents/sap-solution-architect.agent.md

@@ -21,6 +21,8 @@ Follow this workflow in order and use only capabilities actually exposed by the
    - **Quality and risk signals:** `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, and `GetApplicationLog` when assessing existing behavior.
    - **Transport context:** `GetUserTransports`, `GetTransport`, `GetTransportInfo`, `ListTransports`, `CreateTransport`, `CheckTransportReadiness`, and `ListDependencies` only for planning or explicitly authorized preparation. Never claim transport release/deletion support; transport release is unavailable through this addon.
    Tool modes and target systems vary. Do not infer availability from this map or static documentation.
+
+   For an approved design requiring new transparent DDIC persistence, include `CreateTable` as a state-changing work-package step. It creates the table, writes generated DDL, and activates in one call; require explicit approval and a known package/transport. It does not create authorization objects.
 3. **Evaluate SAP standard and recommend APIs first.** Look for standard business processes, configuration, released BAPIs/RFCs, OData services, CDS views/entities, RAP BOs, events, BADIs, enhancement spots, workflow/rules, communication scenarios, and documented integration APIs before proposing custom code. Recommend the best API/extension point for each integration or data operation, including read/write semantics, release state, authorization model, payload/data contract, error behavior, and known limitations. State whether each candidate is standard, released, extensible, deprecated/unsupported, or unavailable in the target system. Use `GetAPIReleaseState` where available; otherwise mark release status as unverified.
 4. **Apply Clean Core and side-by-side rules.** Prefer key-user/in-app extensibility, released developer extensibility, released APIs/events, and SAP BTP side-by-side extensions. Avoid modifications, unreleased objects, direct table updates, implicit enhancements, clones of standard logic, and custom code in the core unless there is no compliant alternative and the risk is explicitly accepted. Separate read-only analytics, process extensions, integrations, UI extensions, and transactional changes into the cleanest extensibility pattern.
 5. **Design the target solution with best practices.** Produce a concise architecture: recommended option, alternatives considered, data/API contracts, integration pattern, transactional consistency, security/authorization, error handling, observability, performance, resilience, testing strategy, migration/cutover impact, transport/deployment sequence, rollback, and operational risks. Include exact objects/APIs inspected and gaps/blockers. Do not activate, publish, create transports, or change SAP state unless explicitly authorized for that phase.

package/.github/skills/abap-development/SKILL.md

@@ -11,6 +11,8 @@ description: Implement or change ABAP programs, classes, interfaces, function gr
 
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Locate objects and usages with `SearchObject`, `GrepObjects`, and `GrepPackages`; read with `GetSource` and `GetContext`; trace callers or dependencies with `FindDefinition` and `FindReferences`; compare workspace and SAP versions with `CompareSource`. Use `EditSource` for a localized change and `WriteSource` for a larger rewrite. Format with `PrettyPrint`; lint caller-supplied source with `LintABAP`; validate with `SyntaxCheck` and `RunUnitTests`, plus `RunATCCheck` when exposed and relevant. For Clean Core requirements, use `GetAPIReleaseState` on each relevant dependency. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+For a requested transparent DDIC persistence table, use live `CreateTable` (`create_table` on a single-destination proxy), not `CreateObject`. It creates the table, writes generated DDL, and activates in one SAP call; require explicit approval and a known package/transport. It does not create authorization objects; transport release/deletion is unavailable through this addon.
+
 ## Release compatibility and Clean ABAP naming
 
 Before authoring or changing ABAP, identify the target system's ABAP release/language version and the oldest supported ABAP release across all consumers. Use that as the syntax compatibility floor. On ABAP 7.40 or newer, actively consider modern ABAP syntax instead of defaulting to classic forms; verify each feature-specific minimum release against the compatibility floor. Inline declarations, constructor expressions/operators, table expressions, functional expressions, string templates, and modern Open SQL are examples to consider where applicable, not a promise that every target supports every construct. If the target or compatibility floor is unknown, resolve it with live system/capability or syntax-check evidence, or ask; do not guess. Keep unrelated legacy code in its existing style.

package/.github/skills/cds-development/SKILL.md

@@ -11,6 +11,8 @@ description: Implement, change, or analyze ABAP CDS data definitions and their d
 
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Locate views and usages with `SearchObject` and `GrepObjects`; read DDLS with `GetSource`; compare workspace and SAP versions with `CompareSource`; use `GetCDSDependencies` for upstream dependencies, `GetCDSImpactAnalysis` for consumers, and `GetCDSElementInfo` for element metadata. Trace references with `FindReferences`; edit via `EditSource` / `WriteSource`. Validate with `SyntaxCheck`, `RunATCCheck`, activation via `Activate` / `ActivateMultiple`, and read-only runtime queries via `RunQuery` or `GetTableContents` when exposed. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+For a new transparent DDIC table backing a CDS entity, use live `CreateTable`; it is not for CDS views. It writes generated DDL and activates in one SAP call, so require explicit approval and a known package/transport. It does not create authorization objects; transport release/deletion is unavailable through this addon.
+
 ## Language level and naming
 
 For DDLS/CDS source, establish the target CDS language level and capabilities, plus the oldest CDS level required by consumers. Do not infer CDS syntax support solely from an ABAP release; validate against the target's CDS capability or syntax check. For accompanying ABAP code, identify the oldest supported ABAP release and, on ABAP 7.40 or newer, actively consider modern ABAP syntax while checking each feature's minimum release. Use descriptive business/domain names for CDS entities and elements, following required SAP and project conventions. Apply Clean ABAP naming to ABAP identifiers where applicable; see the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).

package/.github/skills/rap-development/SKILL.md

@@ -11,6 +11,8 @@ description: Develop SAP RAP business objects, behavior, projections, and OData
 
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Check support and the connected destination with `GetSystemInfo`, `GetFeatures`, and `GetConnectionInfo`; locate objects with `SearchObject` and `GrepObjects`; inspect sources and structure with `GetSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `GetProgram`, and `GetInclude`. Edit with `EditSource` / `WriteSource` or reviewed `PrepareABAPChangeSet` / `ApplyABAPChangeSet`; validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `RunQuery`, `GetTableContents`, and `GenerateRAPRegressionSuite` / `RunRAPRegressionSuite` for GET-only OData smoke checks when exposed. Activate with `Activate` / `ActivateMultiple` only when requested. Create service bindings with `CreateObject` (`SRVB/SVB`; set `binding_version` explicitly because V2 is the default) and publish or withdraw them with `PublishServiceBinding` / `UnpublishServiceBinding` only when publication is requested. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+When a RAP business object needs a new transparent persistence table, use live `CreateTable` before dependent CDS/behavior artifacts. It writes generated DDL and activates in one SAP call; require explicit approval and a known package/transport. It does not create authorization objects; transport release/deletion is unavailable through this addon.
+
 ## Release compatibility and naming
 
 For ABAP source, identify the target release/language version and the oldest supported ABAP release across all consumers; use it as the syntax floor. On ABAP 7.40 or newer, actively consider modern ABAP syntax, but verify each construct's minimum release against that floor. If the floor is unknown, resolve it or ask rather than guessing. Apply Clean ABAP names where applicable: descriptive domain terms, `snake_case`, nouns for classes/interfaces, verbs for methods, plural collection names, and no needless abbreviations or type-encoding prefixes. Preserve SAP-required and existing RAP/CDS object conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).

package/.github/skills/rap-service-delivery/SKILL.md

@@ -9,7 +9,9 @@ description: Validate and deliver SAP RAP OData services, behavior implementatio
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once and use the exact live names and schemas. Prefer these curated addon tools when available: `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `RunQuery`, `GetTableContents`, `GenerateRAPRegressionSuite`, `RunRAPRegressionSuite`, `GetApplicationLog`, `GetInactiveObjects`, `Activate`, `ActivateMultiple`, `CreateObject` (service bindings), `PublishServiceBinding`, and `UnpublishServiceBinding`. Read UI5 apps already deployed to the ABAP repository with `UI5ListApps`, `UI5GetApp`, and `UI5GetFileContent`. UI5 deployment, dump, trace, arbitrary execution/RFC, and code-coverage tools are not exposed by this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once and use the exact live names and schemas. Prefer these curated addon tools when available: `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `RunQuery`, `GetTableContents`, `GenerateRAPRegressionSuite`, `RunRAPRegressionSuite`, `GetApplicationLog`, `GetInactiveObjects`, `Activate`, `ActivateMultiple`, `CreateTable`, `CreateObject` (service bindings), `PublishServiceBinding`, and `UnpublishServiceBinding`. Read UI5 apps already deployed to the ABAP repository with `UI5ListApps`, `UI5GetApp`, and `UI5GetFileContent`. UI5 deployment, dump, trace, arbitrary execution/RFC, and code-coverage tools are not exposed by this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
+
+If the RAP service requires a new transparent persistence table, use `CreateTable` before dependent CDS artifacts. It creates the table, writes generated DDL, and activates in one call; require explicit approval and a known package/transport. It does not create authorization objects.
 
 1. Confirm target destination, package, transport/temporary target, RAP object names, and whether activation/publication/data mutation is authorized. Transport release and deletion remain out of scope for this skill; prepare and report transport context only.
 2. Plan before implementing. Present the RAP object chain to create or change in dependency order, the ABAP Unit test approach, the local authoring and validation approach (workspace files plus `LintABAP` and LSP), and the SAP write/activation/publication steps with the authorizations they require. Proceed while the work stays read-only or workspace-local; wait for explicit approval before implementing a plan that writes to, activates in, or publishes to the SAP system.

package/.github/skills/sap-sdlc-orchestration/SKILL.md

@@ -11,6 +11,8 @@ description: Orchestrate the SAP delivery lifecycle from requirement analysis th
 
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Investigate system and repository context with `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `GetInstalledComponents`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `CompareSource`, and dependency tools (`ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`). Validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, runtime queries (`RunQuery`, `GetTableContents`), `GetApplicationLog`, and `GenerateRAPRegressionSuite` / `RunRAPRegressionSuite` when exposed. Use transport tools for readiness planning only; never claim transport release/deletion support because transport release is unavailable through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+For a work package requiring a new transparent DDIC persistence table, include live `CreateTable` in the approved plan with its target package and transport. It writes generated DDL and activates in one SAP call, so treat it as a state-changing step requiring explicit approval. It does not create authorization objects.
+
 1. Convert the requirement into an SDLC plan: discovery, fit-gap/API recommendation, architecture, implementation packages, test strategy, validation gates, activation/publication gates, transport readiness, deployment notes, rollback, and operations handover.
 2. Require a planning phase before implementation for every work package. Each package starts with a presented plan of objects, tests, and validation steps; no SAP state-changing package proceeds before the user approves it. Every implementation package includes a local quality gate: sources are authored locally as plain workspace source files (`object.type.extension`; do not generate XML or other object-metadata sidecar files) and must pass `LintABAP` plus LSP checks before they are sent to the SAP system. ABAP/RAP packages must state the target release/language version and oldest supported ABAP release across consumers. On ABAP 7.40 or newer, actively consider modern ABAP syntax and verify each feature against that floor; establish the CDS language level separately for DDLS. Include existing SAP/project naming conventions and Clean ABAP naming guidance, linking the [Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
 3. Automate what the active MCP tools safely allow. Read and analyze the system, propose standard APIs and extension points, generate implementation briefs, request or delegate coding work, run checks, collect evidence, and iterate until acceptance criteria are met or a blocker is proven.

package/inventory.md

@@ -6,14 +6,14 @@ This inventory reflects the current SAP AI Dev Toolkit proxy behavior in `src/mc
 
 | Status | Count | Notes |
 | --- | ---: | --- |
-| Upstream tools | Up to 59 | Curated from the child tool list and exposed in lowercase snake_case, unprefixed (`get_source`) on single-destination servers; a destination slug prefix (`demo-abap_get_source`) appears only when one server fronts multiple destinations. |
+| Upstream tools | Up to 60 | Curated from the child tool list and exposed in lowercase snake_case, unprefixed (`get_source`) on single-destination servers; a destination slug prefix (`demo-abap_get_source`) appears only when one server fronts multiple destinations. |
 | Local lint tool | 1 per destination | `LintABAP` analyzes caller-supplied ABAP source in memory; it is exposed publicly as `lint_abap`. |
 | Workflow tools | Up to 6 per destination | Review/apply change sets, transport evidence, Clean Core release assessment, and read-only RAP regression suites. Some are exposed only when their upstream capabilities are registered. |
 | Convenience mapping | Dynamic | `GetApplicationLog` maps to the upstream `SAP(action="analyze", type="application_log")` operation when the SAP router is registered. |
 | Intentionally filtered tools | Dynamic | Destructive, broad-router, trace, and unsupported operations are hidden from direct calls. |
 | Mode-dependent | Dynamic | Focused/expert mode and backend capabilities determine which tools are registered. |
 
-The maximum fixture surface is 67 tools per destination when expert-mode capabilities and all local workflows are available. Multiple selected destinations create separate MCP servers; this add-on cannot inspect VS Code's aggregate tool budget or per-chat tool binding.
+The maximum fixture surface is 68 tools per destination when expert-mode capabilities and all local workflows are available. Multiple selected destinations create separate MCP servers; this add-on cannot inspect VS Code's aggregate tool budget or per-chat tool binding.
 
 ## Known upstream tools
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sap-ai-dev-toolkit",
-  "version": "0.9.9909",
+  "version": "0.9.9911",
   "description": "SAP AI development toolkit for BAS, ABAP, RAP, CAP, HANA Cloud, Fiori, UI5, and MCP",
   "author": "Gurkan Yilmaz",
   "type": "module",

package/src/mcp-proxy.mjs

@@ -78,6 +78,7 @@ export const PUBLIC_VSP_TOOLS = new Set([
   'ActivateMultiple',
   'CompareSource',
   'CreateObject',
+  'CreateTable',
   'CreateTransport',
   'DebuggerAttach',
   'DebuggerDetach',

package/tools.md

@@ -1,6 +1,6 @@
 # Curated SAP tools exposed through the BAS proxy
 
-The proxy no longer advertises every tool provided by the SAP runtime. To keep the developer-lifecycle MCP surface manageable, each generated one-destination server exposes a curated set of upstream tools plus local workflow tools (currently 67 tools when all upstream capabilities are registered).
+The proxy no longer advertises every tool provided by the SAP runtime. To keep the developer-lifecycle MCP surface manageable, each generated one-destination server exposes a curated set of upstream tools plus local workflow tools (currently 68 tools when all upstream capabilities are registered).
 
 The names below are the logical tool names. Publicly they are exposed in lowercase snake_case without a prefix (`get_table_contents`, `run_query`) because each generated MCP server is scoped to one destination; only when a single server fronts multiple destinations does each name gain its destination slug (`demo-abap_get_table_contents`) to stay unambiguous. BAS/VS Code chat tool references bind only lowercase identifiers, so mixed-case names never reach the model.
 
@@ -12,6 +12,7 @@ Hidden upstream tools are not directly callable through the proxy. Local workflo
 - `ActivateMultiple`
 - `CompareSource`
 - `CreateObject`
+- `CreateTable`
 - `CreateTransport`
 - `DebuggerAttach`
 - `DebuggerDetach`
@@ -68,6 +69,8 @@ Hidden upstream tools are not directly callable through the proxy. Local workflo
 - `UnpublishServiceBinding`
 - `WriteSource`
 
+`CreateTable` creates a transparent DDIC table, writes its generated DDL source, and activates it. The upstream VSP package and transport mutation checks still apply. Authorization-object creation is not supported by the pinned backend and remains unavailable.
+
 ## Hidden from direct proxy calls
 
 Broad/destructive surfaces such as object deletion, SQL trace, arbitrary SAP router calls, transport release/delete, RFC execution, debugger listen/delete-breakpoint helpers, and one-off generator/update helpers are intentionally not advertised by the BAS proxy. UI5 repository writes are hidden too: the ADT filestore only reads UI5 apps, so deploy them with SAP Fiori tools instead.