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

There are no annotations, so the description carries the full burden. It conveys some behavioral context (activation resolves an object left inactive after create/update), but says nothing about side effects, permission needs, whether activation triggers dependency/compilation failures, or reversibility. Adequate but incomplete for a state-changing 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 short sentences, purpose front-loaded, with the workflow condition second and no wasted words.

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

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

For a simple scope-activation tool with no output schema, the description covers the action and its place in the create/update workflow. The main gap is the absence of any note on activation dependencies or side effects, which matters more given there are no annotations.

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 name, detail, session_id, and session_state. The description adds no extra parameter semantics beyond what the schema provides, 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 (Activate) and resource (RAP behavior definition), which distinguishes it from the many other Activate* siblings that target different object types. An agent can route to it 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?

Gives explicit context — use it after CreateBehaviorDefinition or UpdateBehaviorDefinition when the object remains inactive — and names both relevant siblings. It does not mention the generic ActivateObjects alternative for batch activation, so it stops just short of full when/when-not 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 provided, so the description carries the full burden. It says nothing about side effects, whether activation can fail on syntax errors, idempotency, permissions, or session handling, despite session_id/session_state being part of the call. Only the minimal mutation implication of 'Activate' is conveyed.

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 short sentences, front-loaded with the action and followed by the triggering condition. 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 simple activation tool with fully documented parameters, the description covers the core intent. However, with no annotations and a nested session_state parameter, it omits session requirements and failure behavior that an agent would need to invoke this reliably.

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 class_name, detail, session_id, and session_state. The description adds no parameter guidance beyond that, 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 ('Activate') and resource ('ABAP class'), which cleanly separates it from the many Get*/Create*/Update* siblings. It does not name ActivateObjects, the generic bulk activator, but the resource specificity makes the target unambiguous.

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 clear when-to-use context: after CreateClass or UpdateClass if the object remains inactive. This names the sibling operations that typically precede it. It stops short of stating when NOT to use it (e.g., vs. ActivateObjects for batch 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?

No annotations are provided, so the description carries the full burden. It implies a state-changing activation but says nothing about side effects, whether it requires a lock, whether it is reversible, whether other inactive objects are pulled in, or what happens on failure — significant gaps for a mutation tool with zero annotation coverage.

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 action stated first and the precondition second. Front-loaded and 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?

The description adequately covers what the tool does and when, but for a mutation tool with no annotations and no output schema, it omits behavioral detail an agent would want (activation effects, error/prerequisite handling). Minimum viable rather than 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% with four well-described parameters (detail, session_id, session_state, data_element_name), so the schema does the heavy lifting. The description adds no parameter meaning beyond the schema, so baseline 3 is correct.

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 ('Activate an ABAP data element') and clearly distinguishes itself from the many sibling Activate* tools by naming the object type. An agent can route to it 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?

Explicitly specifies when to use it: 'after CreateDataElement or UpdateDataElement if the object remains inactive' — naming the sibling operations that precede it and the condition that triggers it. It lacks explicit when-not-to-use guidance, but the sequencing context is strong.

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 disclosure burden. It adds real workflow context (activation is a post-create/update remediation step only needed while the object is inactive), but is silent on permissions, transport/lock implications, idempotency on an already-active object, and failure behavior for a state-changing 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 short sentences, zero filler. Purpose comes first, the usage condition second — correctly front-loaded for a quick routing decision.

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 four-parameter, state-changing tool with no annotations and no output schema, the description covers what and when but not the operational details an agent needs (session handling via session_id/session_state, effect on the active/inactive state, error semantics). Adequate but with 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 description coverage is 100%: ddl_name, detail, session_id and session_state are all documented in the schema itself. The description adds no field-level meaning (e.g. that ddl_name is the DDL source rather than a database table), so the schema does the heavy lifting and 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 (Activate) and a specific resource (CDS view / DDL source), which cleanly separates it from the many sibling Activate* tools (ActivateClass, ActivateTable, ActivateStructure, etc.). An agent can identify the target object type 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?

Explicitly conditions use: run it after CreateDdl or UpdateDdl when the object 'remains inactive', which tells the agent when this step is required. It does not, however, mention bulk alternatives such as ActivateObjects or an environment-inactive check via GetInactiveObjects, so the routing is clear but not exhaustive.

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 mentions the precondition that the object must be inactive, but says nothing about what activation changes, whether it requires permissions or a session, whether it is reversible, or what happens on failure—major gaps for a state-changing 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 tightly written sentences with no filler. The core action is front-loaded and the usage condition follows immediately, making it easy to scan.

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 activation mutation tool with no annotations and no output schema, the description is too thin. It covers when to invoke it but omits behavioral details such as session requirements, side effects, failure modes, and how it relates to the generic ActivateObjects sibling.

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 four parameters including the detail enum and session fields. The description adds no parameter-level information beyond what the schema 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 ('Activate') and resource ('ABAP domain'), which distinguishes it from the many other Activate* siblings by resource type. However, it never explicitly differentiates itself from generic activation tools like 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?

Provides a clear triggering condition: use after CreateDomain or UpdateDomain when the object remains inactive. It does not state when not to use it or name alternative activation paths (e.g., ActivateObjects), so it is clear context without full when/when-not 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 provided, so the description carries the full burden. It implies a state-changing operation but says nothing about side effects, lock/transport implications, permission requirements, or whether activation is reversible or can fail on errors in the group. All of that is left to inference for a mutation 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 padding, with the action stated first and the precondition second. Nothing 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?

Purpose and the key usage condition are covered, and the rich schema compensates for parameter details. With no annotations and no output schema, however, the description omits behavioral aspects (side effects, failure modes, session handling relevance) that an agent would want before invoking 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 every parameter (function_group_name, session_id, session_state, detail) is already documented in the schema, including the detail enum. The description adds no parameter-level meaning beyond that, which is the baseline 3 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 (Activate) and a specific resource (ABAP function group), which cleanly distinguishes it from the many non-activation siblings. It doesn't explicitly differentiate itself from generic siblings like ActivateObjects or the parallel ActivateFunctionModule, but the specific resource noun makes the target unambiguous.

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?

Gives a concrete usage condition: call it after CreateFunctionGroup or UpdateFunctionGroup when the object remains inactive. That routes the agent well for the common case, though it never explains when to prefer the generic ActivateObjects instead or what to do if activation fails.

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 behavioral burden, and it discloses almost nothing: no statement of what activation changes, whether it fails on syntax errors, whether it needs an existing session/lock, or whether the operation is reversible. Only the implicit mutation semantics can be inferred from the verb.

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 short sentences, zero filler, with the action front-loaded and the precondition second. Nothing could be trimmed without losing signal.

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 is thin on failure modes and return expectations, though the 100%-covered schema handles the input side. It is minimally sufficient to invoke but leaves the agent guessing about activation errors.

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%, with function_module_name, function_group_name, session_id, session_state and detail all documented in-schema, so the baseline is 3. The description adds no parameter meaning beyond the schema, such as that the two required names identify the object to activate.

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?

Specific verb (Activate) plus a specific resource (ABAP function module), so the agent knows exactly what the tool performs. It does not differentiate itself from siblings like ActivateObjects or ActivateFunctionGroup, which is the only gap.

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?

"Use after UpdateFunctionModule if the object remains inactive" gives a concrete trigger condition tied to a named sibling, which is above-average routing guidance. It stops short of stating when NOT to use it (e.g. preferring ActivateFunctionGroup or batch ActivateObjects).

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 of behavioral disclosure for a mutation tool. It hints at a state transition (inactive -> active) but says nothing about idempotency, required locks/transport entry, permissions, whether activation can partially succeed, or what an already-active object returns. That is a substantial gap for an activation 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, zero waste, with the purpose and the trigger condition both front-loaded. Nothing is repeated from 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?

With no output schema and no annotations, the description should compensate more than it does. It covers purpose and trigger adequately for a single required parameter, but omits the failure/return behavior an agent needs to interpret an activation result.

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 a documented enum for 'detail' and an explanation of session_id/session_state, so the schema already carries parameter meaning. The description adds nothing about parameters, which is acceptable at this coverage level but not above 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 ('Activate an ABAP interface'), which is unambiguous and matches the naming family of ActivateClass/ActivateTable/etc. It does not, however, distinguish itself from the generic sibling ActivateObjects, which could plausibly activate an interface too, so the agent must infer the boundary.

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?

Gives a clear trigger condition: 'Use after CreateInterface or UpdateInterface if the object remains inactive.' That tells the agent when the tool is warranted rather than leaving it to inference. It stops short of naming alternatives (e.g., ActivateObjects) or explaining what to do if activation fails.

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 behavioral burden. It discloses the key state-transition trigger (post-create/update, object inactive), but says nothing about required permissions, session prerequisites, failure modes, or side effects on dependents, which matters for a mutation 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, no filler, and the core action is front-loaded ahead of the conditional prerequisite. Every clause 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 and no annotations, so the description is the only source of behavior, and it stops at the trigger condition. For an activation mutation tool, an agent would still want to know what activation returns or how failures surface, but the essential calling context 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% with four well-documented parameters (name, detail, session_id, session_state), so the schema does the heavy lifting and the baseline of 3 applies. The description adds nothing about how name or session data should be supplied.

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 (activate a CDS metadata extension), which cleanly separates it from the many other Activate* siblings (ActivateDdl, ActivateClass, ActivateTable, etc.). An agent can identify the correct tool 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?

Explicitly tells the agent when to reach for this tool: after CreateMetadataExtension or UpdateMetadataExtension, and only when the object remains inactive. It does not mention the generic ActivateObjects alternative, so it falls just short of full routing 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 provided, so the description carries the full behavioral burden. It discloses one useful trait – implicit dependency ordering via the 'domains + data elements + tables together' example – but says nothing about failure modes, whether partial activation is possible, dependency resolution, or permission requirements for a state-changing 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 tight sentences, front-loaded with the action and scope followed by usage context. Every clause earns its place with no redundancy.

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 activation tool with no annotations and no output schema, the description covers purpose, timing, and grouping well. It is only slightly short on what happens on success/failure or ordering guarantees, which keeps it from a 5.

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 params ('objects' array with per-item type codes and 'preaudit') are already fully documented in the schema. The description adds no syntax or semantic detail beyond it, so the baseline 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?

States a specific verb and resource ('Activate ... ABAP repository objects') and immediately distinguishes itself from the many singular ActivateXxx siblings with 'one or multiple' and 'group activation of related objects'. An agent can tell this is the batch/multi-object activation tool 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?

Gives clear when-to-use context: 'Use after Create/Update when objects remain inactive, or for group activation of related objects'. The example (domains + data elements + tables) clarifies the group case. It does not explicitly name the per-type ActivateDomain/ActivateClass alternatives or when to prefer them, so it stops short of a 5.

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. Beyond implying a state-changing operation, it says nothing about side effects, required permissions, whether activation is idempotent, or what occurs if the object is already active.

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 short sentences with zero padding; the action is front-loaded and the usage condition follows immediately.

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 no-annotation, no-output-schema mutation tool, the description covers purpose and usage but omits behavioral context (permissions, failure modes, effects). Adequate but with a clear gap given the absence of structured hints.

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 four parameters (name, detail, session_id, session_state) are already documented in the schema. The description adds no extra meaning about parameter formats or interactions, 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 (Activate) and resource (ABAP service binding), making it immediately distinguishable from GetServiceBinding, DeleteServiceBinding, ValidateServiceBinding and the many 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?

Explicitly names the triggering tools (CreateServiceBinding, UpdateServiceBinding) and the condition under which activation is warranted ('if the object remains inactive'), so the agent knows when this follows on from those operations. It lacks an explicit exclusion (e.g., using ActivateObjects for batches), so it falls just short of a 5.

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 only implies activation is conditional on an inactive state, but says nothing about permissions, transport implications, failure modes (e.g. syntax errors blocking activation), reversibility, or what activation changes. For a mutation tool with zero annotation coverage this is a substantial gap.

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 action front-loaded and the triggering condition immediately after. No filler and nothing to trim.

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?

Purpose and trigger are covered and the parameter schema is fully documented, but with no annotations and no output schema the description leaves behavioral expectations (side effects, failure conditions, what 'active' yields) unstated. Adequate but not 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 schema already documents name, detail, session_id and session_state, including the enum meaning. The description adds no parameter-level meaning 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: 'Activate an ABAP service definition.' This clearly separates it from GetServiceDefinition/CreateServiceDefinition/DeleteServiceDefinition. It does not, however, distinguish it from the generic ActivateObjects sibling, which also performs activation.

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?

Gives an explicit trigger: 'Use after CreateServiceDefinition or UpdateServiceDefinition if the object remains inactive.' This names the preceding lifecycle steps and the condition that warrants activation. It stops short of naming an alternative (e.g. ActivateObjects) or stating 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?

No annotations are supplied, so the description carries the full behavioral burden. It conveys a precondition (object must still be inactive) but says nothing about side effects, whether activation is a mutation, permission requirements, error behavior if already active, or what the activation result 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 short sentences, zero filler, with the action front-loaded and the precondition immediately after. Nothing could be trimmed without losing information.

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

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

For a simple activation operation with fully documented parameters and a session-management pattern already in the schema, the description is adequate on the input side. It is thin on the output side (no output schema) and does not hint at what activation returns, such as messages or remaining inactive objects.

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 detail, session_id, session_state, and structure_name are all documented in the schema itself. The description adds no parameter-level meaning, which is acceptable at full coverage but yields only the baseline score.

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 ("Activate an ABAP structure"), which cleanly separates it from the many other Activate* siblings that target tables, classes, domains, etc. It does not explicitly name the generic ActivateObjects alternative, so the differentiation is implied by resource rather than spelled out.

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?

Gives a clear triggering condition: use it after CreateStructure or UpdateStructure when the object remains inactive. This is real guidance about lifecycle ordering, though it offers no exclusions (e.g., what to do if the object is already active, or when to prefer the bulk ActivateObjects).

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 says only that it activates the table, with no mention of permissions, transport implications, reversibility, or side effects of activation on dependent 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?

Two short sentences, front-loaded with the action and followed by the workflow condition. No filler, though the second sentence could have been folded in more tightly.

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 four params including a nested session_state object and no output schema, the description covers only the trigger. It leaves session handling and activation semantics to the schema, which is adequate but leaves behavioral gaps unfilled.

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 four parameters (detail, session_id, table_name, session_state) are already documented in the schema. The description adds no extra meaning about parameter usage, 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 (Activate) and resource (ABAP table), so the core action is unambiguous. It does not differentiate itself from the many sibling Activate* tools (e.g., ActivateObjects, ActivateStructure), though the resource in the name makes the target reasonably 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?

Explicitly ties usage to a workflow: run after CreateTable or UpdateTable when the object remains inactive. This gives a clear trigger condition, but offers no exclusions or named alternative (e.g., ActivateObjects for batch 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?

No annotations are provided, so the description carries the full behavioral burden. It states the mutation happens but not whether it requires a modifiable transport, what happens if the object is already in the request, whether it errors on a released task, or what permissions are needed — significant gaps for a write 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?

A single sentence with zero filler, front-loading the action and following with the effect. Nothing to trim.

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 should explain prerequisites, failure modes, and effect on the transport request. It covers only the bare intent, leaving an agent unable to predict what will happen on error or on an already-released transport.

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 notable warning that object_type is an object-directory type (CLAS, FUGR) rather than an ADT type code, so the schema already does the heavy lifting. The description adds no parameter-level meaning beyond the schema, which is the baseline 3 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+resource ('Add an existing ABAP object to a transport task') and adds the consequence ('so it travels with the task's request'), which makes it distinguishable from the sibling RemoveTransportObject. It doesn't explicitly name siblings, so it falls just 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 word 'existing' implies the object must already exist, and the tool's intent (assign an object to a task) is inferable, but there is no explicit when-to-use guidance, no prerequisites (e.g., transport must be modifiable/unreleased), and no mention of when to prefer this over CreateTransportTask or ReadTransportObjects.

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 the return content (syntax errors, warnings, messages), which is genuinely useful behavioral information. However it does not state that the operation is read-only/non-persisting, whether it requires an activation lock, or any permission constraints, leaving notable behavioral gaps for a mutation-adjacent check 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 with zero redundancy: the first front-loads purpose and resource, the second covers the return contract. Since no output schema exists, the return statement is informative rather than filler, so every sentence 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 low-complexity, 2-parameter check tool with 100% schema coverage and no output schema, the description covers both purpose and return shape adequately. It is slightly thin on behavioral/read-only semantics, but the detailed 'version' param schema compensates for much of the operational nuance an agent needs.

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 carries unusually rich guidance (inactive default, active fallback behavior, empty-source findings). The description adds nothing about parameters, so the baseline 3 applies since the schema already 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 (syntax check) and resource (ABAP behavior definition / BDEF), so it is distinguishable from the Get/Update/Activate/Create BehaviorDefinition siblings. It does not explicitly contrast itself with the Check* family (CheckClass, CheckTable, CheckDdl), but the resource-specific naming makes the intent unambiguous.

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 provides no when-to-use, when-not-to-use, or alternative guidance. It never says whether this is a pre-activation gate, whether it overlaps with RunATC/GetATCFindings, or that it should be used before ActivateBehaviorDefinition. Usage is only implied by the tool name.

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. It discloses the return content (syntax errors, warnings, messages) and the fact that hypothetical validation does not create an object, which is genuinely useful. However, it never explicitly states that the operation is read-only/non-mutating for the existing-class path, nor mentions permission or lock prerequisites, so behavioral coverage is incomplete for a zero-annotation 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?

Three short sentences with the core action front-loaded and no filler. Slightly dense but every sentence carries purpose or mode information; no structural 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?

No output schema exists, and the description compensates by naming the returned content (errors, warnings, messages). It also covers both operating modes, so an agent has enough to call it correctly. The lack of explicit read-only confirmation and guidance against sibling check/analysis tools is the only real 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 description coverage is 100%, so all three parameters, including the active/inactive enum and the complete-source requirement for source_code, are already documented in the schema. The description restates the mode distinction but adds no syntax, format, or constraint detail beyond what the schema provides, 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 ('syntax check') and resource ('ABAP class'), and by naming the resource it distinguishes itself from siblings like CheckInterface, CheckTable, and CheckDdl. An agent can identify the target of the check 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 explains the two usage modes clearly: checking an existing class (active or inactive) versus validating hypothetical source code that is not yet an object. It gives solid context but names no alternative or exclusion, e.g. it never contrasts itself with GetAbapAST, GetAbapSemanticAnalysis, or RunATC, so the agent must infer when a syntax check beats those tools.

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 that the tool is a non-mutating check and what it returns (errors, warnings, messages), but it omits the version-default pitfall (defaults to inactive, which fails for active-only objects) and any auth/permission context.

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 short sentences, front-loaded with the action and resource, then the return content. No filler or repetition.

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

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

For a simple read-only check with no output schema, the description adequately covers both what the tool does and what it returns. The remaining gap is the unmentioned version-default behavior, which matters for correct invocation but is documented in the schema.

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%: both parameters, including the tricky version enum, are thoroughly documented in the schema itself. The description adds no parameter meaning beyond that, 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 ('perform syntax check') and resource ('ABAP data element'), which cleanly separates it from the many sibling Check* tools (CheckClass, CheckTable, CheckStructure). It does not explicitly name or contrast with those siblings, 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?

There is no guidance on when to use this tool versus alternatives such as GetDataElement, CheckTable, or RunATC, nor any note about prerequisites (e.g., the object must exist). The description is purely declarative.

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 disclosure burden. It reveals the return payload (syntax errors, warnings, messages) and the two check modes, but never states that the operation is read-only/non-mutating, nor whether the target view must already exist or what happens if it does not.

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 two modes, then the return content. No filler and nothing restated twice.

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 annotations and no output schema, the description does the necessary work: what it checks, the two modes, and what comes back. The remaining gap is behavioral (read-only nature, requirements on the target object), which is a modest omission for a check-only 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 three parameters are already fully documented in the schema and the baseline is 3. The description confirms the active/inactive distinction and the 'instead of the saved version' semantics of ddl_source but adds no format or interaction 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+resource combination ('perform syntax check on an ABAP CDS view'), which cleanly separates it from the other Check* siblings (CheckClass, CheckTable, CheckStructure) by object type. It stops short of the explicit sibling-contrast phrasing that would earn 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?

Makes the two operating modes explicit: check an existing view (active or inactive) or validate a hypothetical DDL source. That tells the agent which mode to pick, though it offers no exclusions or pointers to adjacent tools (CreateDdl/UpdateDdl/ActivateDdl) that a check might precede.

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. It does disclose the return content (syntax errors, warnings, messages), which is useful, but says nothing about side effects, preconditions, or which versions are applicable; the version-import pitfall is documented only in 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?

Two short sentences, front-loaded with the action and resource, and the second sentence efficiently covers the return content. 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 simple check tool with no output schema, the description is adequate but leaves out the workflow context an agent needs — e.g., the relationship to ActivateDomain and the active/inactive version behavior, which matters given how many Check* tools 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 schema text is unusually detailed (defaults to inactive, active-only objects error out). The description adds no parameter meaning, so the baseline of 3 applies because the schema already 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?

The description names a specific verb (syntax check) and a specific resource (ABAP domain), so it is easily distinguished from the large Check* family (CheckClass, CheckTable, CheckDdl, etc.) by resource. It is clear but does not explicitly contrast itself with those siblings or with ActivateDomain.

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?

No when-to-use guidance is given: it does not say to run this before ActivateDomain, nor that it operates against the active/inactive version. The only usage-relevant context lives in the version parameter's schema description, not in the tool 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the return content (syntax errors, warnings, messages), which is useful, but says nothing about whether the check mutates state, permission requirements, or how the omitted-version default behaves — the latter matters a lot and is only in 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?

Two short sentences, purpose first, return values second, with zero filler. Nothing could be removed without losing information.

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?

Adequate minimum for a simple read-style check tool: purpose, resource, and return content are covered, and the parameter nuance is handled by the schema. However, with no annotations and no output schema, the description could have said more about safety and how findings are scoped.

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%; the version parameter carries an unusually detailed description of the default-inactive pitfall. The description text adds no parameter meaning of its own, 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 (syntax check) and resource (ABAP function group), and names the return payload (errors, warnings, messages). This clearly separates it from sibling Check* tools that target classes, interfaces, tables, or function modules.

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?

No guidance on when to run this check versus RunATC or the other Check* tools, no mention of prerequisites, and no note about the active/inactive version decision (that trap lives only in the schema). The agent gets no routing help from the description itself.

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 must carry the full load. It discloses that the check returns syntax errors, warnings, and messages, which is useful output context, but it does not state that the operation is read-only or mention any permission requirements. This partial disclosure warrants a mid-range score.

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 zero waste, front-loading the action, followed by the return description. Every sentence 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 simple check tool with no output schema and no annotations, the description covers the purpose and return values adequately. It lacks usage guidelines, but given the clear name and full schema, an agent can invoke it correctly. Minor gaps remain.

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 all three parameters. The description adds no additional parameter semantics beyond what is already in the structured data. Baseline 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?

States a specific verb ('Perform syntax check') and resource ('ABAP function module'). It distinguishes itself from sibling Check* tools like CheckFunctionGroup by naming the exact object type. The second sentence clarifies the return values.

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 no guidance on when to use this tool versus alternatives such as CheckFunctionGroup or GetFunctionModule. It simply states what it does without any conditions 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 annotations exist, so the description carries the full behavioral burden, and it delivers little: it never states that the check is non-mutating, that it does not change the object's state, or that the default target is the inactive version (that caveat lives only in the schema). Reporting the return content is the only behavioral information offered.

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 short sentences, front-loaded with the action and then the result. Nothing is redundant or 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 simple two-parameter check tool with no output schema and near-total schema coverage, the description is nearly sufficient: the agent knows the action, the subject, and the output category, and the schema supplies the version semantics. Only the absence of any usage/ordering context (e.g., relative to activation) keeps it from being fully 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%, and the 'version' parameter's schema text is far richer than anything in the description. The description adds no parameter meaning 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 and resource ('Perform syntax check on an ABAP interface') and adds the shape of the result ('syntax errors, warnings, and messages'). Within a large Check* family (CheckClass, CheckTable, CheckDdl, CheckFunctionGroup), naming the resource makes it immediately distinguishable from 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?

There is no guidance on when to run this check (e.g., before ActivateInterface, or as an alternative to RunATC/GetATCFindings), no prerequisites, and no exclusions. Usage must be inferred from the tool name alone.

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 discloses the return content (syntax errors, warnings, messages), which is useful, but it never states that this is a read-only, side-effect-free diagnostic or what permissions/state it requires. For a check tool this is adequate but thin.

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 action front-loaded and zero padding. The second sentence earns its place by stating the return shape, though it is fairly generic.

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 description does at least describe the nature of the output (errors, warnings, messages). For a two-parameter diagnostic tool this is close to complete, though it could say more about the object's expected state and that it does not mutate anything.

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 `name` and `version` (including the active/inactive behavior and no-fallback note) are already fully documented in the schema. The description adds no parameter meaning beyond that, 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 and resource: a syntax check on an ABAP metadata extension (DDLX). This clearly separates it from the Create/Get/Update/Delete metadata-extension siblings by the 'check' verb. It doesn't explicitly differentiate from the other Check* siblings (e.g., CheckDdl), though the resource name does the work implicitly.

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: run this to validate a DDLX for syntax problems. There is no explicit when-to-use, no mention of prerequisites (e.g., an object must exist), and no routing against related tools like ActivateMetadataExtension or CheckDdl. A reader can infer intent but nothing is 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?

No annotations are provided, so the description carries full burden. It states the check is a read-only syntax check and lists return categories, but doesn't disclose whether the check is synchronous, whether it consumes ATC-style resources, whether it has side effects, or whether it depends on activation 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?

Two short sentences, front-loaded with the action and scope. No waste, though the second sentence is essentially a return-value list which overlaps with output expectations.

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 and no annotations, the description should explain result structure or usage context. It mentions error/warning/message categories but leaves prerequisites, side effects, and differentiation from sibling Check* tools unexplained.

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 package_name and super_package parameters are already documented in the schema. The description adds no new parameter semantics beyond what's in 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 (syntax check) and resource (ABAP package), and names the return contents (errors, warnings, messages). It distinguishes itself from other Check* siblings by targeting a package specifically, though it doesn't explicitly reference CheckPackageLow or how it differs.

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?

No guidance on when to use this vs. alternatives. The schema's mention of CheckPackageLow hints at a sibling variant (low-level check), but the description itself offers no when-to-use or when-not-to-use context.

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. 'Syntax check' and 'returns syntax errors, warnings, and messages' make clear this is a non-mutating validation and describes the result shape, but there is no mention of permissions, whether it triggers activation, or performance/rate considerations.

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 core action, and no filler. The middle sentence is slightly redundant with the parameter schema but still earns its place by disambiguating the two modes.

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 3-parameter read-only validation tool with 100% schema coverage and no output schema, the description covers purpose, modes, and return content adequately. The only gap is behavioral detail on permissions and mode precedence, which is minor for this tool class.

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 enum for version, the ddl_code override, and structure_name are all documented in the schema. The description restates the active/inactive and DDL modes but adds no syntax, format, or precedence detail (e.g., what happens when both structure_name and ddl_code are given). 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 (syntax check) and resource (ABAP structure), and clarifies two modes (saved active/inactive version vs. hypothetical DDL). It distinguishes itself from the many other Check* siblings by naming the resource, though it never explicitly routes the agent away from CheckDdl even though the DDL-mode feature overlaps with that tool.

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 explains the two usage modes (existing structure vs. hypothetical DDL code), which implies when to reach for it, but names no alternatives or exclusions and gives no prerequisites. An agent must still infer whether to use this or CheckDdl for DDL validation.

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. It discloses the return content (syntax errors, warnings, messages), which implies a non-mutating check, but does not state whether checking a 'new' version has side effects or whether any state 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?

Three tight sentences, front-loaded with the core action and followed by the mode distinction and return content. No filler, though the second sentence slightly overlaps the schema's enum description.

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 three-parameter check tool with no output schema and no annotations, the description covers purpose, modes, and return shape adequately. It would be stronger if it clarified side effects for the 'new' version mode.

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 including the version enum. The description restates the two modes but adds no format or syntax detail beyond what the schema provides; 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 ('Perform syntax check on an ABAP table') and explains the two modes of operation. It is clear, though it does not explicitly differentiate itself from close siblings like CheckDdl, which also validates DDL code.

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?

Gives clear context for when to use it: checking an existing table's active/inactive version, or validating hypothetical DDL. No explicit exclusions or sibling routing are given, keeping it short of a 5.

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 adds only that the object is created 'in initial state', but says nothing about required authorizations, transport-request obligations, failure modes when the name already exists, or whether creation is reversible. The 'initial state' claim also sits oddly against the schema's activate=true 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?

Two short sentences, but the second largely restates the first's verb+resource before tacking on 'initial state'. It is compact yet partially redundant rather than tightly value-bearing.

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 9-parameter mutation tool with no annotations and no output schema, the description is too thin. It omits the activation relationship, transport handling, naming constraints relative to the root entity, and error conditions an agent must anticipate before invoking it.

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 each of the 9 parameters (including enums for detail and implementation_type) is already documented in the schema. The description adds no semantics beyond that, 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 (Create) and resource (ABAP Behavior Definition / BDEF), making it trivially distinguishable from its Get/Update/Delete/CheckBehaviorDefinition siblings. An agent can identify exactly what object type is created 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?

No guidance on when to use this versus alternatives (e.g., UpdateBehaviorDefinition, CreateBehaviorImplementation) or prerequisites such as needing a root CDS entity to exist. The 'initial state' note implies a subsequent activation step but never says so, and doesn't reconcile with the `activate` parameter defaulting to true.

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 the key behavioral trait: the object is created in an initial state with no FOR BEHAVIOR OF main source and no implementations include. It also flags the lock-handle prerequisite for the follow-up write. It does not cover error cases (e.g., existing object) or return behavior, 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?

Three tight sentences, front-loaded with the core action, then scope of the created object, then the follow-up workflow. 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?

There is no output schema and no annotations, but the description compensates by explaining the initial-state semantics and the two-step write flow via sibling tools. It is nearly complete for a create tool; only error/return behavior is left 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 description coverage is 100%, so the schema already documents all six parameters in detail, including behavior_definition's compatibility caveat and the transport_request requirement. The description adds no parameter-level meaning 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?

Specific verb+resource: 'Create a new ABAP behavior implementation class for a behavior definition.' It clearly distinguishes itself from CreateClass and CreateBehaviorDefinition by naming the exact artifact, and the follow-up sentence clarifies the scope of what is created.

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?

Explicitly routes the agent: use UpdateClass to write the main source, and UpdateBehaviorImplementation (with a lock handle from LockClass) to write the implementations include. This names alternatives and the conditions that select them, leaving nothing to inference.

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 usefully discloses that the tool mutates the system by creating and activating a class, and that it validates test-double support first, but it omits permission requirements, behavior when the view is not testable, and the role of the transport_request parameter.

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 a colon-delimited list of the three actions; no filler. Slightly dense, but every clause describes a distinct step of the operation.

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 six-parameter mutation tool with no annotations and no output schema, the description covers the main workflow but leaves gaps on prerequisites (active/package/transport state), failure modes when the view lacks test-double support, and the return shape. Adequate 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 all six parameters, including the enum for 'detail' and the transport_request note, are already documented in the schema; the description adds no parameter-level detail beyond the shared CDS-view wording. 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 (Create) and resource (ABAP Unit tests for a CDS view) and enumerates the three behaviors performed: test-double eligibility check, test class creation, activation. This distinguishes it from siblings CreateUnitTest and CreateFunctionGroupUnitTest, which target classes and function groups respectively.

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 internal step ordering ('check the view supports CDS test doubles, create a test class, activate it') implies the workflow, but the description never says when to pick this over CreateUnitTest or what prerequisite state the CDS view must be in beyond the schema hint 'must be active'.

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, so the description carries the burden. It usefully discloses that the object is created in initial (inactive) state, which is non-obvious behavior in SAP, but omits permission/authorization needs, the transport requirement implied by the transport_request param, and whether a subsequent activation is mandatory.

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, zero filler, with the core action stated first and the sibling hand-off last. Nothing redundant with the schema.

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 10-parameter mutation tool with no output schema and no annotations, the description covers the essential post-creation state and the follow-up tool. It stops short of mentioning activation requirements or authorization/transport constraints that an agent would need to complete 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?

Schema description coverage is 100%, so every parameter is already documented in the schema, including defaults, enum values, and the transport_request caveat. The description adds no parameter-level meaning beyond that, 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+resource ('Create a new ABAP class'), names the target system, and describes the resulting state ('initial state'), which separates it from GetClass/UpdateClass/ActivateClass 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?

Explicitly routes the agent to UpdateClass for the follow-up source-code step, which is the natural next action after creation. It does not state when NOT to use it (e.g. class already exists, activation prerequisites), so it falls short of a full 5.

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 for a mutation tool. It discloses only that the object is created inactive; it says nothing about required authorizations, transport requirements, whether a partial failure leaves an orphaned object, or error behavior.

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 short, front-loaded sentences with no filler. The verb+resource and the state outcome both land immediately.

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 schema compensates for parameter documentation, but the description omits the activation follow-up (ActivateDataElement), transport_request implications, and any failure semantics. It is minimally complete but leaves real workflow 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% across 18 parameters, so the schema already documents names, defaults, enum values, and the note that label/search-help fields apply 'during update step after creation.' The description adds nothing parameter-level beyond that, 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 ('Create a new ABAP data element') and adds that the object is left in 'initial state', which distinguishes it from ActivateDataElement and UpdateDataElement. It doesn't explicitly name those siblings, but the name/verb pair is unambiguous.

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 'in initial state' implicitly signals that a follow-up activation step is needed, but the description never names ActivateDataElement or states the workflow conditions. No prerequisites (package, transport) or when-not-to-use guidance is 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?

No annotations are provided, so the description carries the full burden. It does add useful behavioral detail by stating the object is created in 'initial state' (i.e. without source content). However, it omits critical operational facts such as whether the result is inactive/requires ActivateDdl, transport/auth requirements, and failure behavior.

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 short sentences, front-loaded with the action and immediately followed by the scope/state clarification and the next-step tool. Every sentence earns 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?

For a mutation tool with no annotations and no output schema, the description covers what is created and the follow-on write step, which is a solid core. It leaves out the activation requirement (a sibling ActivateDdl exists) and any indication of what the initial-state object contains, so an agent may not complete the full 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?

Schema description coverage is 100%, so all six parameters including detail, master_language and transport_request are already documented in the schema. The description adds no parameter-level syntax or semantics 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 ('Create a new CDS View or Classic View', 'Creates the DDL source object') and clarifies the resulting state ('in initial state'). It distinguishes itself from UpdateDdl, which handles the source code, so an agent can separate the two DDL-mutating tools. It does not, however, differentiate itself from the broader family of Create* tools beyond the resource name.

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?

Explicitly names the follow-on alternative: 'Use UpdateDdl to set DDL source code,' which routes the agent correctly after creation. This gives clear context but stops short of stating when-not-to-use or prerequisites (e.g. that the object is created inactive and needs 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?

No annotations are provided, so the description carries the full behavioral burden. Beyond 'creates the object in initial state', it says nothing about permissions required, what happens if the domain already exists, or the interaction between 'initial state' and the activate=true default — a significant gap for a 15-parameter mutation 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 short sentences, front-loaded with the core action. The second sentence is largely redundant restatement, but nothing is bloated.

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 15 parameters, no annotations, and no output schema, the description is far too thin. It omits creation-failure conditions, transport requirements, and the meaning of the initial vs activated state, leaving the agent reliant entirely on the schema.

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 15 parameters (datatype, length, decimals, fixed_values, transport_request, etc.) are already documented in the schema. The description adds no parameter meaning beyond it, so the baseline 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?

States a specific verb+resource (create an ABAP domain) and adds a state note ('initial state'), which distinguishes it from GetDomain/UpdateDomain/DeleteDomain by name. However, it does not explicitly differentiate itself from the sibling CheckDomain or ActivateDomain, and the 'initial state' claim sits in tension with the schema's activate default of true.

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?

No when-to-use guidance, no prerequisites (e.g., run CheckDomain first, or that transportable packages need a transport_request), and no alternatives named. The agent must infer everything from the name and schema.

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, and it discloses almost nothing beyond the mutation itself. It does not say that creation requires a transport request for transportable packages, what activation does or that it defaults to true, whether the operation fails on an existing name, or what permissions are needed. The second sentence is domain education, not behavioral disclosure.

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 short sentences, front-loaded with the action, with no filler. The second sentence is arguably optional context but is cheap and aids the agent's understanding of the object type.

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 creation tool with no annotations and no output schema, the description is thin: it omits transport semantics, activation consequences, and collision behavior. The rich, fully documented schema compensates for the parameter gaps, keeping this at minimum-viable rather than inadequate.

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 seven parameters (including transport_request, activate, master_language, and detail) are already fully documented in the schema. The description adds no parameter-level meaning, which is acceptable given the coverage, 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 and resource ("Create a new ABAP function group in SAP system") and adds a one-line domain gloss about what a function group is. Sibling tools like CreateFunctionModule, UpdateFunctionGroup, and DeleteFunctionGroup make the operation unambiguous by name, but the description itself 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?

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites (package must exist, transport requirements), and no routing to alternatives such as UpdateFunctionGroup or CheckFunctionGroup. The agent is left to infer usage purely from the tool name and schema.

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. It usefully discloses that the include is created together with its local test classes and that it is activated with the group, which is a real side effect. However, it says nothing about permissions, error/exception behavior, or what happens when the include already 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?

A single front-loaded sentence that names the action, the target, and the resulting artifact with no filler. It could have gone marginally further on lifecycle behavior, but every clause 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 mutation tool with no annotations and no output schema, the description covers what is created and that it is activated, and the 100%-covered schema handles parameters. It omits conflict/overwrite behavior and any indication of what a caller gets back, leaving meaningful gaps for an agent invoking a write 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 all four parameters are already documented (including that test_class_source replaces the include contents and that transport_request is required for transportable objects). The description only loosely maps to test_class_source and adds no format or syntax detail 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 ("Create") and resource ("ABAP Unit tests for a function group") and even describes the artifact produced: a test include with local test classes. This distinguishes it in substance from CreateUnitTest and UpdateFunctionGroupUnitTest, though it never names those siblings to route the agent 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 when-to-use or when-not-to-use guidance and no named alternative. The agent must infer from context that this is for function groups rather than the CreateUnitTest / CreateCdsUnitTest siblings, and the description offers no condition to select between them.

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 disclosure burden. 'Creates the include in initial state' is genuinely useful behavioral context (the result is likely inactive and will need activation), but permissions, transport behavior, failure modes, and side effects are not addressed.

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 short sentences with the core action front-loaded and no filler. The second sentence is slightly restating the first, but it contributes the 'initial state' detail, so the redundancy is minimal.

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 creation tool with no annotations and no output schema, the description covers what is created and its initial state but omits what the caller must do next (activation/check siblings) and what a successful result looks like. Adequate but with 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 description coverage is 100%, so the schema already documents all five parameters including transport_request and the detail enum. The description adds no parameter-level meaning beyond what the schema 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 (Create), resource (ABAP include) and scope (within an existing function group), which cleanly separates it from CreateFunctionGroup/CreateFunctionModule. It does not explicitly name a sibling alternative, but the verb+resource is unambiguous.

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?

No when-to-use guidance, no prerequisites, and no routing to alternatives such as CreateFunctionModule or UpdateFunctionInclude is provided. The parent-group constraint is embedded in the purpose statement rather than expressed as a usage rule.

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 disclosure burden. It adds one genuinely useful behavioral fact — the module is created 'in initial state' (implying activation is needed) — but omits transport/auth requirements, error behavior, and side effects on the parent group.

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 short sentences with no filler; the action and its scope come first, and the state note follows. Nothing is repeated from the tool name or schema.

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 no-output-schema creation tool the description covers the core action and the resulting state, and the schema carries all parameter documentation. It stops short of mentioning the required subsequent activation or transport concerns, which an agent would benefit from knowing.

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 detail, transport_request, description) are already documented in the schema. The description only echoes the required function-group relationship, adding no syntax or format detail beyond it. 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 module') and scopes it to an existing function group. It is distinguishable from CreateFunctionGroup/CreateFunctionInclude by naming the artifact type, though it never explicitly contrasts with those 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?

Gives no when-to-use guidance, no prerequisites beyond the implied existence of a parent function group, and names no alternatives. An agent gets no signal about ordering relative to CreateFunctionGroup or the follow-up ActivateFunctionModule step.

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 does disclose one real behavioral trait — the object is created "in initial state," implying a separate activation step — which is valuable. However it says nothing about required authorizations, the transport requirements implied by the transport_request parameter, or behavior when the interface already 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 short sentences, front-loaded with the action and resource. The second sentence partly restates the first ("Creates the interface object"), but the "initial state" clause earns its place by adding a behavioral 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 6-parameter mutation tool with no annotations and no output schema, the description covers the action and the resulting object state but omits the create/activate lifecycle, permission needs, and transport handling. That is minimally adequate for an experienced SAP agent but not self-sufficient.

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 explains every parameter including the detail enum, master_language default, and the transport_request caveat. The description adds no parameter-level meaning, so the baseline 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?

States a specific verb+resource ("Create a new ABAP interface in SAP system"), which cleanly separates it from GetInterface, UpdateInterface, and the many other Create* siblings. It stops short of explicitly naming its counterparts, so it lands just under the top mark.

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 when-to-use guidance, no prerequisites, and no mention of the natural follow-up (ActivateInterface) that a newly created ABAP object requires. The agent gets no help deciding between this and CreateClass/CreateFunctionGroup or understanding the create-then-activate 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 behavior burden and does disclose two meaningful traits: this creates only a shell (not a populated class) and the result is not activated. It omits permissions/auth requirements and what the response contains, but the non-activation caveat is exactly the kind of non-obvious 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?

Two sentences, front-loaded with the core action, no filler. Each clause adds information: the shell nature, the follow-up sibling, and the non-activation 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 create operation with no annotations, no output schema, and fully documented parameters, the description covers what is created, what is left to a sibling tool, and the activation state. It is complete enough to invoke correctly, with only auth/response details 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 the schema already documents all six parameters including optionality, defaults, and the transport_request requirement. The description adds no parameter-level detail 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?

Specific verb+resource: "Create a new ABAP message class (T100) shell." It also distinguishes itself from CreateMessageClassMessage by stating that individual messages are added afterwards with that sibling, so an agent can route correctly without opening either 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?

It names the sibling CreateMessageClassMessage and the condition under which it is used (adding individual messages afterwards). It also implies a follow-up step by noting classes are not activated, but it does not explicitly point to an activation tool, so guidance is clear but not fully exhaustive.

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 behavioral burden. It discloses the key ordering constraint (parent class must pre-exist), which is genuinely useful, but says nothing about duplicate message-number behavior, transport/authorization requirements, or whether the message must be activated afterwards.

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 short sentences with zero padding; the action is front-loaded and the prerequisite follows immediately. Every clause 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 creation tool with no annotations and no output schema, the description covers the prerequisite but omits post-conditions such as activation state, duplicate handling, and transport implications. It is adequate but leaves meaningful gaps for an agent operating unattended.

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 placeholder syntax for msgtext and the optional fields, so the schema does the heavy lifting. The description only loosely maps to 'number + text' and adds nothing the schema does not already state.

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 — adding a numbered message text to an existing ABAP message class (T100). This is clearly distinguishable from sibling tools like CreateMessageClass, UpdateMessageClassMessage, and DeleteMessageClassMessage, so an agent can route correctly without opening a 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?

Provides a concrete prerequisite: the parent class must exist first, and it names CreateMessageClass as the tool that satisfies it. It does not, however, contrast with UpdateMessageClassMessage for editing an existing message number or note when this is inappropriate.

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 hints at a state outcome ('initial state') but says nothing about required permissions, transport locking, whether the object is inactive, or what happens on failure. Notably, the 'initial state' claim sits in mild tension with the schema's activate default of true, which the description does not reconcile.

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 short sentences, front-loaded with the core action. The second sentence is largely a restatement of the first with only marginal added value ('initial state'), but nothing is verbose or 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?

For a mutation tool with seven parameters, no annotations, and no output schema, the description is too thin. It omits transport handling, activation behavior, and permission requirements that an agent would need to invoke this correctly.

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 seven parameters including the detail enum and the activate default. The description adds no parameter-level meaning beyond that 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?

The description states a specific verb and resource: 'Create a new ABAP Metadata Extension (DDLX)'. It distinguishes itself from siblings like GetMetadataExtension and UpdateMetadataExtension by the word 'new', though it does not explicitly name 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?

There is no guidance on when to use this versus UpdateMetadataExtension, nor any mention of prerequisites such as needing a transport request or an existing package. The agent must infer usage entirely from the tool name.

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, and it discloses essentially nothing: no permission requirements, no transport/change-recording implications, no statement about whether creation is idempotent or fails on duplicate names. The second sentence is background description of ABAP packages, not behavioral context for the call.

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 short sentences, front-loaded with the action. The second sentence is arguably filler for an agent that already knows SAP, but it costs little and never buries the operative content.

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 mutating, 11-parameter creation tool with no annotations and no output schema, so the description should at minimum cover preconditions (transport layer/request for transportable packages) and what constitutes success or failure. It covers none of that, leaving the agent to reconstruct prerequisites from scattered schema property descriptions.

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?

With 11 parameters at 100% schema description coverage, the schema already documents each field, including the transport-related conditionals. The description adds no parameter-level meaning, 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 (create an ABAP package in an SAP system) and adds a one-line definition of what a package is. The purpose is unambiguous and separable from read-side siblings like GetPackage or GetPackageContents, though it does not explicitly name those 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., CheckPackage to validate first, GetPackage to inspect an existing one). The agent must infer everything about invocation context from the name alone.

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 does disclose that the binding is created "in initial state" (inactive), which is useful, but it omits transport/permission prerequisites, what happens on failure, and how the default activate=true interacts with that initial 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?

A single front-loaded sentence with no filler. For a 12-parameter mutation tool it is arguably too terse, which keeps it from a 5, but every word 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 12-parameter write tool with no annotations and no output schema, the description is thin. It says nothing about which parameters are required, transport handling, activation semantics, or error behavior, so an agent lacks the context needed to invoke it confidently.

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 12 parameters are already documented in the schema. The description's variant naming (V2 or V4, UI or Web API) merely restates the binding_variant enum rather than adding new meaning. 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 (Create) and resource (OData service binding), and scopes it to a service definition with the V2/V4 and UI/Web API variants named. It is distinguishable from UpdateServiceBinding/DeleteServiceBinding by the verb, though it never explicitly names those 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?

"in initial state" implies the object is created inactive and may need ActivateServiceBinding, but the description never states when to use this versus ActivateServiceBinding or ValidateServiceBinding. Usage is only implied, not 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?

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It says 'in initial state' but never clarifies what that means relative to the schema's activate=true default, nor whether a transport request is mandatory in practice, what permissions are required, or what happens on name collision.

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 no filler; the scoping phrase 'in initial state' is placed where it is most useful. It is efficient, though it could spend one more clause on behavior instead of being quite so terse.

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 8-parameter mutating tool with no annotations and no output schema, the description is thin: it does not explain the activation/transport implications or what is returned. The rich 100%-covered schema compensates on parameters, but the behavioral gap keeps this at minimum-viable.

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 defaults for detail, activate, description, source_code and master_language, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond that, which is the expected baseline 3 when coverage is complete.

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?

Specific verb+resource ("Create a service definition") plus scope detail ("exposes CDS views as an OData service, in initial state"). This clearly separates it from Get/Update/DeleteServiceDefinition and CreateServiceBinding, though no sibling is named 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?

No when-to-use context, prerequisites, or alternatives are given. The Agent must infer that this is the creation counterpart to the sibling read/update/delete tools, and nothing explains when a service definition is needed versus e.g. CreateServiceBinding.

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, yet it only says the object is created in 'initial state.' It omits critical traits such as the two-step create-then-update workflow, activation behavior, transport/lock requirements, and idempotency, all of which matter 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 short sentences with the verb and resource front-loaded and no filler. There is mild redundancy between 'Create a new ABAP structure' and 'Creates the structure object,' keeping it just short of a 5.

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 create tool with 9 parameters and no output schema, the description should surface the critical 'metadata-only create, then UpdateStructure with ddl_code' workflow, but it leaves that to the schema. The schema compensates, so the definition is adequate but not self-sufficient.

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 even explains the non-obvious caveat that `fields` and `includes` do not reach creation. The description itself adds no parameter meaning, so the baseline 3 applies as the schema does all 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?

The description states a specific verb and resource ('Create a new ABAP structure') and adds the scope qualifier that it lands in 'initial state,' which distinguishes it from sibling mutations like CreateTable and from UpdateStructure. It does not explicitly name those siblings, 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?

The phrase 'initial state' implies a follow-up step is expected, but the description never says when to prefer this over UpdateStructure or CreateTable. The important routing advice (use UpdateStructure with ddl_code after creating) 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?

There are no annotations, so the description carries the full disclosure burden. 'Creates the table object in initial state' usefully implies the object is not yet active, but the description says nothing about permissions, transport requirements, collision behavior when the table already exists, or reversibility — much of that is buried in the parameter 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?

Two short sentences, front-loaded with the action and then the resulting state. Nothing is wasted, though the brevity leaves it thin for a mutation tool with six parameters.

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 description should ideally cover the creation-to-activation workflow and transport implications. 'Initial state' gestures at the activation step but the transport-request prerequisite and the follow-up UpdateTable flow are only implied, leaving moderate gaps for a mutating 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% and the parameter descriptions are rich (transport request caveat, description-not-reaching-creation note, master language defaulting), so the schema does the heavy lifting. The tool description adds no parameter meaning beyond it, matching the baseline 3.

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 table in SAP system') and adds a state qualifier ('initial state') that distinguishes it from ActivateTable and UpdateTable. It doesn't explicitly name a sibling, but the create-vs-modify distinction is clear from the repository of sibling verbs.

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?

No guidance on when to use CreateTable versus CheckTable, ActivateTable, or the UpdateTable follow-up. The only usage hint lives in the schema's `description` parameter, not in the tool description itself, so an agent gets no tool-level context on preconditions or next 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?

With no annotations, the description carries the full burden. It implies a mutation but does not disclose required authorizations, whether the request is immediately released/usable, side effects, or whether a task is auto-created. For a write operation with zero annotation coverage, this is a substantial gap.

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 no filler. It is efficient, though it could carry one more routing or prerequisite clause without becoming bloated.

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?