sap-ai-dev-toolkit 0.9.9911 → 0.9.9912

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

@@ -24,7 +24,7 @@ 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.
+   Use `GetStructure`, `GetTypeInfo`, and `GetMessages` for read-only DDIC shape, ABAP type, and SE91 message-text inspection. Use `CreatePackage` only when a new package is required and explicitly approved; transportable packages need a known software component and explicit transport. For transparent DDIC persistence, use `CreateTable`; it creates, writes generated DDL, and activates in one call. Neither tool creates 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.

package/.github/agents/abap-runtime-debugger.agent.md

@@ -19,7 +19,7 @@ You are a specialized ABAP runtime debugging and performance diagnosis agent for
    - **Logs/runtime evidence:** `GetApplicationLog` for bounded SLG1 evidence; `GetSystemInfo`, `GetFeatures`, `GetInstalledComponents`, and `GetConnectionInfo` for environment context. Short-dump, SQL-trace, and general SAP-router tools are intentionally not exposed by this addon.
    - **Debugger/breakpoints:** `SetBreakpoint`, `GetBreakpoints`, `DebuggerAttach`, `DebuggerGetStack`, `DebuggerGetVariables`, `DebuggerStep`, and `DebuggerDetach` when the session is authorized. Delete/listen helper tools are not part of the curated proxy surface.
    - **Call-flow and static analysis:** `FindDefinition`, `FindReferences`, `CompareSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, and `GetCDSElementInfo`.
-   - **Source/object inspection:** `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetFunction`, `GetFunctionGroup`, `GetProgram`, `GetInclude`, `GetInterface`, `GetPackage`, and `GetTable`.
+   - **Source/object inspection:** `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetFunction`, `GetFunctionGroup`, `GetProgram`, `GetInclude`, `GetInterface`, `GetPackage`, `GetStructure`, `GetTypeInfo`, `GetMessages`, and `GetTable`.
    - **Safe validation/data inspection:** `RunQuery` and `GetTableContents` only for safe read-only evidence on the target.
    - **Fix validation when code changes are authorized:** `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `GetInactiveObjects`, `Activate`, and `ActivateMultiple`.
    Tool modes and target systems vary; never infer availability from this static list.

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

@@ -23,7 +23,7 @@ You are a specialized SAP RAP service development agent for SAP Business Applica
    - **Validation:** `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `RunQuery`, `GetTableContents`, `GenerateRAPRegressionSuite`, and `RunRAPRegressionSuite` when safely applicable.
    - **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.
+   Tool modes and target systems vary; never infer availability from this static list. Use `GetStructure`, `GetTypeInfo`, and `GetMessages` for read-only DDIC/type/message metadata. If the target package must be created, use `CreatePackage` only after explicit approval; a transportable package requires its software component and transport. `CreateTable` does not create authorization objects.
 
    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.

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

@@ -20,7 +20,7 @@ Follow this workflow in order and use only capabilities actually exposed by the
    - **CDS/RAP/API analysis:** `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `RunQuery`, `GetTableContents`, `GenerateRAPRegressionSuite`, `RunRAPRegressionSuite`, `GetAPIReleaseState`, and `PlanABAPCloudMigration` for relevant dependencies and candidate APIs.
    - **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.
+   Tool modes and target systems vary. Do not infer availability from this map or static documentation. Use `GetStructure`, `GetTypeInfo`, and `GetMessages` for read-only DDIC/type/message evidence. Include `CreatePackage` only when package provisioning is required, with explicit approval and a known software component/transport for transportable packages.
 
    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.

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

@@ -11,6 +11,8 @@ description: Diagnose ABAP runtime failures using application logs, source/refer
 
 Query the active MCP server's live `tools/list` once; use the exact live tool name and schema for the target. Start with `GetApplicationLog`, source/object inspection (`SearchObject`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `ListDependencies`), and safe data inspection (`RunQuery`, `GetTableContents`). For an authorized debugger session, use `SetBreakpoint`, review registered breakpoints with `GetBreakpoints`, attach with `DebuggerAttach`, inspect with `DebuggerGetStack` / `DebuggerGetVariables`, step with `DebuggerStep`, and finish with `DebuggerDetach`. Avoid attaching to another user's session. Dump, trace, debugger-listen, delete-breakpoint, and arbitrary execution/RFC 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`.
 
+Use `GetStructure`, `GetTypeInfo`, and `GetMessages` as read-only aids when a failure depends on DDIC layout, ABAP type metadata, or SE91 text.
+
 1. Reproduce the reported failure when safe and within the requested target. Establish the observed input, outcome, and execution context before changing code.
 2. Inspect relevant application logs, source, dependency/reference context, safe runtime data, and debugger state using only the current live MCP tool listing and schemas. Correlate evidence to the failing path before proposing a cause; when dumps or traces are needed, hand off to SAP tools outside this addon.
 3. Keep debugger sessions and execution bounded. Set breakpoints sparingly; breakpoints registered with `SetBreakpoint` cannot be deleted through this surface (`DeleteBreakpoint` is not exposed), and `DebuggerDetach` releases the session. Do not change business data or attach to, interrupt, or alter another user's session. Prefer read-only diagnostics unless a change is specifically authorized.

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

@@ -11,7 +11,7 @@ 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.
+Use `GetStructure`, `GetTypeInfo`, and `GetMessages` for read-only DDIC shape, ABAP type, and SE91 text inspection. If a new package is required, use live `CreatePackage` only with explicit approval; a transportable package requires its software component and transport. For transparent DDIC persistence, use `CreateTable`, not `CreateObject`; it creates the table, writes generated DDL, and activates in one SAP call. Neither creator supports authorization objects; transport release/deletion is unavailable through this addon.
 
 ## Release compatibility and Clean ABAP naming
 

package/.github/skills/abap-runtime-analysis/SKILL.md

@@ -11,6 +11,8 @@ description: Analyze ABAP runtime incidents, debugger state, and performance sym
 
 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`, `GetInstalledComponents`, `GetContext`, `GetApplicationLog`, `DebuggerAttach`, `DebuggerGetStack`, `DebuggerGetVariables`, `DebuggerStep`, `DebuggerDetach`, `SetBreakpoint`, `GetBreakpoints`, `FindDefinition`, `FindReferences`, `CompareSource`, `ListDependencies`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetFunction`, `GetFunctionGroup`, `GetProgram`, `GetInclude`, `GetInterface`, `GetPackage`, `GetTable`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `RunQuery`, and `GetTableContents`. For authorized fixes, also use `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `Activate`, and `ActivateMultiple`. Dump, trace, arbitrary execution/RFC, and delete-breakpoint helpers 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`.
 
+Use `GetStructure`, `GetTypeInfo`, and `GetMessages` for read-only DDIC, ABAP type, and message-class context during runtime analysis.
+
 1. Establish incident boundaries: symptom, expected result, object/service, destination, user/session, input, time window, frequency, and whether reproduction/debugging is authorized.
 2. Gather read-only evidence first. Correlate logs, source/reference context, dependencies, debugger state, and data conditions by timestamp and object path. Do not start with source edits.
 3. For debugger sessions, set breakpoints sparingly — breakpoints registered with `SetBreakpoint` cannot be deleted through this surface because `DeleteBreakpoint` is not exposed — and attach only to the authorized session. Inspect stack and variables, step minimally, then detach; `DebuggerDetach` releases the session. Never attach to another user's unrelated session.

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

@@ -11,7 +11,7 @@ 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.
+Use `GetStructure` and `GetTypeInfo` to inspect DDIC-backed structure and type metadata when resolving CDS field dependencies. If a new package is needed, `CreatePackage` is state-changing: require explicit approval, and provide a software component plus transport for a transportable package. For a new transparent DDIC table backing a CDS entity, use `CreateTable`; it is not for CDS views, writes generated DDL, and activates in one SAP call. Authorization-object creation and transport release/deletion are unavailable through this addon.
 
 ## Language level and naming
 

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

@@ -11,7 +11,7 @@ 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.
+Use `GetStructure`, `GetTypeInfo`, and `GetMessages` for read-only DDIC/type/message metadata. If a new package is required, use `CreatePackage` only with explicit approval; transportable packages need a software component and transport. When a RAP business object needs a new transparent persistence table, use `CreateTable` before dependent CDS/behavior artifacts; it writes generated DDL and activates in one SAP call. Authorization-object creation and transport release/deletion are unavailable through this addon.
 
 ## Release compatibility and naming
 

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

@@ -11,7 +11,7 @@ description: Validate and deliver SAP RAP OData services, behavior implementatio
 
 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.
+Use `GetStructure`, `GetTypeInfo`, and `GetMessages` for read-only DDIC/type/message inspection. If the service needs a new package, use `CreatePackage` only with explicit approval; transportable packages require a software component and transport. If the 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. Neither creator supports 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,7 +11,7 @@ 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.
+Use `GetStructure`, `GetTypeInfo`, and `GetMessages` as read-only DDIC/type/message evidence. If a work package needs a new package, include `CreatePackage` only with explicit approval and the target software component/transport; it changes SAP state. For new transparent DDIC persistence, include `CreateTable` in the approved plan with its target package and transport; it writes generated DDL and activates in one call. Authorization-object creation and transport release/deletion are unavailable through this addon.
 
 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).

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 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. |
+| Upstream tools | Up to 64 | 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 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.
+The maximum fixture surface is 72 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.9911",
+  "version": "0.9.9912",
   "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',
+  'CreatePackage',
   'CreateTable',
   'CreateTransport',
   'DebuggerAttach',
@@ -106,14 +107,17 @@ export const PUBLIC_VSP_TOOLS = new Set([
   'GetInclude',
   'GetInstalledComponents',
   'GetInterface',
+  'GetMessages',
   'GetPackage',
   'GetProgram',
   'GetSource',
+  'GetStructure',
   'GetSystemInfo',
   'GetTable',
   'GetTableContents',
   'GetTransport',
   'GetTransportInfo',
+  'GetTypeInfo',
   'GetUserTransports',
   'GrepObjects',
   'GrepPackages',

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 68 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 72 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`
+- `CreatePackage`
 - `CreateTable`
 - `CreateTransport`
 - `DebuggerAttach`
@@ -40,14 +41,17 @@ Hidden upstream tools are not directly callable through the proxy. Local workflo
 - `GetInclude`
 - `GetInstalledComponents`
 - `GetInterface`
+- `GetMessages`
 - `GetPackage`
 - `GetProgram`
 - `GetSource`
+- `GetStructure`
 - `GetSystemInfo`
 - `GetTable`
 - `GetTableContents`
 - `GetTransport`
 - `GetTransportInfo`
+- `GetTypeInfo`
 - `GetUserTransports`
 - `GrepObjects`
 - `GrepPackages`
@@ -69,7 +73,7 @@ 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.
+`CreatePackage` creates a local package or a transportable package with an explicit transport; it changes SAP state and requires explicit approval. `CreateTable` creates a transparent DDIC table, writes its generated DDL source, and activates it. `GetStructure`, `GetTypeInfo`, and `GetMessages` are read-only metadata lookups. The upstream VSP package and transport mutation checks still apply. The pinned backend does not create structures, table types, or authorization objects.
 
 ## Hidden from direct proxy calls