Skip to main content
Glama
Sign In
fr0ster

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

RunFunctionGroupUnitTest

Runs every ABAP Unit test in a function group and returns results; use async to wait within a bound and fetch by run_id, or sync for a finished result.

Instructions

[read-only] Runs every ABAP Unit test of the function group named by function_group_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 that returns the finished result. When runner is sync, 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_nameYesFunction group whose tests run.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv20.1.0
    • 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

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does a good job: it self-declares '[read-only]', explains that async runs are bounded and may return only a run_id whose result must be fetched separately, and discloses the non-obvious batch-mode recording behavior where the call returns empty content read later by number. It omits execution side effects (tests can create/modify data) and any mention that the function group must be active, so it falls short of a 5.

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 is front-loaded in the first clause, and nearly every clause carries behavioral information rather than filler. The final sentence is overpacked and grammatically broken ('When runner is sync, recordable: ...'), forcing a re-read, which costs it a point.

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?

There is no output schema and no annotations, so the description must cover behavior and return handling alone, and it does explain that results may come back inline or via run_id. What is missing is any description of the result payload (pass/fail counts, messages) and explicit naming of the companion tool used to read run_id, leaving the agent to guess at follow-up steps.

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% and the schema itself already spells out runner, detail, and the full scope subtree including foreign-test preview semantics. The description mostly restates the runner enum rather than adding syntax or default behavior beyond it, so the baseline 3 is right. The recordable/batch note is the only genuine addition, and even that is a sentence fragment ('When runner is sync, recordable: ...') rather than a parameter clarification.

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: runs every ABAP Unit test of the function group named by function_group_name and returns the result. Clear on scope (all tests in the group), but it never distinguishes itself from close siblings such as RunFunctionModuleUnitTest, RunProgramUnitTest, or RunUnitTest, so an agent must infer which Run* variant applies.

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?

It gives real guidance on the async-vs-sync choice ('suited to long suites') and explains how foreign tests behave differently under each runner. However, there is no guidance on when to use this tool rather than the sibling unit-test runners or GetUnitTestResult, which is the selection decision the agent actually faces.

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