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

With no annotations, the description carries the load and does disclose real behavior: the state change (inactive version becomes active) and the non-obvious batch-mode contract where the call returns empty content and the answer must be fetched by number after the batch ends. It stops short of covering error cases, permissions, or transport implications.

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?

Two dense sentences with the purpose front-loaded and the batch-mode caveat second; nothing is padded or redundant.

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?

A mutation tool with no annotations and no output schema, and the description still conveys the state effect and the batch-answer retrieval pattern, which is the main thing an agent could get wrong. Missing only preconditions and failure behavior, which are comparatively minor here.

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 coverage is 100%, so both parameters are fully documented in the schema, including the enum values and defaults for 'detail'. The description only echoes the 'name' parameter and adds nothing about 'detail', so this is the baseline case where the schema does the work.

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 (Activates) and resource (RAP behavior definition) plus the effect ('inactive version is in force'), which is more than a restatement of the name. It doesn't explicitly differentiate itself from the numerous sibling Activate* tools (e.g. ActivateObjects, ActivateServiceDefinition), so an agent must infer the distinction from the resource name alone.

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?

Usage is implied: call it when a behavior definition has an inactive version that must be brought into force. There is no explicit statement of when not to use it or whether the generic ActivateObjects would also cover this case, and no prerequisites are named.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose a non-obvious behavior: in batch mode the call is recorded under a sequence number and returns empty content that must be read later via BatchAnswers. That is genuinely useful beyond the schema. It still omits error/permission behavior and whether an already-active class fails, which keeps it below 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, and the core action is front-loaded before the batch caveat. The second sentence is dense and slightly convoluted ('recorded under the next number and answers with empty content'), but every clause carries information an agent needs.

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 two-parameter mutation tool with no annotations and no output schema, the definition covers the action, its effect, and the batch-mode return convention. Missing pieces are failure modes and confirmation of what the activation response contains, but nothing critical to calling it correctly is absent.

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 the schema already documents both class_name and the detail enum with its three modes. The description only restates that class_name names the class and adds nothing about the detail parameter. Baseline 3 applies when the schema does the heavy lifting.

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 and resource ('Activates the ABAP class') plus the effect ('its inactive version is in force'), which is exactly what distinguishes it from the many Activate* siblings such as ActivateProgram or ActivateInterface. An agent can identify the target object type and outcome without opening the schema.

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?

Usage is implied by the effect statement — you call it when a class has an inactive version that should be put in force — and the batch-mode sentence gives a real usage context. However, it never states prerequisites (an inactive version must exist), what happens if the class is already active, or points to any alternative such as ActivateObjects for multi-object activation.

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

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

With no annotations, the description carries the full burden, and it does disclose a non-obvious behavior: in batch mode the call is recorded and returns empty content, read back by number later. That is valuable, but it omits whether activation requires a transport, lock, or special authorization, and what a non-batch response looks like.

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?

Two sentences, front-loaded with the action and effect, with the batch caveat second. The "Recordable:" clause is dense but every element is actionable; nothing is wasted.

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 two-parameter mutation tool with no annotations and no output schema, the description covers the effect and the batch-mode return semantics, which is the main gap an agent would hit. It still leaves prerequisites and failure modes unstated.

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 coverage is 100%, including a fully documented enum for `detail`, so the schema already does the heavy lifting. The description only ties `data_element_name` to the activation target and adds no format or naming-convention detail beyond the schema.

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 and resource ("Activates the ABAP data element named by data_element_name") and adds the effect ("so its inactive version is in force"), which separates it from Create/Update/DeleteDataElement siblings by intent. It does not explicitly name a sibling alternative such as ActivateObjects, so it falls short of a 5.

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?

Usage is only implied: the agent must infer that this is the step to run after an Update leaves an inactive version behind. There is no explicit "use when X, not Y" guidance, and bulk activation via ActivateObjects is never mentioned.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the core effect (the inactive version becomes active) and a non-obvious batch-mode behavior where calls are recorded and answered later by number, though it omits permission requirements and normal-mode return details.

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?

The description is two sentences with no wasted words. The primary activation behavior is front-loaded, and the batch-mode caveat follows directly.

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 mutation tool with no annotations and no output schema, it adequately explains the activation effect and batch behavior, but it does not describe what a non-batch call returns or how errors are surfaced. The description is minimally sufficient but has clear gaps.

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 coverage is 100%, so the schema already documents both parameters in detail. The description only names 'ddl_name' and adds no additional meaning beyond what the schema provides for either parameter.

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?

The description states a specific verb ('Activates') and resource ('CDS view (DDL source)') and explicitly names the parameter that identifies it. An agent can distinguish this from sibling activation tools like ActivateTable or ActivateProgram by the DDL/CDS scope.

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?

It implies the tool should be used when an inactive version needs to be made active, but it does not explicitly say when to use this versus alternatives such as ActivateObjects or CheckDdl. No exclusions or prerequisites are given.

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

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

With no annotations, the description carries the burden and does add real value: it discloses the mutation effect on the object's version state and the non-obvious batch-mode contract (call recorded under the next number, empty content returned, result read by number afterwards), which ties into BatchAnswers. It stops short of stating failure behavior, preconditions such as syntax checks, or whether a transport entry is created.

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?

Two sentences, front-loaded with the core action and effect; nothing is wasteful. The second sentence is a dense run-on that packs the entire batch protocol in one breath, which slightly hurts readability.

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 two-parameter, no-output-schema mutation tool, the description covers the action, its effect on version state, and the batch recording protocol. Missing only activation-failure semantics and prerequisite context (checks, transport handling) that an agent would want before firing a mutating call.

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 coverage is 100%, and the 'detail' enum is fully self-documented in the schema (terse/full/raw). The description only echoes that domain_name is the target domain, adding no format or naming conventions beyond the schema, so the baseline of 3 applies.

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 ('Activates') and resource ('the ABAP domain named by domain_name') and explains the effect: the inactive version becomes active. The resource name separates it from the many Activate* siblings (ActivateClass, ActivateTable, ActivateDataElement), but the description never explicitly contrasts with them or with the generic ActivateObjects.

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 phrase 'so its inactive version is in force' implies when to use it (after edits that produced an inactive version), but there is no explicit guidance on alternatives such as ActivateObjects or the Check* tools that might precede activation. Usage is inferable rather than stated.

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

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 activation makes the inactive version live, and explains the non-obvious batch-mode recording semantics (recorded under a number, empty answer, retrieved later via BatchAnswers). It still omits error behavior when no inactive version exists and any permission/transport implications.

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?

Two sentences, front-loaded with the core action; the second sentence is dense but earns its place by explaining batch-mode recording, though its phrasing ('Recordable', 'answers with empty content') is slightly compressed and could be clearer.

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?

A mutation tool with no annotations and no output schema needs to explain return shape and failure modes. The description covers the batch-answer retrieval path well but says nothing about the normal return content, errors, or what happens when no inactive version is pending.

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 coverage is 100%, so both parameters are already documented, including the detail enum's terse/full/raw options. The description only echoes that function_group_name selects the target, adding no syntax or naming-convention guidance beyond the schema.

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 (activates) and resource (ABAP function group, named by parameter) plus the effect (inactive version goes into force). The resource boundary cleanly separates it from ActivateFunctionModule, ActivateProgram, ActivateClass and other Activate* siblings.

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?

Usage is implied rather than stated: one infers this follows edits that produced an inactive version. It never says when to prefer it over ActivateObjects (the bulk activator) or when to run CheckFunctionGroup first, and no prerequisites are given.

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

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

With no annotations, the description must carry behavioral disclosure. It explains that the inactive version becomes active and describes batch recording behavior in detail, but omits permissions, dependency/lock failures, reversibility, and normal response expectations.

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?

Two sentences with the purpose front-loaded and a relevant batch-mode caveat afterward. The second sentence is dense but earns its place by explaining non-obvious recording behavior.

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 mutation tool with no annotations and no output schema, it covers the core activation effect and important batch behavior. It remains incomplete on prerequisites, error cases, and what a normal non-batch response looks like.

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%, including the detail enum and its options, so the schema baseline is 3. The description names the two required parameters but largely restates schema semantics and does not add meaning beyond 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 ('Activates') and resource ('ABAP function module'), scoped by the function group named in the required parameters. It does not explicitly distinguish this from sibling activation tools such as ActivateFunctionGroup or ActivateObjects, but the function-module focus is clear.

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 implied usage is clear: activate an inactive function module. It adds useful batch-mode recording context, but gives no explicit when-to-use/when-not guidance or alternatives among the many activation, check, and delete siblings.

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

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

No annotations exist, so the description carries the full burden; it does disclose a genuinely non-obvious trait — that in batch mode the call is recorded under the next number and returns empty content, with the real answer retrieved later by number. It omits permissions, failure behavior, and whether dependent objects are also activated, leaving some gaps for a mutating tool.

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?

Two sentences, zero waste, with the core action and its effect front-loaded before the secondary batch-mode caveat.

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 two-parameter activation tool with no output schema, the description covers effect, target, and the batch-recording mechanic, which is enough to call it correctly. Minor gaps remain around prerequisites and error/partial-activation behavior.

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% and the detail parameter already documents its terse/full/raw enum meanings, so the schema does the heavy lifting. The description only restates interface_name ('the ABAP interface named by interface_name') and adds nothing about parameters.

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 (activates) and a specific resource (the ABAP interface named by interface_name), and adds the effect ('its inactive version is in force'), which distinguishes it clearly from sibling Activate* tools for classes, tables, programs, etc.

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?

Usage is implied by the activation semantics, but there is no explicit guidance on prerequisites (e.g., whether CheckInterface/GetInactiveObjects should precede it) or on choosing ActivateInterface over the generic ActivateObjects, and no statement of when not to use it.

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

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

With no annotations, the description carries the full burden and does disclose a genuinely non-obvious trait: in batch mode the call is recorded and returns empty content, with the answer retrieved by number after BatchEnd. It omits prerequisites (must an inactive version exist?), failure behavior, and permission needs, so not 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, the activation effect front-loaded and the batch caveat second. No filler; both sentences carry information an agent needs.

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 two-param mutation with no annotations and no output schema, the description covers effect and batch return semantics, which are the highest-risk unknowns. It stops short of stating preconditions and error outcomes, leaving a modest gap.

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 coverage is 100% and the description adds nothing about the 'name' or 'detail' parameters beyond what the schema already documents. Baseline 3 applies when the schema does the work.

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 (activates) and resource (CDS metadata extension), plus the effect ('its inactive version is in force'), which distinguishes it from sibling reads like GetMetadataExtension and checks like CheckMetadataExtension. An agent can tell what it does without opening the schema.

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 'inactive version is in force' clause implies the tool applies after an edit leaves an inactive version, but it never explicitly states when to use it versus GetMetadataExtension/CheckMetadataExtension or the generic ActivateObjects. Usage is inferable rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It says the operation activates and 'runs outside batch mode', but does not disclose what a mutation of this kind entails: whether activation is atomic across the list, what happens on partial failure, whether objects must be inactive beforehand, or what happens to dependencies.

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 dense sentence with the core action and scope front-loaded and no filler. It could be broken up slightly for readability, but nothing is wasted.

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?

Schema fully documents both parameters and there is no output schema to explain, but the description leaves behavioral gaps (atomicity, failure handling, preconditions) that matter for a mutation tool with zero annotation coverage.

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 coverage is 100%, with name/type and the full type-code enum documented in the schema, so the baseline is 3. The description restates 'each a name and a type' but adds nothing about the preaudit parameter or the semantics of mixed-type activation beyond the schema.

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 (activates) and resource (repository objects named by objects), and clarifies that heterogeneous types can be activated together in one call, which distinguishes it from the many single-type ActivateX siblings. It stops short of naming those siblings explicitly.

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?

'together, in one activation' implies this is the bulk-activation path, and 'Runs outside batch mode' hints at a context constraint, but neither the alternatives (ActivateClass, ActivateTable, etc.) nor when-not-to-use is spelled out. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the activation effect and the batch-mode recording behavior, including empty content and later retrieval by number, but it omits permissions, error behavior, and what a normal non-batch response looks like.

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?

The description is short and front-loads the primary purpose. The second sentence adds useful batch-mode context, though it is dense and specialized.

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?

The description covers the core mutation and an important batch-mode behavior, but with no annotations and no output schema it leaves gaps around normal return behavior, permissions, and error cases. It is adequate but not fully complete for a mutation tool.

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 the baseline is 3. The description mentions program_name in passing, but adds no parameter meaning beyond the schema, and the detail parameter is documented only in the schema.

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?

The description states a specific verb and resource: activating the ABAP program (report) named by program_name so its inactive version becomes active. It is clear what the tool does, but it does not explicitly distinguish itself from sibling activation tools such as ActivateObjects or ActivateClass.

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?

Usage is implied by the action and by the batch-mode note, but there is no explicit guidance on when to choose this tool over siblings like ActivateObjects or when not to use it. An agent can infer the basic scenario, but alternatives are not addressed.

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

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

With no annotations, the description carries the full burden and delivers real behavioral detail: the mutation semantics (inactive → active) and the non-obvious batch/recordable contract where the call returns empty content and the real answer is read later by number. It stops short of permissions, error behavior, or what happens if no inactive version exists.

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?

Two sentences, no filler, with the core effect front-loaded and the batch-mode caveat placed second. The batch sentence is dense but every clause (recording, next number, empty answer, read after batch) carries information an agent needs.

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 two-parameter activation tool with no output schema, the description covers what matters most: what changes on the server and how the response behaves in batch mode. It is only short of permission/error prerequisites, which is a modest gap for a low-complexity mutation.

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% and the `detail` enum is fully documented in the schema, so the baseline is 3. The description only restates that the binding is identified by `name` and adds no extra semantics for either parameter.

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 (Activates) and resource (the OData service binding named by `name`) plus the concrete effect: the inactive version is put in force. Against siblings like CreateServiceBinding, UpdateServiceBinding, DeleteServiceBinding, and ActivateServiceDefinition, the operation is unmistakable without opening any schema.

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?

Usage is implied rather than stated: an agent infers you call this when a binding is inactive and you want it live. There is no guidance on prerequisites (must an inactive version exist?), on when to prefer this over ActivateObjects, or on failure modes.

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

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

With no annotations, the description carries the burden and does add real behavioral context: it explains the activation effect on the inactive version and, unusually, the batch-mode contract (recorded under the next number, empty answer, answer retrieved by number). It omits failure behavior (does activation return check errors?) and permission requirements, which matters for a mutating operation.

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?

Two sentences, front-loaded with the core action and effect; the batch-mode sentence is dense but every clause (recording, empty answer, retrieval by number) is operationally necessary. No filler.

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 2-parameter, no-output-schema, no-annotation mutation tool, the description covers the effect and the otherwise-invisible batch return contract, which compensates for the missing output schema. What remains uncovered is error/check behavior on activation failure.

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 parameters are already documented, including the detail enum with per-value meaning. The description only echoes that the target is identified by name and says nothing about the detail parameter. Baseline 3 applies when the schema does the work.

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 and resource ("Activates the service definition named by name") plus the effect (inactive version comes into force), which is far more specific than a tautology. It does not, however, explicitly distinguish itself from the many other Activate* siblings (ActivateServiceBinding, ActivateClass, ActivateObjects), leaving that to the name alone.

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?

Usage is implied rather than stated: since it puts the inactive version in force, an agent can infer this is the post-edit activation step. There is no explicit when-to-use, no prerequisite mention (e.g., successful check), and no named alternative such as ActivateObjects or ActivateServiceBinding.

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

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 explains the activation semantics and, notably, discloses the non-obvious batch-mode contract (call is recorded under the next number, returns empty content, answer retrieved by number afterwards). It still omits permissions, failure behavior, and whether errors leave the object inactive.

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?

Two compact sentences with the core action front-loaded and no filler. The batch sentence is information-dense but slightly convoluted in phrasing ('answers with empty content; its answer is read by number'), costing a bit of readability.

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?

There is no output schema and no annotations, so the description must carry behavioral context, and it covers purpose plus the batch-recording quirk well. Gaps remain around preconditions, side effects on the inactive version, and error outcomes for what is a state-changing operation.

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 parameters are already documented, including the terse/full/raw enum for detail. The description only restates that structure_name identifies the ABAP structure and adds nothing about the detail parameter, so baseline 3 applies.

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 (Activates) and resource (ABAP structure), plus the concrete effect (inactive version comes into force). Distinguishes reasonably from ActivateProgram/ActivateClass/ActivateTable by naming the resource, though it never addresses the generic ActivateObjects sibling that could also cover structures.

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?

Usage is implied by the effect statement, and the batch-mode clause hints that the tool is callable inside a batch, but nothing says when to prefer this over ActivateObjects, whether a CheckStructure should run first, or what preconditions must hold.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the mutation effect and specific batch-mode behavior: calls are recorded, return empty content, and answers are read by number afterward. It omits other important behavioral details such as permissions, failure modes, and normal response behavior outside batch mode.

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?

The description is front-loaded with the core activation behavior and is only two sentences. The second sentence adds relevant batch-mode information without unnecessary repetition or filler.

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 tool with no output schema and no annotations, the description covers the main action and unusual batch behavior. However, it does not explain the normal response shape, error behavior, or prerequisites, leaving gaps that an agent would need to infer.

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 coverage is 100%, and the schema already documents both table_name and detail. The description reinforces that table_name identifies the table to activate but adds no meaning for the detail parameter beyond what the schema provides, so the baseline score of 3 is appropriate.

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?

The description uses a specific verb and resource: it activates the ABAP database table identified by table_name and makes its inactive version active. This clearly distinguishes it from sibling activation tools such as ActivateProgram, ActivateClass, and ActivateStructure.

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 phrase 'so its inactive version is in force' implies the table must already have an inactive version, which gives some usage context. However, it does not explicitly state when to choose ActivateTable over ActivateObjects or when not to use it, nor does it mention prerequisites or alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It does add one genuinely non-obvious trait: in batch mode the call is recorded under the next number and returns empty content, read later via a numbered answer. However, it omits failure behavior (duplicate object already in task, released/non-modifiable transport), permission requirements, and what the non-batch answer contains.

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?

Two sentences, action stated first with zero filler. The second sentence is dense and slightly jargon-heavy ('Recordable', 'recorded under the next number'), but every clause conveys real information rather than restating the name.

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 5-parameter mutation tool with no annotations and no output schema, the description covers the core action and batch semantics but leaves the normal (non-batch) return shape, error conditions, and transport-state preconditions unexplained. It is workable but incomplete for a write operation whose safety profile is otherwise undocumented.

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 all five parameters (including pgmid and detail enum) are already documented in the schema. The description only ties the three required parameters to the action and adds the 'existing' qualifier on object_name/object_type; it contributes no new syntax or constraint beyond the schema, so baseline 3 applies.

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?

The description gives a specific verb and resource — adding an existing object (by name and type) into a named transport task — and even states the effect ('so it travels with the task's request'). It doesn't name a sibling (e.g., RemoveTransportObject, MoveTransportObjects) to sharpen the boundary, so it stops short of a 5.

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 existing object' implies the object must already exist rather than be created here, and the batch-mode sentence implies usage inside BatchBegin/BatchEnd. But there is no explicit when-to-use/when-not guidance, no mention of the alternative tools for moving or removing objects, and no stated prerequisites (task must exist, must be modifiable/unreleased).

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

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

No annotations are supplied, so the description carries the full burden; it does disclose two useful traits: the safety posture ('[read-only]') and the batch-mode restriction. It stops short of stating what happens to the debuggee after cancellation, what state_handle becomes, or what is returned.

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?

Two bracketed tags plus a single sentence, with the action and its constraint front-loaded. Nothing is wasted and nothing needed is buried.

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?

With no output schema and no annotations, the definition covers the action and the batch-mode limitation but leaves the post-cancellation state and any return value unexplained. Adequate for a simple two-parameter debug helper, but thin for a tool that alters a live debugging session.

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 coverage is 100% and both parameters carry their own descriptions, including the full enum semantics for 'detail', so the schema does the documentation work. The description adds no param-level meaning beyond that, which is the baseline case.

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 (cancels) and resource (the stopped AMDP debuggee's execution), which is enough to distinguish it from AmdpDebugStart and AmdpDebugStep. It does not explicitly contrast with the close sibling AmdpDebugStop, so the boundary between 'cancel' and 'stop' must be inferred.

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?

Makes the precondition explicit (the debuggee must already be stopped) and adds a clear exclusion with 'Runs outside batch mode', which tells the agent not to wrap it in BatchBegin/BatchEnd. No named alternative for related debug flows, but context is clear.

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

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

With no annotations, the description carries the full burden, and it does disclose two genuinely non-obvious traits: a hard 100-row cap (truncation) and that it runs only outside batch mode. It still omits permission requirements and what happens if invoked without an active stop, so it is strong but not exhaustive.

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?

Very short and front-loaded, with bracketed tags signaling read-only and debug category before the core content. The telegraphic phrasing ('through a SELECT over it') is slightly compressed, but no sentence is wasted.

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 read-only debug inspection tool with no output schema and a fully documented schema, the description covers what it returns (rows, bounded at 100, verbosity controllable via detail) and where it may run. Missing only edge-case behavior, which is minor at this complexity.

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 coverage is 100%, so all four parameters are already documented, including the detail enum. The description only adds that 'query' is an optional SELECT applied over the table variable instead of a plain row dump; it says nothing about 'variable' or 'state_handle' 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.

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

States a specific verb+resource: it reads rows of a table variable at an AMDP debug stop, with an optional SELECT path. The scope ('at the AMDP stop', 'up to 100') separates it from GetTableContents and GetTable, though it never names a sibling explicitly to disambiguate from DebugGetVariables.

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?

'At the AMDP stop' implies the prerequisite (the debugger must already be paused following AmdpDebugStart/AmdpDebugWait), and 'runs outside batch mode' hints at the batch-tool alternative. But there is no explicit statement of when to use this versus AmdpDebugStep, DebugGetVariables, or the batch variants, and no stated failure behavior if not stopped.

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

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

With no annotations provided, the description carries the full burden, and it does disclose meaningful behavior: the set is applied server-side ('as confirmed by the system'), it catches requests for the whole connected SAP user from any source (a broad, surprising side effect), and it does not work in batch mode. However, it does not state that existing breakpoints are replaced, what permissions are required, or what happens when the session has ended.

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?

Three short sentences with the tag prefixes front-loaded and no filler. The clause 'as confirmed by the system' is slightly vague, but overall the text is tight and appropriately sized for a three-parameter tool.

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?

Honestly this is a 3-ish area, but weighing it: no output schema exists, so the description would ideally say what comes back; the 'detail' enum in the schema covers return granularity, which mitigates that gap. For a stateful debug mutation the description gives the environment constraint (no batch mode) and the scope of effect (all requests of the user), which is the core operational context an agent needs before calling.

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 coverage is 100%, so state_handle, breakpoints, and detail are already fully documented in the schema, giving a baseline of 3. The phrase 'to the set given' hints that the breakpoints array replaces rather than appends, which is a small semantic addition, but no other parameter meaning is added.

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?

The description states a specific verb and resource: 'Sets the AMDP breakpoints of a debug session to the set given.' The AMDP qualifier and the note about catching requests 'from this server and from anywhere else' implicitly separate it from the generic DebugSetBreakpoints sibling, but the sibling is never named, so an agent must infer which tool to pick.

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?

There is no explicit statement of when to use this versus DebugSetBreakpoints, nor any prerequisite such as needing an active session created by AmdpDebugStart. The only exclusion hint is the trailing 'Runs outside batch mode,' which is a constraint, not usage guidance.

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

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

No annotations are supplied, yet the description discloses the two traits that actually matter: the session captures every request of the connected SAP user from this server and anywhere else, and it runs outside batch mode. The ordering guarantee for the background run is also spelled out. It stops short of saying whether an existing session blocks the call or what a session handle looks like.

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?

Front-loaded with the core action and the [read-only] [debug] tags, and every clause carries information. The single long sentence is dense but not padded, though it could be split for scanability.

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?

There is no output schema, and the description never indicates what comes back from a successful start (a session handle presumably needed by AmdpDebugWait/AmdpDebugStep) or how long the call blocks. For a stateful, blocking debug operation with nested parameters, that is a meaningful gap.

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 coverage is 100% with per-parameter descriptions for run, detail, breakpoints and stop_existing, so the schema does the heavy lifting. The description adds only the sequencing semantics of run (starts once breakpoints are confirmed) and that breakpoints target SQLScript method lines; 3 is the baseline.

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 and resource — "Opens an AMDP debug session ... with breakpoints on lines in SQLScript methods" — and pins the scope to the connected SAP user. That reads distinctly from the ABAP Debug* family and from AmdpDebugSetBreakpoints, which adds breakpoints to a session rather than opening one.

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?

Usage is implied rather than stated: breakpoints are required, and the description notes a background run only starts after the system confirms breakpoints. It never says what to do when a session already exists (use stop_existing vs AmdpDebugStop) or how it relates to AmdpDebugSetBreakpoints, so the agent must infer the workflow from siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the stopped-debuggee precondition and the outside-batch-mode constraint, but it does not explain side effects on debug state, error behavior, or whether the call blocks waiting for a stop.

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 front-loaded sentence with compact tags; every clause adds either purpose or a usage constraint. There is no redundant or filler text.

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?

The schema is rich and the description adds the key precondition that the debuggee must be stopped and that the tool runs outside batch mode. With no output schema, the remaining gap around return values and blocked-call behavior is minor but real.

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 coverage is 100%, so the schema already documents all three parameters clearly. The description only restates the action semantics at a high level and adds no syntax, defaults, or constraints beyond what the schema provides.

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?

The description states a specific verb and resource: stepping a stopped AMDP debuggee. It also distinguishes the two step semantics (over a statement vs. to the next stop), which separates it from related siblings such as AmdpDebugWait or generic DebugStep.

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?

It gives clear context for use: the debuggee must be stopped, and the tool runs outside batch mode. However, it does not name explicit alternatives or say when another AMDP debug tool should be preferred.

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

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

With no annotations, the description carries the burden and discloses meaningful side effects: releasing the suspended debuggee, deleting kept debugger-batch answers when the whole session ends, and reporting a failed undo. It still lacks details on permissions, idempotency, and what '[read-only]' means for mutable debug-session state.

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?

The purpose is front-loaded across three efficient sentences with no obvious filler. Some phrasing around 'kept answers of its debugger batch' is dense, but the overall structure is appropriately sized.

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?

Given no annotations and no output schema, the description covers the key lifecycle side effects and the batch-mode constraint. It leaves minor gaps around return values and the lifecycle of 'state_handle', but is broadly complete for a debug-stop operation.

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 parameters are fully documented in the schema. The description adds no meaning about 'state_handle' or 'detail' beyond what the schema already provides, making the baseline 3 appropriate.

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 ('Ends') and resource ('the AMDP part of a debug session'), and adds that it releases a suspended debuggee first. It does not explicitly distinguish itself from close siblings such as AmdpDebugCancel or DebugStop.

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?

Provides a contextual constraint ('Runs outside batch mode') and describes failure behavior, but gives no explicit when-to-use guidance versus AmdpDebugCancel or DebugStop, nor any when-not conditions.

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

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

No annotations are supplied, so the description carries the burden; it does add real value with the explicit '[read-only]' marker and the constraint that it runs outside batch mode. However, for a long-poll/wait tool the critical behaviors are undisclosed: what is returned if the wait expires with no event (empty result vs. error), whether returned events are consumed or re-readable, and whether the state_handle stays valid.

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 with bracketed tags front-loading the read-only and debug classification; nothing is redundant. It is slightly over-compressed, since the fragment omits the verb that would make it self-contained.

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?

There is no output schema, so the description should convey what an 'AMDP event' result looks like and what a timeout yields; it does neither. With full schema coverage on inputs and the detail knob controlling payload size, what remains missing is concentrated in return/timing behavior.

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 coverage is 100% and every parameter, including the detail enum's three modes, is documented in the schema itself. The description only restates that the wait is bounded by hold_seconds, adding nothing beyond the schema's 'at most 30 seconds' note, so the baseline of 3 applies.

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?

The description names a specific resource (AMDP events of a debug session) and the waiting behavior keyed to hold_seconds, and the '[debug]' tag plus the AMDP prefix separate it from the generic DebugWait sibling. It is a sentence fragment rather than a full verb statement, but an agent can still tell what it retrieves.

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?

Usage is only implied: the '[debug]' tag and 'Runs outside batch mode' tell the agent this is for interactive AMDP debugging and not batch runs, which is a partial when-not. Nothing states when to call AmdpDebugWait versus AmdpDebugStep or DebugWait, nor that a prior AmdpDebugStart/state_handle is required, leaving the agent to infer the polling workflow.

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

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

With no annotations, the description carries the burden and does reasonably well: it declares read-only, discloses that answers are materialized on first read and cached for later reads, that numbers are processed in parallel, and that unknown numbers yield 'unknown' rather than an error. It does not describe what an 'answer' object contains or whether reads are idempotent across batch restarts.

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?

Front-loaded with the read-only tag and the core action, then the caching and parallelism facts. It is dense semicolon-chained prose, but every clause contributes information about behavior.

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?

No output schema exists, so the description must convey the return shape, and 'the tool's answer, built from the call's parts of SAP's response' is suggestive but not concrete about the answer's structure or failure representation. The relationship to the batch lifecycle (BatchBegin/BatchEnd, DebugBatchBegin) is left implicit for a tool that cannot be used standalone.

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% and the schema already states 'give this or numbers, not both' and the ordering guarantee. The description's 'takes one number or a list of numbers' and 'unknown number answers as unknown' add only marginal semantics beyond the schema, so baseline 3 applies.

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 and resource: it answers the calls of the last executed batch by number. An agent can tell this is a read-back of prior batch results rather than a batch-start/end control. It stops short of naming BatchBegin/BatchEnd as the lifecycle siblings it depends on, so differentiation relies on inference.

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 last executed batch" implies the tool is only meaningful after a batch has run, and the description notes takes one number or a list. There is no explicit when-not guidance, no statement that BatchBegin must precede it, and no advice on what to do when a number is unknown beyond the bare 'answers as unknown'.

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

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

No annotations exist, so the description carries the full burden, and it discloses genuinely important behavior: recordable tools return empty content while batching, and the returned state_handle must be threaded through Streamable HTTP as an argument or header. It also self-declares read-only. Missing is what happens on error or repeated BatchBegin calls.

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?

Three tight sentences, front-loaded with the verb and purpose, followed by the mechanism and then the transport-specific detail. Nothing is repeated and nothing is filler, so the agent can stop reading at any sentence and still act correctly.

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?

With no output schema, the description correctly fills the gap by explaining that state_handle is returned and how to use it. What is left out is the lifecycle tail, i.e. how the batch is closed or its answers retrieved, which matters for an agent that has only this tool and its siblings to reason about.

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?

The tool takes zero parameters, so the baseline is 4 and there is no parameter ambiguity to resolve. The description instead spends its words on the state_handle output, which is useful value-add even though it is not a parameter concern.

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 and resource ("Starts batch mode on this server") and then defines what batch mode does: recordable tool calls are recorded under sequential numbers and answer with empty content. That is enough to distinguish it from BatchEnd/BatchAnswers, though those siblings are never named, so the differentiation is inferred rather than explicit.

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?

Explains the operating context and the requirement to pass state_handle on every subsequent batch call, which implicitly tells the agent this is the entry point of a workflow. However, it never states when to use this versus BatchEnd or BatchAnswers, nor what happens if a batch is already open, leaving the workflow routing implied.

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

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

With no annotations, the description does useful behavioral work: it says the tool sends recorded calls with credentials in force, splits SAP's answer per call, returns counts of recorded calls/requests/parts, and reports errors when sending or splitting fails. However, the error behavior is hard to parse and important details such as what happens to the batch state after failure are not clearly spelled out.

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?

The first sentence is front-loaded and clear, but the second sentence is a long, convoluted run-on that repeats 'answers' and packs multiple error conditions together. The content is relevant but could be structured much more cleanly.

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?

Given zero parameters and no output schema, the description does explain the returned counts and error conditions. Still, it omits key context for batch mode, such as the prerequisite relationship with BatchBegin and whether BatchAnswers is also needed, leaving an agent to infer the workflow.

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?

The tool has zero parameters, so there are no parameter semantics to explain. The schema has no properties, and the baseline for this dimension is 4.

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?

The description states a specific verb and resource: it sends recorded calls in one envelope and ends batch mode. This distinguishes the core action from BatchBegin and BatchAnswers, though it does not explicitly name those siblings or fully contrast the tool with them.

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 phrase 'ends batch mode' implies the tool should be used at the end of a batch sequence, but the description never explicitly says it must follow BatchBegin or when to prefer BatchAnswers. Usage is inferable rather than explicitly guided.

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

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

No structured annotations are provided, so the description carries the disclosure burden and does so reasonably: it marks the tool as [read-only], says it returns syntax errors/warnings/messages, and explains the non-obvious batch recording behavior. It does not cover authorization requirements or more detailed side-effect constraints, but the key behavioral traits are disclosed.

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?

The description is three focused sentences with no wasted text. The primary purpose is front-loaded, and the batch-recording caveat is compactly summarized after the core behavior.

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 two-parameter check tool with full schema coverage and no output schema, the description gives enough context to invoke it correctly: it explains the input resource, the returned categories, and the batch behavior. It could more explicitly mention alternatives or prerequisites, but no critical invocation detail is missing.

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%, and the schema already documents both `name` and `version`, including the active/inactive enum semantics. The description only repeats that the BDEF is named by `name` and adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.

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?

The description states a specific verb and resource: it runs a syntax check on the RAP behavior definition (BDEF) named by `name`. The BDEF resource makes it clearly distinguishable from the many other `Check*` siblings such as CheckClass or CheckTable. It also states what is returned: syntax errors, warnings, and messages.

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 context is clear enough to imply when to use it: checking the syntax of a BDEF. However, the description does not explicitly state when to use this instead of related tools like GetBehaviorDefinition, ActivateBehaviorDefinition, or other Check* tools, nor does it describe prerequisites or exclusions.

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

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

No structured annotations exist, so the description carries the burden, and it does substantial work: it self-labels read-only and discloses the non-obvious batch-mode behavior where the call records an answer and returns empty content to be retrieved by number later. It does not cover authorization, cost, or limits, but the batch quirk is exactly the kind of hidden behavior an agent needs.

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?

Four tight sentences with the read-only tag and core action front-loaded, followed by modes, return content, and the batch caveat in priority order. Nothing is redundant, though the batch sentence is dense and could be split for readability.

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?

With no output schema, the description correctly states what comes back (syntax errors, warnings, messages), and it covers the tricky batch-mode return path. For a three-parameter read-only check tool this is essentially complete; only cross-tool routing guidance is missing.

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 all three parameters are already documented, including the active/inactive enum and the requirement that source_code contain full DEFINITION and IMPLEMENTATION sections. The description only restates that existing-code and hypothetical-code modes exist, adding little beyond the schema, so baseline 3 applies.

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?

The description gives a specific verb and resource: 'Runs a syntax check on the ABAP class named by class_name.' The resource naming implicitly separates it from the many sibling Check* tools (CheckProgram, CheckInterface, CheckTable), though none are called out explicitly.

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?

It clearly explains the two usage modes: checking an existing class (active or inactive) versus validating hypothetical source code passed in. It stops short of naming alternatives or stating when to prefer CheckClass-family tools over, say, activating the class, so it is clear context rather than explicit routing.

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

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

With no annotations, the description carries the full burden and does well: it declares [read-only], enumerates the return category (syntax errors, warnings, messages), and discloses a non-obvious batch-mode behavior where the call returns empty content and must be resolved by number via BatchAnswers. It does not state whether the check is bounded in time or whether it fails on nonexistent objects.

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?

Three short sentences, with the read-only marker and the core action front-loaded, followed by return values and the batch caveat. No filler, though the batch sentence is dense and would read better separated from the return-value sentence.

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 two-parameter read tool with no output schema and no annotations, the description covers purpose, result shape, and the batch-mode recording protocol that an agent would otherwise get wrong. Remaining gaps (timeouts, error behavior on missing objects) are minor.

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% and the version parameter already documents active vs inactive semantics in full, including the post-write inactive use case. The description only restates that data_element_name names the data element, adding nothing beyond the schema; baseline 3 applies.

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 and resource ("Runs a syntax check on the ABAP data element") and names the target object type, which implicitly separates it from the many other Check* siblings like CheckTable and CheckClass. It does not explicitly contrast itself with those siblings or with GetDataElement, so it stops short of a 5.

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?

Usage is only implied: it is a validation step, and the batch paragraph explains the batch-mode contract. There is no explicit guidance on when to prefer this over GetDataElement or ActivateDataElement, or that a check should follow an UpdateDataElement on the inactive version.

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

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 well: it explicitly declares read-only behavior, states the return content (syntax errors, warnings, messages), and discloses the unusual batch-mode recording semantics including empty responses and answer retrieval by number. It does not cover auth/permission requirements or error handling for invalid ddl_name, but the core behavioral profile is clear.

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?

The purpose and read-only marker are front-loaded, and the description stays compact despite covering two modes plus batch semantics. The batch sentence is long but earns its place by explaining non-obvious behavior.

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?

There is no output schema, but the description states the return content (syntax errors, warnings, messages), and no annotations exist, yet the description supplies the read-only and batch-mode context. An agent has enough to call the tool correctly, with only minor gaps around invalid-input behavior.

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 all three parameters are already documented in the input schema. The description reinforces the mode distinction (existing view vs. hypothetical source) but adds little syntax or interaction detail beyond what the schema already provides; baseline 3 applies when the schema does the heavy lifting.

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?

The description gives a specific verb and resource: 'Runs a syntax check on the CDS view named by ddl_name,' and explains the two modes (existing active/inactive view vs. hypothetical DDL source). This clearly separates it from retrieval tools like GetDdl and from other Check* tools aimed at different object types, though it never names an explicit alternative.

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?

It states what can be checked (existing view or hypothetical source), which implies when the tool is appropriate, but gives no explicit when-not conditions or routing to alternatives such as GetDdl for plain retrieval or ActivateDdl for activation. The batch-mode note is contextual rather than a usage guideline.

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

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

With no annotations provided, the description carries the burden. It discloses read-only status, return values (syntax errors, warnings, messages), and special batch-mode recording behavior. It lacks details on permissions or error conditions, but covers key behaviors well.

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?

The description is appropriately sized and front-loads the purpose and read-only flag. The batch-mode sentence is somewhat dense but necessary; overall it is efficient with little waste.

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?

Given the simple check operation, full schema coverage, and no output schema, the description covers purpose, returns, and batch behavior sufficiently. It could more explicitly differentiate from sibling check tools, but for calling the tool it is nearly complete.

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 the schema fully documents both parameters. The description adds no additional meaning about parameters beyond what the schema provides, making the baseline score of 3 appropriate.

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?

The description states a specific verb (runs a syntax check) and resource (ABAP domain named by domain_name). It does not explicitly distinguish from sibling Check* tools (e.g., CheckTable, CheckDataElement), but the domain focus is clear.

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?

Usage is implied: the tool is for checking domain syntax. However, there is no explicit guidance on when to use this versus other Check* tools or when not to use it. No alternatives or exclusions are mentioned.

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

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

No annotations were supplied, and the description carries the burden well: it declares the operation read-only and discloses the non-obvious batch-mode recording behavior (empty content returned, answer retrieved by number after batch). That is exactly the kind of trait an agent could not infer from the schema.

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?

Three short sentences: what it does, what it returns, and the batch caveat — each front-loaded and earning its place, with no filler.

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?

Complete for a simple 2-parameter read tool with no output schema: operation, return categories, version selection (via schema), and batch semantics are all covered. Only minor gaps remain around failure behavior for an invalid or nonexistent function group name.

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 coverage is 100% and the `version` parameter already has a rich enum description covering active vs. inactive semantics, so the schema does the heavy lifting. The description adds nothing about parameters beyond naming `function_group_name`, so baseline 3 applies.

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+resource ('Runs a syntax check on the ABAP function group') and enumerates the return content. The resource name inherently distinguishes it from siblings like CheckFunctionModule, CheckProgram, and CheckInterface, though it never explicitly says so.

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?

Usage is implied — check a function group's syntax — but there is no explicit guidance on when to prefer CheckFunctionModule, CheckInclude, or ActivateFunctionGroup instead, nor on prerequisites (e.g., must the group exist/be locked?).

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

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

With no annotations, the description carries the full burden and does well: it self-declares '[read-only]', states what is returned (errors, warnings, messages), and explains the non-obvious batch behavior where the call is recorded and later read back by number. It omits authorization requirements and whether inactive-version checks behave differently, so not 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three front-loaded sentences with no filler: purpose first, return values second, batch caveat last. The batch sentence is long but carries genuinely non-obvious information, so nothing is wasted.

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?

No output schema exists, and the description compensates by specifying the return content. Parameters are explained well enough and the batch mode is disclosed. Missing sibling routing and activation prerequisites are the only meaningful gaps for a check tool.

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 coverage is 100%, so all three parameters are already documented, giving a baseline of 3. The description reinforces the function_module_name/function_group_name relationship but never mentions the 'version' parameter or its active/inactive default, adding little beyond the schema.

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 ('Runs a syntax check') and a precisely scoped resource (an ABAP function module within a named function group), plus the return content. It does not explicitly say how it differs from the many Check* siblings such as CheckFunctionGroup or CheckProgram, which keeps it at 4 rather than 5.

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 scope ('function module in the function group') implies when the tool applies, but there is no explicit statement of when to use it versus CheckFunctionGroup, CheckProgram, or the Activate* tools, and no prerequisites such as whether the object must be active first. Usage is inferable but not guided.

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

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

With no annotations, the description carries the burden and does well: it declares the operation read-only and explains the non-obvious batch-mode behavior (empty content on call, answer retrieved later by number). It does not cover permissions or result size, which keeps it below 5.

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?

Three sentences, front-loaded with purpose and return content, with the read-only tag leading. The batch sentence is dense but this is genuinely non-obvious information that earns its place.

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 two-parameter check tool with no output schema and no annotations, the description covers purpose, return content, safety profile, and the batch quirk. The main gap is routing guidance against sibling check/get tools, which is a minor omission given the clear resource-based naming.

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 coverage is 100%, so both parameters, including the enum semantics of `version`, are already fully documented in the schema. The description only echoes `interface_name` and adds no syntax or format details beyond it, so the baseline 3 applies.

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 and resource ('Runs a syntax check on the ABAP interface') and names the input that selects the target, which cleanly separates it from the many sibling Check* tools (CheckClass, CheckProgram, CheckTable) that share the same verb but operate on different object types.

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?

Usage is only implied by the read-only tag and the batch-recording note; the description never says when to run this versus GetInterface or the version-diff siblings, nor mentions the inactive-version workflow. The hint about checking inactive after a write lives in the schema, not the description.

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

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

With no annotations, the description carries the disclosure burden and does state the tool is read-only, what it returns (errors, warnings, messages), and explains the non-obvious batch recording behavior including empty content and later retrieval by number. It omits permission requirements and any side effects around active vs. inactive versions, but covers the major behavioral traits.

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?

Two sentences, front-loaded with the read-only marker, purpose, and return values, followed by the batch caveat. Every clause carries information an agent needs, with no repetition of the schema or title.

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 two-parameter tool with no output schema, the description supplies the return contents (errors, warnings, messages), the read-only nature, and the batch interaction model, while the schema handles version semantics. It is nearly complete, though it could note prerequisites or what happens when the named DDLX does not exist.

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%, and the version parameter’s active/inactive semantics – including the lack of fallback – are fully documented in the schema. The description only restates that the tool operates on the metadata extension 'named by name,' adding no parameter meaning beyond the schema, so the baseline of 3 applies.

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?

The description names a specific verb (runs a syntax check) and a precise resource (the CDS metadata extension / DDLX named by name). It also states the returned artifacts (syntax errors, warnings, messages), which distinguishes it from generic Check* siblings such as CheckDdl, CheckTable, and CheckClass.

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?

Usage is implied by 'Runs a syntax check' – an agent can infer this is for validating a DDLX before activation – but the description never says when to use it rather than CheckDdl or ActivateMetadataExtension, and it gives no prerequisites. The batch-mode note describes behavior, not when to choose this tool over alternatives.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the operation is '[read-only]', that it returns syntax errors, warnings, and messages, and it explains the unusual batch-mode recording behavior where the call answers empty and the result is read later by number. These are meaningful traits beyond the schema, though it does not cover failure behavior or result structure in detail.

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?

The description is three tight sentences with no waste. It front-loads the core action and read-only nature, then adds return values and batch behavior in a logical order.

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 check tool with no output schema, the description explains what is returned (syntax errors, warnings, messages) and covers the non-obvious batch recording semantics. The parameter details are fully covered by the schema. It could say more about failure cases or whether the check is recursive, but the essential calling information is present.

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 parameters are already documented in the schema, including the caution that super_package is not read by the check endpoint. The description mentions package_name only implicitly through the package-level purpose and adds no syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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?

The description states a specific verb and resource: 'Runs a syntax check on the ABAP package named by package_name.' It distinguishes the tool from siblings like CheckProgram, CheckClass, and CheckTable by explicitly scoping the check to a package. An agent can identify the operation without opening the schema.

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 this is the package-level syntax check, but it never states when to use it versus CheckProgram, CheckClass, or CheckPackageLow. There are no exclusions or decision criteria for selecting among the many sibling Check* tools. Usage is inferable from the resource name but not explicitly guided.

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

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

With no annotations, the description carries the full behavioral burden and does well: it marks the tool as read-only, describes the return content (syntax errors, warnings, messages), and explains the batch recording behavior where calls return empty content and answers are read later by number. It does not cover authorization or edge cases, but adds meaningful context beyond structured fields.

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?

The description is front-loaded with the core action and return behavior, followed by availability and batch semantics. Each sentence adds value, though the batch-mode note could arguably be separated for clarity.

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 two-parameter read-only check tool with no output schema, the description supplies the key return information and batch behavior. It is sufficient for correct invocation, with only minor gaps around error details.

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 parameters are already documented. The description mentions program_name but adds no syntax or format detail beyond the schema, making the baseline score appropriate.

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?

The description states a specific verb and resource: it runs a syntax check on an ABAP program identified by program_name. This distinguishes it from sibling Check* tools such as CheckClass and CheckTable by the resource it checks.

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?

It provides clear usage context, including that it is available on premise and that `inactive` should be passed right after a write for the unsaved version. It does not explicitly exclude other Check* siblings, but the resource-specific scope makes the intended use clear.

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

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

No annotations are provided, so the description carries the burden and does so well: it declares read-only behavior, describes the returned syntax errors/warnings/messages, and explains the important batch-mode recording semantics. It omits permission requirements and error behavior for invalid structure names.

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?

Front-loads the purpose, then usage modes, return content, and batch behavior in tight sentences. Every sentence provides information an agent needs for correct invocation.

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 tool with no annotations and no output schema, the description covers the essentials: read-only nature, modes, return content, and batch recording. It could clarify whether structure_name is still required when ddl_code is supplied, and what errors occur on invalid input.

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 coverage is 100%, so the parameter schema already documents version, ddl_code, and structure_name. The description reinforces the active/inactive and hypothetical-DDL concepts but adds no syntax, format, or dependency details beyond the schema.

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 (runs a syntax check) and resource (ABAP structure named by structure_name), and distinguishes the two modes: checking an existing structure versus validating hypothetical DDL code. An agent can identify the operation without opening the schema.

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?

Explains the two usage contexts (existing active/inactive structure vs hypothetical DDL), which is clear guidance. It does not name alternatives such as CheckDdl or CheckTable or state exclusions, leaving sibling differentiation implicit.

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

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

With no annotations, the description carries the full burden and does real work: it declares read-only, states the output is syntax errors/warnings/messages, and explains the non-obvious batch recording semantics (empty content returned, answer retrieved later by number). It omits any error/failure behavior or permission requirements, keeping it 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence and every subsequent sentence adds a distinct fact (accepted inputs, return content, batch behavior). The batch sentence is long but carries information that is otherwise undiscoverable, so it earns its place.

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?

No output schema exists, so the description compensates by naming the return content (errors, warnings, messages), and it covers both usage modes plus the unusual batch/recordable lifecycle. Adequate for a 3-parameter read-only check tool, though interaction rules between version and ddl_code remain unaddressed.

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 coverage is 100% and the enum for version is documented in the schema itself, so the description mostly restates it ('active/inactive', 'hypothetical DDL code'). It adds no format, length, or interaction detail (e.g. what happens if ddl_code and version are both supplied), so baseline 3 applies.

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 (runs a syntax check) against a specific resource (the ABAP database table named by table_name), and adds that it also validates hypothetical DDL. It stops short of distinguishing itself from the very similar sibling CheckDdl, which an agent could easily confuse given the overlap in DDL validation.

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?

Implies the two modes (checking a saved active/inactive version vs validating supplied DDL), but never states when to prefer CheckTable over CheckDdl for DDL source, nor any prerequisites like needing an active/inactive object to exist. Usage is inferable rather than spelled out.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: the object is created in an empty/initial state (so content must be added afterwards) and the call cannot be made inside batch mode. It omits permission/authorization needs, whether a transport request is mandatory for non-local packages, and what happens when activate defaults to true.

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?

Three short sentences, front-loaded with the verb and resource, then the resulting object state, then the execution constraint. No filler and every sentence contributes a distinct fact.

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 mutation tool with no annotations and no output schema, the description says nothing about what is returned (e.g. activation status, errors) or about the create-then-update-then-activate workflow. It is adequate to attempt the call correctly but leaves the agent guessing about the result and follow-up steps.

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%, including enums for detail and implementation_type, so the schema already explains all 9 parameters. The description adds no syntax, format, or constraint detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 and resource: creates an ABAP Behavior Definition (BDEF) object in an SAP system, and clarifies it is created in initial state. This is clearly distinguishable from UpdateBehaviorDefinition and CreateBehaviorImplementation, though the description never names those siblings explicitly.

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?

There is no explicit statement of when to choose this tool over UpdateBehaviorDefinition, CreateBehaviorImplementation, or the Activate* siblings. 'Runs outside batch mode' is a constraint rather than usage guidance, and prerequisites (package, transport) are not discussed at all.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the initial creation state, later source/include writing under class lock, and batch recording behavior, but it omits important caveats such as permissions, transport implications, and the schema-noted fact that behavior_definition is not forwarded to the create request.

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?

The description is front-loaded with the core action, but the first sentence is long and syntactically dense, making the initial-state and class-lock details hard to parse. The batch-mode sentence is useful but the overall structure could be clearer and more concise.

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 complex mutation tool with no output schema, the description covers the initial creation state and batch behavior but does not describe what a normal non-batch call returns. It also does not clarify the relationship to UpdateClass for binding the behavior definition, though the schema supplies that caveat.

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 parameter meanings are largely provided by the schema itself. The description references class_name and behavior_definition and adds workflow context, but does not add substantive semantics beyond the schema, especially for detail, package_name, description, and transport_request.

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?

The description states a specific verb and resource: creates a RAP behavior implementation class identified by class_name. It also ties the class to a behavior definition, which distinguishes it from a generic class creation tool, though it does not explicitly compare itself to siblings like CreateClass or CreateBehaviorDefinition.

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 intended workflow: create the class in initial state, then write the FOR BEHAVIOR OF main source and implementations include afterwards. It also explains batch-mode usage, but it does not explicitly say when to choose this over CreateClass or CreateBehaviorDefinition, nor when not to use it.

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

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

With no annotations, the description carries the burden and does disclose useful behavior: a test-double compatibility pre-check, creation of a class holding local test classes, activation, and the operational constraint that it runs outside batch mode. It omits whether an existing class is overwritten, how errors surface, and how transport_request interacts with package type.

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?

Three sentences, front-loaded with the create action and the parameter roles, then prerequisites and the batch-mode caveat. Nearly every clause earns its place; the batch-mode note is terse but informative.

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 6-parameter mutation with no annotations and no output schema, the description covers the create/activate sequence and one pre-check, but says nothing about the response shape, the transport_request parameter (required for transportable packages per schema), or failure modes.

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 the baseline is 3. The description adds only marginal meaning beyond the schema — clarifying that class_name is the global class that holds the local test classes and that test_class_source feeds 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 and resource: creates an ABAP Unit test class for a named CDS view. The CDS-view framing implicitly separates it from the sibling CreateUnitTest / CreateProgramUnitTest / CreateFunctionGroupUnitTest family, though it does not name those alternatives explicitly.

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?

Usage is implied by the resource type (CDS view unit test) and one prerequisite is stated (the view must support CDS test doubles), but nothing says when to choose this over CreateUnitTest or UpdateCdsUnitTest, or what to do if the class already exists.

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

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

With no annotations, the description carries the behavioral burden and does disclose two non-obvious traits: the object is created with no source code, and in batch mode the call is merely recorded and returns empty content that must be read back by number. It omits permission, transport, and error/failure behavior, which keeps it below 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the core creation semantics front-loaded and the batch-mode caveat appended. No filler or repetition of the title.

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?

Given a 10-parameter mutation tool with no annotations and no output schema, the description covers the key facts an agent needs: what exists after the call and how batch answers are retrieved. It could say more about the transport_request prerequisite for transportable packages and what the detail levels return.

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 every one of the 10 parameters is already documented in the schema. The description reiterates class_name and package_name semantics but adds no extra meaning for the boolean flags, the detail enum, or transport_request (whose 'not a task' caveat lives only in the schema).

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 (Creates) and resource (ABAP class) and pins the scope to class_name/package_name. The clause 'in initial state: the class object alone; its source code is written by an update of the class' implicitly differentiates it from UpdateClass, though the sibling is never named.

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?

Conveys that this tool only creates the shell and that source population belongs to a separate update step, which is useful routing information. However, no alternative tool is named explicitly and there is no when-not-to-use guidance (e.g. if the class already exists).

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

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

With no annotations, the description carries the full burden and does disclose two important behaviors: the object is left in an initial (not usable/activated) state, and the tool cannot run in batch mode. It does not cover failure modes on name collision, permission requirements, or the fact that label/search-help parameters are applied in a second update step.

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?

Three short sentences with the core action front-loaded and the two behavioral caveats following. Minimal waste, though "Creates the data element object" slightly restates the opening clause.

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 an 18-parameter creation tool with no annotations and no output schema, the description covers the essentials (initial state, non-batch) but leaves out what the agent most needs next: that activation via ActivateDataElement is required, and whether transport_request is mandatory for transportable packages.

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 all 18 parameters are already documented in the schema, including the post-creation update-step note on label fields and the transport request caveat. The description adds nothing beyond that, so baseline 3 applies.

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?

The description states a specific verb and resource ("Create a new ABAP data element") and a meaningful scope detail ("in initial state"). Siblings like UpdateDataElement, CheckDataElement, and ActivateDataElement are distinguishable by name, but the description does not explicitly contrast with them.

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?

"Runs outside batch mode" is a real usage constraint that tells an agent not to call this inside BatchBegin/BatchEnd. However, it gives no guidance on when to prefer this over UpdateDataElement, or on the prerequisite sequence of create-then-activate that the sibling set implies.

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

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

With no annotations, the description carries real weight: it discloses that the object lands in initial (unactivated) state, that source code is written afterwards, and the non-obvious batch semantics (empty answer recorded under the next batch number, read afterwards by number). It omits error/rollback behavior and any hint that transport_request may be required for transportable packages.

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?

Two sentences, purpose front-loaded, and every clause carries operational information (initial state, source written after, batch recording and retrieval). Nothing is redundant padding.

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 6-parameter create tool with no annotations and no output schema, the description supplies creation state, ordering of source write, and batch return semantics. It is nearly complete; the remaining gaps are activation follow-up and transport/auth preconditions.

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 the baseline is 3. The description only restates that ddl_name and package_name name the object and package, adding no meaning beyond the schema for those or for detail, master_language, description and transport_request.

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 (Creates) and resource (CDS view or classic DDL view), and ties both required parameters to the action, so it is clearly distinct from UpdateDdl/DeleteDdl/ActivateDdl siblings. It stops short of explicitly naming those siblings as alternatives.

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?

Usage is only implied: 'Creates ... in initial state' tells the agent this is for bringing a new DDL object into existence rather than modifying one, and the closing clause explains batch-mode use. There is no explicit when-not guidance or pointer to ActivateDdl/UpdateDdl for follow-up steps.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the domain is created in initial state and that it runs outside batch mode, but it omits permissions, transport behavior, idempotency, failure modes, and what happens when activation is enabled by default.

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?

The description is three short sentences with no filler, and the core action is front-loaded. The initial-state and batch-mode notes are relevant and compact.

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?

This is a 15-parameter mutation tool with no annotations and no output schema, yet the description is very thin. The schema covers parameters well, but the description does not explain return behavior, lifecycle implications, or key creation prerequisites, leaving important context gaps.

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 the schema already documents all 15 parameters in detail. The description adds no parameter-specific semantics beyond the action itself, which meets the baseline for fully covered schemas but does not add extra guidance.

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?

The description states a specific verb and resource: 'Create a new ABAP domain in SAP system.' It distinguishes creation from sibling operations such as UpdateDomain, ActivateDomain, and DeleteDomain by specifying that the object is created 'in initial state.'

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 this is for creating a new domain, and 'Runs outside batch mode' gives one execution constraint. However, it does not explicitly say when to use this instead of UpdateDomain or ActivateDomain, nor does it state prerequisites or exclusions beyond batch mode.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the non-obvious batch-recording behavior when activate is false, but omits what happens if the group already exists, whether the operation is destructive, permission/transport prerequisites, and any failure modes.

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?

Purpose is front-loaded in the first sentence, followed by a short clarifying clause and one batch-mode caveat. The batch sentence is slightly dense but every sentence contributes; nothing is padding.

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 7-parameter mutation tool with no annotations and no output schema, the description covers purpose and one behavioral quirk but leaves out creation-side outcomes (return shape, collision handling, transport application). It is usable but not complete.

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 parameters are already documented, and the description adds only marginal semantics by elaborating on the activate=false case that the schema touches on briefly. Baseline 3 applies.

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 and resource ('Create a new ABAP function group in SAP system') and adds a definitional clause about function groups being containers for function modules. This clearly separates it from UpdateFunctionGroup, DeleteFunctionGroup, and GetFunctionGroup.

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 activate=false sentence implies a batch-usage context, giving some when-to-use signal, but there is no explicit routing against siblings (UpdateFunctionGroup for modification, CheckFunctionGroup for validation) and no prerequisites such as package/transport requirements.

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

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

With no annotations, the description carries the burden and does disclose non-obvious behavior: the classes go into a test include that is activated along with the group, and the operation runs outside batch mode. It omits permissions, transport behavior, and reversibility, but the key side effects are stated.

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?

Three compact sentences with the target object and inputs front-loaded, then the persistence/activation behavior, then the batch-mode constraint. No filler.

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 mutation tool with no annotations and no output schema, the description covers destination, activation behavior, and an execution constraint. It does not describe what the call returns (implied only by the detail parameter enum), which is a minor gap given the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.