abap-config-mcp

Create Test Include

create_test_include

Create the local test include for an existing class so local test classes can be added; it does not add test code.

Instructions

Create the local test include of an existing class so local test classes can be added to it; it adds no test code itself. Write the tests afterwards with write_abap_object_source, activate, then run them with run_unit_tests. The tool locks the class, creates the include and unlocks it again, and records the change on a Workbench request (not needed in a local package). Transport: a transport you pass is checked and used; an object already locked into a request uses it; createTransport: true creates a new one; otherwise the transport already used for this piece of work (workItem, else this session) is reused; otherwise exactly one open request is used, several are listed for you to choose, none offers creation.

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": {
      "classUrl": "<classUrl>"
    },
    "name": "create_test_include"
  }
}

Input Schema

Name	Required	Description
`classUrl`	Yes	ADT URL of the class itself, not of an include (e.g. /sap/bc/adt/oo/classes/zcl_order_api)
`workItem`	No	Name of the piece of work (e.g. HPM, a ticket). Keeps using the same transport for it across calls and sessions until you pass another.
`transport`	No	Workbench request to record into. Checked before use; becomes the transport for this piece of work.
`connectionId`	No	SAP system connection ID
`createTransport`	No	Create a NEW Workbench request (only when you mean it; existing requests are preferred).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.16.2Nov 12, 2026

changedInput schema / properties / classUrl / description

Previous value: -"ADT URL of the class to add a test include to"New value: +"ADT URL of the class itself, not of an include (e.g. /sap/bc/adt/oo/classes/zcl_order_api)"

First observedv1.16.0Nov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false, idempotentHint=false and destructiveHint=false; the description goes well beyond that by disclosing the locking sequence (lock, create, unlock), the side effect of recording the change on a Workbench request, and the local-package exception. It also spells out the full transport resolution precedence, including the fallback behaviors when zero, one, or several open requests exist.

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 and the follow-up workflow are front-loaded, and every clause carries information. The final transport sentence is a long chained conditional that is denser than it needs to be and could be broken into a short list without losing content, which keeps it from a 5.

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 mutating, locking tool with no output schema, the description covers prerequisites, side effects, transport handling, and next steps thoroughly. The one real gap is that it never says what comes back — notably the include's name/URL that the agent needs in order to write test source into it afterwards — which the caller must infer or discover elsewhere.

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 real meaning: it clarifies that classUrl is the class itself and not an include (reinforcing the schema note), and it explains the precedence and persistence semantics of workItem, transport, and createTransport ("only when you mean it; existing requests are preferred"). The only unused parameter in the prose is connectionId, which the schema already labels adequately.

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?

The description states a specific verb and resource ("Create the local test include of an existing class") and immediately bounds the scope with "it adds no test code itself", which distinguishes it from source-writing tools like write_abap_object_source. An agent can tell exactly what this tool does and does not produce without consulting the schema.

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?

It gives an explicit ordered workflow: create the include here, write tests with write_abap_object_source, activate, then run with run_unit_tests. It also states the prerequisite (an existing class) and the exception case (Workbench request not needed in a local package), so both when-to-use and when-not are covered.

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

Deploy Server