mcp-abap-adt

CreateBehaviorImplementation

Creates a RAP behavior implementation class for a given behavior definition and package, returning an initial class shell; add FOR BEHAVIOR OF and includes later via UpdateClass.

Instructions

Creates the RAP behavior implementation class named by class_name for the behavior definition named by behavior_definition, in initial state: the FOR BEHAVIOR OF main source and the implementations include are written afterwards, the main source as a class source and the implementations include under the class lock. Recordable: in batch mode a call is recorded under the next number and answers with empty content; its answer is read by number after the batch ends.

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": {
      "class_name": "<class_name>",
      "behavior_definition": "<behavior_definition>",
      "package_name": "<package_name>"
    },
    "name": "CreateBehaviorImplementation"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	How much of the answer to return: "terse" (default, the fields you need to act), "full" (the whole parse), "raw" (the document as ADT sent it).	terse
`class_name`	Yes	Behavior Implementation class name.
`description`	No	Class description. If not provided, class_name will be used.
`package_name`	Yes	Package name
`transport_request`	No	Transport request number, not a task. Required for transportable packages.
`behavior_definition`	Yes	Behavior Definition name. The behavior definition must exist. Accepted for compatibility; not forwarded to the create request — the shipped create endpoint posts a metadata document (name/description/package) only. The class is bound to this behavior definition when its FOR BEHAVIOR OF main source is written, separately, via UpdateClass.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv16.0.0Oct 4, 2026

changedInput schema / properties / behavior_definition / description

Previous value: -"Behavior Definition name (e.g., ZI_MY_ENTITY). The behavior definition must exist."New value: +"Behavior Definition name. The behavior definition must exist. Accepted for compatibility; not forwarded to the create request — the shipped create endpoint posts a metadata document (name/description/package) only. The class is bound to this behavior definition when its FOR BEHAVIOR OF main source is written, separately, via UpdateClass."

changedInput schema / properties / class_name / description

Previous value: -"Behavior Implementation class name (e.g., ZBP_MY_ENTITY). Must follow SAP naming conventions (typically starts with ZBP_ for behavior implementations)."New value: +"Behavior Implementation class name."

addedInput schema / properties / detail

Added value: +{
+  "default": "terse",
+  "description": "How much of the answer to return: \"terse\" (default, the fields you need to act), \"full\" (the whole parse), \"raw\" (the document as ADT sent it).",
+  "enum": [
+    "terse",
+    "full",
+    "raw"
+  ],
+  "type": "string"
+}

changedInput schema / properties / package_name / description

Previous value: -"Package name (e.g., ZOK_LOCAL, $TMP for local objects)"New value: +"Package name"

changedInput schema / properties / transport_request / description

Previous value: -"Transport request number (e.g., E19K905635). Required for transportable packages."New value: +"Transport request number, not a task. Required for transportable packages."

Changed2 schema fields changedMar 14, 2026

removedInput schema / properties / activate

Removed value: -{
-  "description": "Activate behavior implementation after creation. Default: true.",
-  "type": "boolean"
-}

removedInput schema / properties / implementation_code

Removed value: -{
-  "description": "Implementation code for the implementations include (optional). Contains the actual behavior implementation methods.",
-  "type": "string"
-}

First observedDec 29, 2025

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the initial creation state, later source/include writing under class lock, and batch recording behavior, but it omits important caveats such as permissions, transport implications, and the schema-noted fact that behavior_definition is not forwarded to the create request.

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

Conciseness3/5

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

The description is front-loaded with the core action, but the first sentence is long and syntactically dense, making the initial-state and class-lock details hard to parse. The batch-mode sentence is useful but the overall structure could be clearer and more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation tool with no output schema, the description covers the initial creation state and batch behavior but does not describe what a normal non-batch call returns. It also does not clarify the relationship to UpdateClass for binding the behavior definition, though the schema supplies that caveat.

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 parameter meanings are largely provided by the schema itself. The description references class_name and behavior_definition and adds workflow context, but does not add substantive semantics beyond the schema, especially for detail, package_name, description, and transport_request.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: creates a RAP behavior implementation class identified by class_name. It also ties the class to a behavior definition, which distinguishes it from a generic class creation tool, though it does not explicitly compare itself to siblings like CreateClass or CreateBehaviorDefinition.

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

Usage Guidelines3/5

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

The description implies the intended workflow: create the class in initial state, then write the FOR BEHAVIOR OF main source and implementations include afterwards. It also explains batch-mode usage, but it does not explicitly say when to choose this over CreateClass or CreateBehaviorDefinition, nor when not to use it.

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

Deploy Server