mcp-abap-adt

CreateCdsUnitTest

Creates an ABAP Unit test class for a CDS view from supplied test source, verifies the view supports test doubles, and activates the class in the specified package.

Instructions

Creates the ABAP Unit test class named by class_name for the CDS view named by cds_view_name, from test_class_source. The view is checked to support CDS test doubles, the test class holding the local test classes is created in the package named by package_name, and it is activated. Runs outside batch mode.

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": {
      "cds_view_name": "<cds_view_name>",
      "class_name": "<class_name>",
      "package_name": "<package_name>",
      "test_class_source": "<test_class_source>"
    },
    "name": "CreateCdsUnitTest"
  }
}

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	Name of the new global class that holds the tests.
`package_name`	Yes	Package of the new test class.
`cds_view_name`	Yes	CDS view under test (DDL source). Must be active and testable with test doubles.
`test_class_source`	Yes	ABAP source of the local test classes: definitions and implementations, FOR TESTING.
`transport_request`	No	Transport request, not a task. Required for a transportable package.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv16.0.0Oct 4, 2026

changedInput schema / properties / cds_view_name / description

Previous value: -"CDS view name to validate for unit test doubles."New value: +"CDS view under test (DDL source). Must be active and testable with test doubles."

changedInput schema / properties / class_name / description

Previous value: -"Global test class name (e.g., ZCL_CDS_TEST)."New value: +"Name of the new global class that holds the tests."

removedInput schema / properties / description

Removed value: -{
-  "description": "Optional description for the global test class.",
-  "type": "string"
-}

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_TEST_PKG_01, $TMP)."New value: +"Package of the new test class."

addedInput schema / properties / test_class_source

Added value: +{
+  "description": "ABAP source of the local test classes: definitions and implementations, FOR TESTING.",
+  "type": "string"
+}

changedInput schema / properties / transport_request / description

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

changedInput schema / required

Previous value: -[
-  "class_name",
-  "package_name",
-  "cds_view_name"
-]New value: +[
+  "cds_view_name",
+  "class_name",
+  "package_name",
+  "test_class_source"
+]

Changed3 schema fields changedMar 14, 2026

removedInput schema / properties / class_template

Removed value: -{
-  "description": "ABAP class template used for CDS unit tests.",
-  "type": "string"
-}

removedInput schema / properties / test_class_source

Removed value: -{
-  "description": "Local test class ABAP source code.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "class_name",
-  "package_name",
-  "cds_view_name",
-  "class_template",
-  "test_class_source"
-]New value: +[
+  "class_name",
+  "package_name",
+  "cds_view_name"
+]

First observedDec 29, 2025

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the burden and does disclose useful behavior: a test-double compatibility pre-check, creation of a class holding local test classes, activation, and the operational constraint that it runs outside batch mode. It omits whether an existing class is overwritten, how errors surface, and how transport_request interacts with package type.

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?

Three sentences, front-loaded with the create action and the parameter roles, then prerequisites and the batch-mode caveat. Nearly every clause earns its place; the batch-mode note is terse but informative.

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 6-parameter mutation with no annotations and no output schema, the description covers the create/activate sequence and one pre-check, but says nothing about the response shape, the transport_request parameter (required for transportable packages per schema), or failure modes.

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 baseline is 3. The description adds only marginal meaning beyond the schema — clarifying that class_name is the global class that holds the local test classes and that test_class_source feeds it.

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?

States a specific verb and resource: creates an ABAP Unit test class for a named CDS view. The CDS-view framing implicitly separates it from the sibling CreateUnitTest / CreateProgramUnitTest / CreateFunctionGroupUnitTest family, though it does not name those alternatives explicitly.

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?

Usage is implied by the resource type (CDS view unit test) and one prerequisite is stated (the view must support CDS test doubles), but nothing says when to choose this over CreateUnitTest or UpdateCdsUnitTest, or what to do if the class already exists.

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

Deploy Server