Skip to main content
Glama
Sign In
fr0ster

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

RunFunctionModuleUnitTest

Runs ABAP Unit tests for a specified function module and returns results, supporting async runs for long suites and sync execution for immediate results.

Instructions

[read-only] Runs the ABAP Unit tests of the function module named by function_module_name and returns the result. runner async (default): the run is started and waited for within a bound, and a run that outlasts it returns its run_id, whose status and result are read by run_id; suited to long suites. runner sync: one request, addressed by function_group_name and function_module_name, that returns the finished result of every test of the module's function group. When runner is sync and function_group_name is given, 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.

Input Schema

NameRequiredDescriptionDefault
scopeNoWhich tests the run covers, sent with either runner. Foreign tests are test classes linked to the object by an ABAP Doc @testing relation (a function module's tests are often linked so). With runner sync they execute only with foreign_tests true: with the defaults (foreign_tests false, add_foreign_tests_as_preview true) SAP lists them as a preview, unexecuted. Runner async executes them with the defaults as well.
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
runnerNoasync (default): starts the run, waits for it within a bound and returns the result, or the run_id of a run that outlasts the bound, whose status and result are read by run_id; suited to long suites. sync: one request that returns the finished result.async
function_group_nameNoFunction group holding the function module; required by runner sync.
function_module_nameYesFunction module whose tests run.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv20.1.0
    • addedInput schema / properties / function_group_name
      Added value: +{
+  "description": "Function group holding the function module; required by runner sync.",
+  "type": "string"
+}
    • addedInput schema / properties / runner
      Added value: +{
+  "default": "async",
+  "description": "async (default): starts the run, waits for it within a bound and returns the result, or the run_id of a run that outlasts the bound, whose status and result are read by run_id; suited to long suites. sync: one request that returns the finished result.",
+  "enum": [
+    "async",
+    "sync"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / scope
      Added value: +{
+  "description": "Which tests the run covers, sent with either runner. Foreign tests are test classes linked to the object by an ABAP Doc @testing relation (a function module's tests are often linked so). With runner sync they execute only with foreign_tests true: with the defaults (foreign_tests false, add_foreign_tests_as_preview true) SAP lists them as a preview, unexecuted. Runner async executes them with the defaults as well.",
+  "properties": {
+    "add_foreign_tests_as_preview": {
+      "description": "List the foreign tests as a preview, unexecuted (default true).",
+      "type": "boolean"
+    },
+    "foreign_tests": {
+      "description": "Execute the foreign tests, those linked by an ABAP Doc @testing relation (default false).",
+      "type": "boolean"
+    },
+    "own_tests": {
+      "description": "Include the object's own tests (default true).",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
  2. Addedv16.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does so well: it marks the operation as read-only, explains async waiting and run_id fallback, sync request behavior, and batch recordable behavior. It still leaves some operational details implicit, such as error handling and side effects of test execution.

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?

The purpose is front-loaded and the content is dense with relevant invocation details. The recordable clause is somewhat run-on and the sync sentence is slightly awkward, but the description remains appropriately sized for a complex tool.

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

Completeness5/5

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

Given the absence of annotations and an output schema, the description is thorough: it covers return behavior for async and sync runners, the run_id follow-up path, function group addressing, and batch recording. An agent has enough information to invoke the tool correctly without additional context.

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 description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for runner and function_group_name, including the sync requirement and async run_id workflow. It adds less value for detail and scope because those are already well documented in the schema.

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: it runs ABAP Unit tests for a named function module and returns the result. It distinguishes the scope from sibling tools like RunFunctionGroupUnitTest and RunUnitTest by explicitly tying the run to function_module_name.

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?

It clearly explains when to choose runner async versus sync, including that async is suited to long suites. It does not explicitly compare this tool with sibling unit-test runners such as RunFunctionGroupUnitTest or RunUnitTest.

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