Skip to main content
Glama

Copy Organizational Unit (EC01-style)

org_copy
Destructive

Copies or deletes a whole SAP organizational unit with all dependent customizing through SAP's standard entity copier, with a dry run that lists copied and retest-scope tables.

Instructions

Copy or delete a WHOLE organizational unit including all its dependent customizing, via SAP's standard entity copier (ECOP_ORG_UNITS_IN_THE_DARK) — the exact engine behind EC01/EC02/EC04…, run headlessly through the in-system Customizing Engine.

orgUnit values (org-key DOMAIN): BUKRS company code (EC01), WERKS plant (EC02), CACCD controlling area (EC03), VKORG sales org (EC04), VTWEG distribution channel (EC05), SPART division (EC06), VSTEL shipping point (EC07), LGNUM warehouse no. (EC09), EKORG purchasing org (EC13), LGORT storage location (EC14), MTART material type (EC15).

DRY RUN by default: lists the copier's dependent tables, then the RETEST SCOPE — every customizing table (delivery class C/G/E) keyed on the org domain that the copier does NOT copy, with live source/target row counts (source has rows, target none = retest first), and a summary of application/master-data tables (class A) keyed on it. Run the dry run again after the copy, same source and target, to diff the new unit against the source. commit: true performs the copy and commits.

TRANSPORT: the entity copier records onto a Customizing request it MINTS ITSELF and reports back — it cannot record into a request you supply (a passed transport is ignored). On commit set createTransport: true to acknowledge that; the copier names the request. The copier never overwrites: it fails if the target unit already exists. After the copy, patch unit-specific values (name, currency, country, …) with customizing_apply using values + onlyMissing: false. Needs engine v0.9.9+.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "orgUnit": "<orgUnit>",
      "sourceKey": "<sourceKey>"
    },
    "name": "org_copy"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionNo"copy" (default) duplicates source→target; "delete" removes sourceKey's unit with all dependent entries
commitNoActually copy (default: false = dry run)
icfPathNoSICF path of the engine (default: /sap/bc/zmcp_cust)
orgUnitYesOrg-key domain: BUKRS, WERKS, VKORG, VTWEG, SPART, EKORG, LGORT, CACCD, VSTEL, LGNUM, MTART
sourceKeyYesSource unit to copy from (e.g. plant 1000). For action: "delete" — the unit to remove.
targetKeyNoNew unit to create (e.g. 1010). Not used for delete. On a dry run it may already exist: the retest scope then compares source and target.
autoDeployNoAuto-deploy/update the engine class if missing or outdated (default: true)
retestScopeNoList the org-keyed tables the copier leaves alone, with source/target row counts (default: true for a copy, customizing first, then application data, within ~30 s). "customizing" or "application" counts only that part — for a re-run when a large unit (a company code has ~6,000 keyed tables) runs out of time. false = just the copier's table set.
connectionIdNoSAP system connection ID
createTransportNoRequired on commit in a recording client: acknowledge that the copier mints its OWN Customizing request (a supplied transport is not honored). The copier names the request; transportText is not applied. The new request number is reported on completion.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.16.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, it discloses that the copier never overwrites and fails if the target unit already exists, mints its own Customizing request and ignores a supplied transport, requires createTransport acknowledgment, and needs engine v0.9.9+. It also describes the dry-run retest scope and live row-count report, giving the agent essential behavioral context for a destructive operation.

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?

The description is long but front-loads the purpose and organizes the rest into dry-run, transport, and follow-up sections. Some parenthetical detail and overlap with schema descriptions make it denser than necessary, though the tool's complexity justifies most of its length.

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

Completeness5/5

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

For a destructive, non-idempotent tool with no output schema, it covers the dry-run report contents, commit behavior, transport-request constraints, overwrite failure mode, engine version requirement, and post-copy patching. This is enough for an agent to call it correctly without further context.

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

Parameters4/5

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

Schema coverage is 100%, but the description still adds meaning: it maps orgUnit values to EC transaction codes, explains sourceKey/targetKey behavior including delete and pre-existing dry-run targets, and clarifies retestScope's customizing/application split and timeout workaround. createTransport and transport-ignoring behavior are also described beyond the schema.

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

Purpose5/5

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

The opening sentence names a specific verb and resource — copy or delete a whole organizational unit with all dependent customizing — and identifies the exact engine, ECOPO_ORG_UNITS_IN_THE_DARK. It also enumerates supported org-key domains, making it clearly distinguishable from generic customizing tools.

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 explains the default dry-run/commit workflow, re-running the dry run after a copy, and using customizing_apply to patch unit-specific values afterward. It lacks an explicit comparison with customizing_create for creating a new org unit, but the operational guidance is otherwise clear.

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