Skip to main content
Glama

Apply Customizing Change

customizing_apply
Destructive

Copy or delete SM30 customizing rows through the standard maintenance engine with a dry run by default; set commit to apply and record changes on a transport.

Instructions

Copy or delete customizing rows through the in-system engine, which drives the SM30 maintenance-view runtime (VIEW_MAINTENANCE_SINGLE_ENTRY) so FK checks, events, change docs and transport recording all run the standard way. DRY RUN by default — returns the exact rows affected. Set commit: true to apply. Use it for one table or view; use org_copy to copy a whole org unit, customizing_create for new rows with no source row, and customizing_plan_change for a quick preview without the engine.

action: "copy" (default) — duplicate rows from sourceKey to targetKey. action: "delete" — remove the entry whose keyField = targetKey (sourceKey not needed), recording the deletion onto the transport like an SM30 delete.

Delivery class behaviour: C / G / E — customizing + control tables: transport-based write. Provide a transport when committing. A — application data (e.g. /POSDW/STORE): direct MODIFY + COMMIT, no transport recording (copy only). Do NOT pass a transport for class-A tables.

The engine enforces S_TABU_DIS authorization on the target table.

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": {
      "table": "<table>",
      "keyField": "<keyField>",
      "targetKey": "<targetKey>"
    },
    "name": "customizing_apply"
  }
}

Input Schema

NameRequiredDescriptionDefault
tableYesTable name (e.g. /POSDW/PROF, /POSDW/STORE, TCURR, TVKO)
actionNo"copy" (default) duplicates source→target; "delete" removes the targetKey entry via the SM30 runtime, recording the deletion to the transport.
commitNoActually write (default: false = dry run)
valuesNoField overrides applied to every planned row after the key swap, e.g. { NAME1: "Z Retail", WAERS: "EUR" }. With sourceKey = targetKey and onlyMissing: false this patches an existing row in place.
icfPathNoSICF path of the engine (default: /sap/bc/zmcp_cust)
keyFieldYesKey field (e.g. PROFILE, WERKS, BUKRS, VKORG, or the full key field for delete)
workItemNoName of the piece of work (e.g. HPM, a ticket). Keeps using the same transport for it across calls and sessions until you pass another.
sourceKeyNoCopy: source value (reference config). Not used for action: "delete".
targetKeyYesCopy: target value to create. Delete: the key value of the entry to remove.
transportNoExisting open request to record into (the 'already chosen for this task' case — used as-is, no prompt). If omitted on a recorded commit and createTransport is not set, the tool returns an interactive prompt: the open Customizing requests to pick from PLUS the create options.
autoDeployNoAuto-deploy/update the ABAP engine class if missing or outdated (default: true)
onlyMissingNoOnly write rows absent from target (default: true)
connectionIdNoSAP system connection ID
transportTextNoShort description for the engine-created Customizing request (only used with createTransport: true). Omit to use an auto-generated text.
createTransportNoCreate a NEW Customizing request at commit (only when you mean it; existing requests are preferred). Combine with transportText to name it.
recordTransportNoRecord the write on a transport request (default: true for C/G/E). Set false for sandbox/test-data writes that should not be transported — transport must be omitted when false.
showAllTransportsNoWhen prompting for a transport, list ALL users' open requests instead of only your own (default: false = your own).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.16.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive=true, non-idempotent, openWorld, but the description goes well past them: it discloses the default dry-run safety, the engine runtime that performs FK checks/events/change docs, delivery-class-specific write behavior (transport-based vs direct MODIFY + COMMIT), the S_TABU_DIS authorization requirement, transport prompting behavior, and the auto-deploy side effect. This is exactly the extra context annotations cannot carry.

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?

Front-loaded with the dry-run default and the apply switch, then organized into scannable sections for action and delivery-class behaviour. It is longer than typical but nearly every line carries operational weight; only the action bullet overlaps the schema description.

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 17-parameter destructive mutation with no output schema, the description covers what an agent needs: the dry-run return (exact rows affected), the commit path, transport selection and prompting, authorization, and delivery-class branching. No material decision is left unexplained.

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%, so the baseline is 3, and much of the description's action/transport/values text restates the schema. It still adds real meaning beyond it: the delivery-class rules that decide whether a transport is required or must be omitted, and the onlyMissing/values combination that patches an existing row in place. The remaining gap is minor since per-parameter text is duplicated in 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?

Opens with a concrete verb pair (copy or delete) and a specific resource (customizing rows via the SM30 maintenance-view runtime), and immediately names the sibling alternatives (org_copy, customizing_create, customizing_plan_change) with the condition that selects each. An agent can distinguish this from customizing_plan_change or customizing_create without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance: dry run by default, set commit: true to apply, one table or view per call, and a named alternative for whole-org copies, new rows with no source row, and quick previews. It also states the when-not case (do not pass a transport for class-A tables) and the transport-prompt fallback.

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