abap-config-mcp

Deploy/Update Customizing Engine

customizing_engine_bootstrap

Idempotent

Installs or updates the SAP Customizing Engine by creating, overwriting and activating class ZCL_MCP_CUST_ENGINE and report ZMCP_CUST_WRITE in place, then activates both objects.

Instructions

Install or update the Customizing Engine in the SAP system: creates or overwrites the class ZCL_MCP_CUST_ENGINE and the batch writer report ZMCP_CUST_WRITE, writes their source and activates both. Run it once to install and again when the engine version changes; the first install then needs a one-time SICF service registration (handler ZCL_MCP_CUST_ENGINE), which the result spells out. Use it to update the engine in place (default package $TMP); for a first setup, or to make the engine transportable, use engine_deploy instead, which calls this and also registers SICF. The customizing tools with autoDeploy update the engine themselves, so this is rarely needed. Verify with customizing_engine_ping; remove with customizing_engine_cleanup. Writes repository objects and needs development authorization (S_DEVELOP).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "customizing_engine_bootstrap"
  }
}

Input Schema

Name	Required	Description
`transport`	No	Workbench request for the class and report (e.g. DEVK900123); needed when the package is transportable
`packageName`	No	Package for the new objects (default: $TMP, local and not transportable; use a transportable Z package such as ZORDER_API to move the engine between systems)
`connectionId`	No	SAP system connection ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.16.2Nov 12, 2026

changedInput schema / properties / packageName / description

Previous value: -"Target package (default: $TMP; use a transportable Z package for production)"New value: +"Package for the new objects (default: $TMP, local and not transportable; use a transportable Z package such as ZORDER_API to move the engine between systems)"

changedInput schema / properties / transport / description

Previous value: -"Transport request for the class (required if package is transportable)"New value: +"Workbench request for the class and report (e.g. DEVK900123); needed when the package is transportable"

First observedv1.16.0Nov 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false/openWorldHint=true/idempotentHint=true/destructiveHint=false; the description adds the concrete mutation surface (creates or overwrites two repository objects and activates them), the authorization prerequisite (S_DEVELOP development authorization), and the non-obvious one-time SICF service registration for handler ZCL_MCP_CUST_ENGINE that is surfaced in the result. The disclosed overwrite semantics are consistent with the idempotent-update annotation rather than contradicting it.

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?

Purpose is front-loaded in the first clause and every subsequent sentence carries information (install cadence, SICF step, alternative tool, verification/cleanup, authorization) with no filler. It is a dense single paragraph, though, and splitting prerequisites and alternatives into distinct sentences would improve scannability.

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?

With no output schema, the description still tells the agent what the result contains (the SICF registration instruction) and how to verify success via customizing_engine_ping. For a mutating, authorization-gated deployment tool the remaining gap is minor: no detail on failure modes if the package is transportable but no transport is supplied.

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 transport, packageName and connectionId with the $TMP default and the transportable-package caveat. The description reinforces the default package $TMP and the in-place update framing but adds no syntax, format or edge-case detail beyond the schema, so the baseline 3 applies.

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 ("Install or update the Customizing Engine") and names the exact artifacts produced (class ZCL_MCP_CUST_ENGINE, report ZMCP_CUST_WRITE, source written and activated). It also explicitly separates itself from engine_deploy and the autoDeploy path of the customizing tools, so an agent can pick it out of a crowded sibling list.

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 (run once to install, again on version change, to update in place with default package $TMP), when-not-to-use (first setup or transportable deployment should use engine_deploy; autoDeploy customizing tools handle it themselves, so rarely needed), plus the follow-up tools customizing_engine_ping for verification and customizing_engine_cleanup for removal. Guidance covers sequencing and exclusions rather than just context.

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

Deploy Server