Skip to main content
Glama
Sign In
mcp-abap-adt

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

UpdateCdsUnitTest

Writes and activates ABAP Unit test class source for an existing CDS view test class, replacing its local test classes so CDS view tests can be updated.

Instructions

Writes test_class_source as the ABAP Unit test classes of the CDS view test class named by class_name. The local test classes in the test class are rewritten, 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": {
      "class_name": "<class_name>",
      "test_class_source": "<test_class_source>"
    },
    "name": "UpdateCdsUnitTest"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNoHow 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_nameYesTest class of the CDS view. Must already exist.
test_class_sourceYesABAP source of the local test classes: definitions and implementations, FOR TESTING. Replaces what the include holds.
transport_requestNoTransport request, not a task. Required for a transportable object.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv16.0.0
    • changedInput schema / properties / class_name / description
      Previous value: -"Global test class name (e.g., ZCL_CDS_TEST)."New value: +"Test class of the CDS view. Must already exist."
    • 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 / test_class_source / description
      Previous value: -"Updated local test class ABAP source code."New value: +"ABAP source of the local test classes: definitions and implementations, FOR TESTING. Replaces what the include holds."
    • 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 object."
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that existing local test class content is replaced (a destructive rewrite), that activation is triggered as a side effect, and that the call runs outside batch mode. It stops short of stating permission/lock requirements or error behavior.

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?

Three short sentences, each earning its place: the primary write, the rewrite/activation side effect, and the batch-mode constraint are all front-loaded with no filler.

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?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers the essential behavioral facts (overwrite semantics, activation, non-batch execution) that the schema does not. Only lock/permission behavior and failure modes are left unaddressed.

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 explains all four parameters including the detail enum and transport_request. The description reinforces what class_name and test_class_source denote but adds no format or syntax 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.

Purpose4/5

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

Specific verb (writes) plus a precise resource: the ABAP Unit test classes of the CDS view test class named by class_name. It distinguishes itself from CreateCdsUnitTest/DeleteCdsUnitTest by being the write-in-place operation, though it does not explicitly name the neighboring UpdateUnitTest or UpdateLocalTestClass alternatives.

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 rather than stated: the description says the local test classes 'are rewritten' and the object is activated, which tells an agent this is an in-place update of an existing test class, and 'Must already exist' appears only in the schema for class_name. No explicit when-to-use/when-not or pointer to Create/Run/Delete siblings.

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

Deploy Server

Other Tools