abap-config-mcp

Plan Customizing Change (Dry Run)

customizing_plan_change

Read-onlyIdempotent

Preview, from ADT reads alone, which customizing rows copying an org-unit key to another would insert, including maintenance view, delivery class and transport object; no writes or engine needed.

Instructions

Preview, from ADT reads alone, the rows that copying customizing from one org-unit key to another would insert (e.g. plant 1000 to a new plant 2000), with the maintenance view, delivery class and transport object. Nothing is written and the in-system engine is not needed, so it works before the engine is installed. Use it for a quick look at one table; for the plan of the write you will actually run, use customizing_apply without commit (its dry run goes through the engine and the SM30 runtime), and org_copy for a whole org unit across all its tables.

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": {
      "objectName": "<objectName>",
      "keyField": "<keyField>",
      "sourceKey": "<sourceKey>",
      "targetKey": "<targetKey>"
    },
    "name": "customizing_plan_change"
  }
}

Input Schema

Name	Required	Description
`keyField`	Yes	Org-unit key field (e.g. WERKS, BUKRS, VKORG)
`sourceKey`	Yes	Source org-unit value (reference config)
`targetKey`	Yes	New org-unit value to create config for
`objectName`	Yes	Maintenance view or table name
`onlyMissing`	No	Only plan rows absent from target (default: true). Set false to plan a full overwrite.
`connectionId`	No	SAP system connection ID

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.16.0Nov 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond readOnlyHint/idempotentHint, it discloses a genuinely non-obvious precondition: the result comes from ADT reads alone, nothing is written, and the in-system engine is not required, so it works before the engine is installed. That is real context the annotations cannot convey. It stops short of describing pagination, size limits, or what a 'no rows' result looks like.

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?

Two sentences, front-loaded with the capability and the 'nothing is written' guarantee before the routing guidance; nearly every clause carries information. The first sentence is dense and stacks three payload fields plus a parenthetical example, which slightly slows scanning but does not waste words.

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?

There is no output schema, so the description carries the return-value burden and does so by naming the planned row fields and the transport object. Combined with the no-engine/read-only constraint and the sibling routing, an agent has enough to call this correctly and interpret the result.

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 100%, so the schema already documents keyField, sourceKey, targetKey, onlyMissing, and connectionId. The description adds only a concrete direction example (plant 1000 to a new plant 2000), which confirms source-to-target orientation but does not add syntax or edge-case meaning. Baseline 3 is appropriate.

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 description opens with a specific verb and scope ('Preview, from ADT reads alone, the rows that copying customizing from one org-unit key to another would insert') and names the concrete payload fields (maintenance view, delivery class, transport object). An agent can distinguish this read-only preview from customizing_apply and org_copy 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?

It states when to use it ('a quick look at one table') and explicitly routes to alternatives: customizing_apply without commit for the real write plan, and org_copy for a whole org unit across all tables. The named alternatives carry the reason they differ (engine/SM30 runtime vs ADT reads), so the choice is not left to inference.

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

Deploy Server