ARC-1

SAPManage

Destructive

Probe SAP system capabilities and manage DEVC packages, FLP catalogs/groups/tiles, and API release states before running feature-dependent operations.

Instructions

Probe and report SAP system capabilities. Use BEFORE operations that depend on optional features (abapGit, RAP/CDS, AMDP, HANA, UI5/Fiori, CTS transports, FLP). Also handles package (DEVC) lifecycle.

Actions:

"features": cached feature status (fast, no round-trip; id, available, mode, probedAt). "probe": re-probe now (feature probes + auth + discovery refresh). "cache_stats": object cache health.
"create_package" / "delete_package" / "change_package": DEVC lifecycle via ADT packages API.
FLP read: flp_list_catalogs, flp_list_groups, flp_list_tiles (catalogId). FLP write: flp_create_catalog, flp_create_group, flp_create_tile, flp_add_tile_to_group, flp_delete_catalog. Classic designer tile/target-mapping model, deprecated since S/4HANA 2023; Work Zone exposure v2 needs LADIs (SAPRead type=UIAD).
"set_api_state": release/revoke an object's API release contract (objectUri, or name+objectType; apiState defaults RELEASED, contract defaults C1 — C0 for SRVD, C3 for classic views). Write counterpart of SAPRead(type="API_STATE").

Returns features + systemType ("onprem"/"btp"); "available: false" means do NOT attempt dependent operations.

Input Schema

Name	Required	Description	Default
`name`	No	Package name (required for create_package and delete_package).
`tile`	No	Tile definition for flp_create_tile.
`title`	No	Title — required for flp_create_catalog and flp_create_group.
`action`	Yes	Action to execute. Read actions: features, probe, cache_stats, flp_list_catalogs, flp_list_groups, flp_list_tiles. Mutating package/FLP actions require writable safety config and write scope in authenticated mode.
`groupId`	No	FLP group/page identifier (required for flp_create_group, flp_add_tile_to_group).
`apiState`	No		RELEASED
`contract`	No	set_api_state: contract (default C1); SRVD uses C0, classic VIEW uses C3. Unsupported choices report supported contracts. SAP validates contract requirements.
`domainId`	No	Domain ID — required for flp_create_catalog (e.g., ZARC1_SALES).
`catalogId`	No	FLP catalog identifier — accepts either full ID (X-SAP-UI2-CATALOGPAGE:MY_CAT) or domain ID (MY_CAT). Required for flp_list_tiles, flp_create_tile, flp_add_tile_to_group, flp_delete_catalog.
`objectUri`	No	ADT URI of the object to move (e.g., /sap/bc/adt/oo/classes/zcl_my_class). If not provided, resolved automatically from objectName + objectType via search. For set_api_state: the object whose API release contract to set (or pass name + objectType instead).
`transport`	No	Optional transport request (corrNr) for create_package, delete_package, or change_package.
`newPackage`	No	Target package to move the object to. Required for change_package.
`objectName`	No	Object name to move (e.g., ZCL_MY_CLASS). Required for change_package.
`objectType`	No	ADT object type (e.g., CLAS/OC, DDLS/DF, PROG/P). Required for change_package. For set_api_state: object type of "name" when objectUri is omitted (e.g. CLAS, INTF, DDLS, TABL).
`oldPackage`	No	Current package of the object. Required for change_package.
`description`	No	Package description (required for create_package).
`packageType`	No	Package type for create_package (default: development).
`responsible`	No	Person-responsible: an existing ABAP user (XUBNAME, max 12 chars); an email is rejected. Defaults to the connection user; pass explicitly under principal propagation. BTP: auto-resolved from prior creates.
`superPackage`	No	Parent package for create_package (defaults to empty root package).
`apiVisibility`	No	set_api_state RELEASED: complete visibility selection; [] means none. Omit for SAP defaults. Read API_STATE first.
`recordChanges`	No	Whether the created package records object changes in transport requests. Defaults to true for non-LOCAL software components or when a transport layer is set; false for literal LOCAL packages.
`tileInstanceId`	No	Tile instance ID in the source catalog (required for flp_add_tile_to_group).
`transportLayer`	No	Transport layer for create_package (optional; required by some transportable landscapes).
`softwareComponent`	No	Software component for create_package (default: LOCAL on-prem, ZLOCAL on BTP).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.6.0Oct 17, 2026

addedInput schema / properties / apiState / default
```
Added value: +"RELEASED"
```

removedInput schema / properties / apiState / description

Removed value: -"For set_api_state: target state of the object's API release contract — RELEASED (mark released for ABAP Cloud / Clean Core) or NOT_RELEASED (revoke). Default RELEASED. Visibility (ABAP Cloud / Key User Apps) follows the contract's defaults. Read the current state first with SAPRead(type=\"API_STATE\")."

addedInput schema / properties / apiVisibility

Added value: +{
+  "description": "set_api_state RELEASED: complete visibility selection; [] means none. Omit for SAP defaults. Read API_STATE first.",
+  "items": {
+    "enum": [
+      "cloudDevelopment",
+      "keyUserApps"
+    ],
+    "type": "string"
+  },
+  "maxItems": 2,
+  "type": "array",
+  "uniqueItems": true
+}

changedInput schema / properties / contract / description

Previous value: -"For set_api_state: which release contract to set. Default C1 (Key-User/Cloud — the common clean-core contract). Object types support different contracts: e.g. service definitions (SRVD) only support C0, classic DDIC views only C3, behavior definitions and tables support C0+C1. If the object does not support the chosen contract, the error lists the ones it does."New value: +"set_api_state: contract (default C1); SRVD uses C0, classic VIEW uses C3. Unsupported choices report supported contracts. SAP validates contract requirements."

Changed2 schema fields changedv1.0.2Aug 3, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / responsible / description

Previous value: -"BTP only: the internal ABAP user (XUBNAME, e.g. CB9980000000) for the new package person-responsible. Auto-resolved from prior object creates if omitted; the IAS email is rejected."New value: +"Person-responsible: an existing ABAP user (XUBNAME, max 12 chars); an email is rejected. Defaults to the connection user; pass explicitly under principal propagation. BTP: auto-resolved from prior creates."

Changed4 schema fields changedv0.9.23Jun 29, 2026

changedInput schema / properties / domainId / description

Previous value: -"Domain ID for FLP catalog creation (e.g., ZARC1_SALES)."New value: +"Domain ID — required for flp_create_catalog (e.g., ZARC1_SALES)."

addedInput schema / properties / responsible

Added value: +{
+  "description": "BTP only: the internal ABAP user (XUBNAME, e.g. CB9980000000) for the new package person-responsible. Auto-resolved from prior object creates if omitted; the IAS email is rejected.",
+  "type": "string"
+}

changedInput schema / properties / softwareComponent / description

Previous value: -"Software component for create_package (default: LOCAL)."New value: +"Software component for create_package (default: LOCAL on-prem, ZLOCAL on BTP)."

changedInput schema / properties / title / description

Previous value: -"Title for FLP catalog/group creation."New value: +"Title — required for flp_create_catalog and flp_create_group."

Changed4 schema fields changedv0.9.21Jun 25, 2026

addedInput schema / properties / apiState

Added value: +{
+  "description": "For set_api_state: target state of the object's API release contract — RELEASED (mark released for ABAP Cloud / Clean Core) or NOT_RELEASED (revoke). Default RELEASED. Visibility (ABAP Cloud / Key User Apps) follows the contract's defaults. Read the current state first with SAPRead(type=\"API_STATE\").",
+  "enum": [
+    "RELEASED",
+    "NOT_RELEASED"
+  ],
+  "type": "string"
+}

addedInput schema / properties / contract

Added value: +{
+  "description": "For set_api_state: which release contract to set. Default C1 (Key-User/Cloud — the common clean-core contract). Object types support different contracts: e.g. service definitions (SRVD) only support C0, classic DDIC views only C3, behavior definitions and tables support C0+C1. If the object does not support the chosen contract, the error lists the ones it does.",
+  "enum": [
+    "C0",
+    "C1",
+    "C2",
+    "C3",
+    "C4"
+  ],
+  "type": "string"
+}

changedInput schema / properties / objectType / description

Previous value: -"ADT object type (e.g., CLAS/OC, DDLS/DF, PROG/P). Required for change_package."New value: +"ADT object type (e.g., CLAS/OC, DDLS/DF, PROG/P). Required for change_package. For set_api_state: object type of \"name\" when objectUri is omitted (e.g. CLAS, INTF, DDLS, TABL)."

changedInput schema / properties / objectUri / description

Previous value: -"ADT URI of the object to move (e.g., /sap/bc/adt/oo/classes/zcl_my_class). If not provided, resolved automatically from objectName + objectType via search."New value: +"ADT URI of the object to move (e.g., /sap/bc/adt/oo/classes/zcl_my_class). If not provided, resolved automatically from objectName + objectType via search. For set_api_state: the object whose API release contract to set (or pass name + objectType instead)."

Changed1 schema field changedv0.9.13Jun 9, 2026

addedInput schema / properties / recordChanges

Added value: +{
+  "description": "Whether the created package records object changes in transport requests. Defaults to true for non-LOCAL software components or when a transport layer is set; false for literal LOCAL packages.",
+  "type": "boolean"
+}

Addedv0.9.6May 28, 2026
Removedv0.9.3May 9, 2026
Addedv0.7.2May 2, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and destructiveHint=true. The description adds meaningful behavioral context beyond that: features is cached (fast, no round-trip), probe performs re-probe and auth/discovery refresh, set_api_state defaults to RELEASED/C1, and the 'available: false' rule governs dependent operations. It doesn't explicitly state that delete_package is destructive or its permanence, but overall it adds substantial operational detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the primary purpose followed by an action list. It is dense but well organized; the FLP deprecation note is relevant but somewhat verbose. Still, every part earns its place given the tool's breadth.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 24-parameter multi-action tool with no output schema, the description covers the main behaviors, defaults, and critical safety rule ('available: false' => do not attempt). It doesn't detail return shapes for package/FLP mutations or delete_package destructiveness, but overall it is complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 96%, so the schema already documents nearly all 24 parameters thoroughly, including defaults and enums. The description adds some cross-parameter context (e.g., set_api_state via objectUri or name+objectType, package name required for create/delete), but mostly the schema does the heavy lifting. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific multi-purpose tool: probing/reporting SAP capabilities and managing DEVC package lifecycle and FLP catalogs/tiles, plus set_api_state. The action list enumerates what it can do. It doesn't explicitly contrast with siblings like SAPRead or SAPDiagnose, though it does reference SAPRead(type=...) to route read counterparts elsewhere.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use it BEFORE operations depending on optional features and that 'available: false' means do NOT attempt dependent operations. It also notes the FLP classic model is deprecated since S/4HANA 2023 and that Work Zone v2 needs LADIs via SAPRead, which is useful routing. It doesn't cover package/FLP action alternative choices or when to use cache_stats vs probe beyond implied names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

SAPManage

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools