abap-config-mcp

Self-Test Customizing Engine

customizing_selftest

Idempotent

Validates risky ABAP customizing engine internals non-destructively—dynamic table typing, sample reads, TABKEY construction, and transport simulation—to confirm the write path before commit.

Instructions

Non-destructively validate the engine's risky internals — dynamic table typing, sample read, flat TABKEY construction, and (if a transport is given) TR_OBJECTS_INSERT in SIMULATION mode — without writing data or recording any transport. Auto-deploys the engine class if needed. Run this after the first bootstrap to confirm the write path will work before any real commit.

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_selftest"
  }
}

Input Schema

Name	Required	Description
`table`	No	Customizing table to test against (default: TCURR — present on every system). Must have at least one row.
`icfPath`	No	SICF path of the engine (default: /sap/bc/zmcp_cust)
`transport`	No	If given, also validates transport recording in simulation mode (no actual recording)
`autoDeploy`	No	Auto-deploy/update the engine class if needed (default: true)
`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?

Adds substantial behavior beyond the annotations: simulation mode for transport recording, a no-write/no-record guarantee consistent with destructiveHint=false, and the notable side effect that the engine class may be auto-deployed (explaining why readOnlyHint is false). The only missing piece is what a failed vs. successful self-test reports, which matters for a validation tool with no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and non-destructive guarantee are front-loaded, followed by the specific checks, then the sequencing instruction last. Three sentences, no filler, and the parenthetical about transport correctly localizes the conditional behavior.

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?

Covers purpose, safety profile, side effects, prerequisites, and all parameters for a 5-param zero-required tool. What is left implicit is the shape of the result (per-check pass/fail), which would help since no output schema exists, but nothing needed to call it correctly is missing.

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 baseline would be 3, but the description adds causal meaning to two parameters: supplying a transport triggers simulated TR_OBJECTS_INSERT with no actual recording, and autoDeploy is described as deploying the engine class if needed. That is real semantic value about consequences, not just restatement.

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 ('validate') and the exact scope (dynamic table typing, sample read, flat TABKEY construction, simulated TR_OBJECTS_INSERT), and positions itself against sibling behavior ('Run this after the first bootstrap', 'before any real commit'). An agent can distinguish this from customizing_engine_bootstrap, customizing_apply, or customizing_engine_ping 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 Guidelines4/5

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

Gives explicit sequencing and intent: run after the first bootstrap, before any real commit, to confirm the write path. It does not name an alternative tool to use instead in other situations, so it stops short of full when/when-not routing, but the context is unambiguous.

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

Deploy Server