Run all ABAP unit tests for a function group and return the result.
Run all ABAP Unit tests of a function group and return the result.
| 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 |
| function_group_name | Yes | Function group whose tests run. |
Changes observed during successful MCP inspections.
v16.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it omits key traits: whether running tests has side effects or mutates state, permission requirements, and whether execution is synchronous or can time out. All it discloses is that it runs all tests and returns a result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the verb and resource with no wasted words. It is appropriately sized for the tool but so terse that it leaves obvious informational gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter test-execution tool, the description is minimally adequate, but with no output schema present it should say more about what "the result" contains (pass/fail counts, messages, detail levels). It stops at restating the purpose without covering the return surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the function_group_name and the detail enum are already documented in the schema. The description adds nothing about parameter meaning or the terse/full/raw choice, so it meets the baseline-3 threshold rather than exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Run) and resource (all ABAP Unit tests of a function group) and clarifies scope with "all". It does not, however, explicitly distinguish itself from the close siblings RunFunctionModuleUnitTest, RunUnitTest, or RunCdsUnitTest, leaving the agent to infer the difference from the names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the context (running tests for a function group) but gives no when-to-use versus when-not-use guidance and never names an alternative such as RunFunctionModuleUnitTest or RunUnitTest. With so many near-identical Run*UnitTest siblings, the routing burden is left entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.