abap-config-mcp

Create Customizing Rows

customizing_create

DestructiveIdempotent

Create customizing table rows from explicit field/value maps with full or composite keys and per-row values, without a source row to copy. Runs dry by default; set commit to write via SM30.

Instructions

Create new customizing rows from explicit field/value maps — full keys (including COMPOSITE keys) and distinct per-row values, with NO source row to copy from. This is what customizing_apply (a single-key copy) can't express: e.g. storage locations T001L (key WERKS+LGORT) each with their own LGOBE description.

Each entry in rows is one row as a { FIELD: value } object and must include all key fields. Rows are written through the SM30 view runtime (VIEW_MAINTENANCE_SINGLE_ENTRY, INS→UPD fallback) so FK checks, events, change docs and transport recording run the standard way; INITIAL/blank non-key fields are allowed.

DRY RUN by default — returns the planned rows. Set commit: true to write. onlyMissing (default true) skips rows whose key already exists — idempotent create. recordTransport: false → direct write, no transport (sandbox/test data); omit transport then. Delivery class C/G/E records onto a Customizing request (provide transport or createTransport); class A writes directly. Enforces S_TABU_DIS on the 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>",
      "rows": "<rows>"
    },
    "name": "customizing_create"
  }
}

Input Schema

Name	Required	Description
`rows`	Yes	Array of rows; each a { FIELD: value } object including ALL key fields, e.g. [{ WERKS: "GHDC", LGORT: "0001", LGOBE: "Goods Receipt" }].
`table`	Yes	Table name (e.g. T001L, T001W). Its generated SM30 maintenance view is resolved automatically for recorded writes.
`commit`	No	Actually write (default: false = dry run returning the planned rows)
`icfPath`	No	SICF path of the engine (default: /sap/bc/zmcp_cust)
`workItem`	No	Name 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.
`transport`	No	Existing open Customizing request to record into (used as-is, no prompt). If omitted on a recorded commit and createTransport is not set, the tool returns an interactive prompt.
`autoDeploy`	No	Auto-deploy/update the engine class if missing or outdated (default: true)
`onlyMissing`	No	Only create rows whose key is absent (default: true = idempotent). false also updates existing rows.
`connectionId`	No	SAP system connection ID
`transportText`	No	Short description for the engine-created Customizing request (only used with createTransport: true).
`createTransport`	No	Create a NEW Customizing request at commit (only when you mean it; existing requests are preferred). Combine with transportText to name it.
`recordTableKeys`	No	For a table with no maintenance view (e.g. T006/T006A, normally CUNI): write it directly and record the row keys as R3TR TABU on the transport. Skips the dedicated transaction's checks — supply complete rows.
`recordTransport`	No	Record the write on a transport (default: true for C/G/E). Set false for a direct, untransported sandbox write — transport must be omitted then.
`showAllTransports`	No	When prompting for a transport, list ALL users' open requests instead of only your own (default: false).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.16.0Nov 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantive context beyond them: writes go through the SM30 view runtime with FK checks, events, change docs and transport recording, INITIAL/blank non-key fields are allowed, and S_TABU_DIS authorization is enforced. It also discloses the dry-run-first safety posture, which meaningfully qualifies the destructive hint.

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 core distinction and an example, then progressively discloses defaults and transport behavior. Slightly long and partially redundant with the schema descriptions of onlyMissing, commit and recordTransport, but every sentence carries operative information.

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 14-parameter mutation tool with no output schema and destructive semantics, the definition covers the important risks: dry run by default, idempotency, transport recording, authorization, and the recordTableKeys escape hatch. What it omits is modest — the shape of the dry-run response and error/failure behavior are only gestured at rather than described.

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

Parameters5/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, but the description adds real cross-parameter meaning the schema cannot express: how onlyMissing interacts with idempotency, how recordTransport:false forces transport omission, and how delivery class determines request routing. The rows-format explanation with a worked example reinforces the schema's own description rather than merely restating it.

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?

States a specific verb and resource ('Create new customizing rows from explicit field/value maps') and immediately differentiates from the named sibling customizing_apply ('a single-key copy'), giving a concrete example (T001L with composite key WERKS+LGORT). An agent can select between the two without opening either 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?

Explicit about when to use it (no source row to copy, composite keys, distinct per-row values) and when the sibling applies instead. Also states the operational defaults and their branches: dry run by default with commit:true to write, onlyMissing default true for idempotent create, recordTransport:false requiring transport omitted, and the C/G/E vs class A transport routing.

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

Deploy Server