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

There are no annotations, so the description carries the full behavioral burden. It discloses that unlock is sent automatically, except for DTPs and DataSources, and that impact analysis can deactivate DTPs that must be re-activated. This is strong side-effect transparency, though error behavior is not covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is efficiently organized and every sentence contributes: scoping sentence, lock-handle rules, source-system rule, and a side-effect warning. There is no filler or redundant text.

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

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

For a five-parameter tool without an output schema, the description covers the nu rules, provides usage conditions, notes side effects, and warns about required re-activations. It does not describe the exact success/error return shape, but the essential calling requirements are covered.

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%, giving a baseline of 3. The description adds real value beyond the schema by explaining when lock_handle must be empty, when source_system is required, and how unlock behavior varies by object type.

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 starts with a specific verb and resource: 'Activate one BW object' and lists the exact supported object types. This clearly distinguishes it from sibling tools like bw_activate_request and bw_activate_process_chain.

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 gives concrete usage rules: when to pass a lock_handle, when to pass an empty string, and when to include source_system. It does not explicitly name alternative tools for request or process-chain activation, but the object-type enumeration makes the intended scope clear.

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

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

No annotations provided, so description carries full burden. It discloses it activates (mutation), returns message, severity, and log entries, and surfaces errors. It does not mention if the chain must be inactive or if activation is synchronous, but provides good insight overall.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two terse sentences front-loaded with the main action. No redundant words; every sentence adds value.

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

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

Given the low complexity (one parameter), full schema coverage, and clear return value description, the tool is well-documented and complete for its scope.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description including case-insensitivity. The tool description does not add additional meaning beyond what the schema already provides, earning a 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?

The description clearly states it activates an existing Process Chain via the BW/4HANA Cockpit REST API, and distinguishes from sibling tools like bw_create_process_chain by specifying the use case after creation or reactivation.

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 says when to use: after bw_create_process_chain with activate=false or to re-activate a modified chain. It does not state when not to use, but the context is clear enough.

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 fully discloses key behaviors: it activates all previous loads up to the given request, moves data from Inbound Table to active data table and change log, and is asynchronous. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two well-structured sentences. The first sentence front-loads the action and scope, while the second provides important distinctions and asynchronous behavior. 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?

The description covers prerequisites (aDSO with activation step), scope (all previous loads), asynchronous nature, and post-call monitoring via sibling tools. With only two parameters and no output schema, this is complete and self-contained.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters (request_tsn and storage). The description adds context that request_tsn comes from bw_list_requests/bw_run_dtp output and notes that storage defaults to 'AQ', but this mostly mirrors the schema. The additional context about 'all previous loads' is more about overall behavior than parameter semantics, so 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?

The description clearly states the tool activates loaded data (DSO request activation) and distinguishes it from bw_activate, which does modeling-object activation. The verb 'activate' and resource 'DSO request' are specific, and the differentiation from the sibling tool is explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use (for aDSOs with an activation step) and when not (not for inbound-only staging aDSOs, not modeling-object activation). It also notes that activation is asynchronous and that progress should be monitored via bw_list_requests or bw_get_request.

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 alone discloses the full behavioral profile: it reads the current model, appends the edge, and PUTs it back; it is idempotent for identical edges; and ETag stalreferencing (412) is explicitly explained. This is strong transparency 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?

The description is dense but no word is wasted. Purpose, mechanics, usage scenario, edge-condition nuance, and error behavior are each given one clear sentence in a logical order. Nothing feels padded or redundant.

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

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

For a 7-parameter mutating tool with no annotations and no output schema, the description is nearly complete: it explains what the operation does, how it mutates, when the right to use it, how to express a special edge type, and what error message to expect on concurrency conflict. Remaining details already live in the well-described 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 coverage is 100% coverage, so the schema already documents each parameter thoroughly. The description adds meaningful cross-parameter semantics by explaining that an 'always continue'edge requires two calls with status 'positive' and 'negative', and that identical edges are skipped. This goes beyond the schema without repeating it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description opens with a precise verb and target: 'Add one dependency (edge) between two existing steps of a Process Chain (RSPC).' It also distinctly scopes the tool as in-place edge wiring, making it clearly distinct from sibling tools that create, remove, or append process-chain nodes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage context ('repair the wiring of a chain') with a concrete example (connecting the end of a newly inserted block to the next step). It also covers the special two-call pattern for 'always continue' dependencies. The only gap is that it does not explicitly route away from the sibling error-link and removal 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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It discloses the in-place edit pattern (read, modify, PUT), idempotency (skipping existing edges), optional activation, and ETag handling. This provides sufficient transparency beyond 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?

The description is a single paragraph with multiple sentences, each providing essential information. It front-loads the main action. While it could be broken into bullet points for readability, it remains concise and informative without 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?

Given the tool's complexity (mutation with side effects), no output schema, and 4 parameters, the description covers the process (read-modify-write), parameter usage, error handling, and activation. It lacks explicit return value details, but the overall context is sufficient for an agent to use it effectively.

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%, but the description adds significant value beyond the schema: it explains how `dtps` matches (exact DTP name or substring of step description), that `name` is case-insensitive, that `activate` defaults to false, and the transport request logic. This detail helps the agent use parameters correctly.

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 clearly states the tool's purpose: adding on-error links to a Process Chain by mirroring existing on-success links from DTP load steps. It uses specific verbs ('Add', 'mirroring') and identifies the resource ('Process Chain (RSPC)') and method (via BW/4HANA Cockpit REST API). It is distinct from sibling tools which deal with different operations on process chains.

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 when to use the `dtps` parameter to restrict to specific steps or omit to apply to all DTP load steps. It also mentions handling of ETag staleness with a 412 error. While it does not explicitly state when not to use the tool or provide alternative tools, the usage context is clear enough.

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 fully discloses behavior: in-place edit, idempotency (skip if same program/variant), edge rerouting details, and error handling. It also clarifies that only synchronous/local/defaults are verified. This provides comprehensive insight beyond the basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is detailed (~200 words) but efficiently combines multiple concepts: purpose, mechanism, positioning, edge mode, idempotency, and error handling. It is front-loaded with the core action. While concise given complexity, some technical details could be moved to notes, but overall it earns its space.

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

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

Given 15 parameters and no output schema, the description covers behavior, error handling, and positioning well. However, it does not describe the return value or output format for successful calls. For a tool without output schema, that omission leaves a gap, preventing the agent from fully understanding what to expect.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for each parameter, so baseline is 3. The main description adds value by explaining how 'before', 'after', and 'predecessor' affect chain structure (e.g., rerouting), and gives examples ('Start → PROGRAM → DTP'). It goes beyond schema details to contextualize parameter usage.

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 clearly states the tool adds an 'Execute ABAP Program' step to a Process Chain, specifying the API and mechanism. It uses specific verbs ('Add', 'runs an ABAP report') and distinguishes from sibling tools like bw_create_process_chain or bw_update_process_chain by focusing on inserting a program step into an existing chain.

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 positioning options (before, after, append), edge modes, and idempotency, providing clear guidance on how to insert the step. It also notes error handling (412 for stale ETag) but does not explicitly compare with alternatives for other step types or state when not to use this tool.

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 to rely on, the description fully carries the burden and does so thoroughly: it discloses the in-place read/modify/write behavior, ETag staleness producing a 412, idempotent skip when the DTP already exists, default dual-edge 'always continue' semantics, placement after verification, and the exact structural impact of append vs before/after. This is rich, non-obvious behavioral context well beyond just saying 'adds a step'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The text is long and dense, but nearly every sentence carries a distinct piece of operational guidance: position routing, edge default, idempotency, ETag failure, block placement. The main structural weakness is that many separate topics are blended together without breaks, so an agent must parse deeply, though no filler is present.

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

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

Given the tool's complexity (nine parameters, two required), no annotations, and no output schema, this description is remarkably complete. It covers the risky positioning semantics, default behaviors, failure mode for stale ETags, transport relevance, idempotency, and node reference forms, leaving an agent with the information needed to correctly invoke it and interpret unexpected results.

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?

Even though schema coverage is 100%, the description adds substantial semantic meaning: it explains how before/after interacts conceptually with rerouting, what 'neither' means for predecessor/strand end auto-selection, how adsoact makes the DTP and activation one block, and what edge_mode defaults and alternatives actually cause. The node-reference forms for predecessor and sibling named tools like bw_get_process_chain greatly enrich the raw parameter definitions.

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 opens with a specific verb-resource pair: 'Add one DTP load step (optionally followed by its own DSO activation step) to an existing Process Chain (RSPC)'. It clearly differentiates this tool from siblings like bw_swap_process_chain_dtp, bw_add_process_chain_program, and bw_add_process_chain_edge by naming the exact operation and its optional companion step.

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 gives explicit when-to and when-not-to instructions: use before/after when a step must complete before an existing one, and phrases like 'pass "before" to place...' and 'the block ends up running in PARALLEL to them, not ahead of them' spell out consequences. It also explains that edge_mode 'success_only' is what a chain with no existing error edges expects, giving actionable context for choosing parameters.

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, but the description covers key behaviors: read-modify-write, validation against admissible values, deactivation side effect, and empty string removal. No contradictions.

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 concise sentences with no fluff. Front-loaded with purpose and action, then side effects, then a specific parameter note.

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 output schema, the description adequately explains inputs, behavior, and side effects. Minor gap: no mention of return value or error handling, but overall 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 covers all parameters with descriptions. The description adds that 'delta_process' can be empty to remove and that it is validated against admissible values, providing extra context beyond basic schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the action ('change the delta process'), the resource ('DataSource RSDS deltaProperties'), and distinguishes from siblings like 'bw_activate' by noting the datasource is left inactive.

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?

Guidance is provided on when to use (change delta process), the read-modify-write behavior, validation, and the need to activate separately. Lacks explicit conditions for not using this tool but offers clear 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?

With no annotations, the description fully covers behavioral traits: no activation, no version change, active object stays active, verified for specific types, and a warning about TRFN re-activation. It honestly notes that other types are not trace-verified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is slightly long but every sentence provides necessary detail. There is no fluff or repetition, and it is structured logically: action, behavior, warnings, special cases.

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

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

Given 5 parameters with 3 required and no output schema, the description adequately covers behavior, side effects, verified object types, and parameter nuances. It is complete for an agent to use the tool 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 coverage is 100%, so baseline is 3. The description adds value by explaining the compound key for RSDS and that the change is verified by re-reading the DataSource. It also gives example values and clarifies mandatory conditions.

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 clearly states the verb 'assign' and the resource 'BW object to a different package', specifying it is a pure TADIR/transport assignment with no activation or version change. This distinguishes it from siblings like bw_move_object.

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 clear context: it's a single write, no activation needed, and explicitly warns not to re-activate TRFN afterwards. It also specifies that for RSDS, source_system is mandatory. However, it does not explicitly contrast with other tools like bw_move_object.

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

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

With no annotations provided, the description must disclose all behavioral traits. It does so by stating the created aDSO is inactive, the default action and template_type, and the requirement for source_system when template_type is RSDS. No contradictory or missing critical 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?

The description is moderately long but each sentence contributes essential information. It is well-structured: starts with the core action, then details each action's behavior, and ends with post-creation steps. No redundant phrases.

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

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

Given the tool's complexity (10 parameters, 2 actions, no output schema), the description covers parameter dependencies, default behaviors, and subsequent required steps (update/activate). It references related tools, providing sufficient context for correct invocation.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage, so baseline is 3. The description adds value by explaining dependencies (e.g., source_system required for RSDS) and defaults (action='from_template', template_type='ADSO'), going beyond mere schema descriptions.

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 clearly states 'Create a new aDSO shell' and elaborates on two specific actions (from_template, empty). It differentiates effectively from sibling tools like bw_create_datasource or bw_create_infoarea by focusing exclusively on aDSO creation.

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 when to use 'from_template' (with or without template_name) and 'empty', and provides workflow context (inactive shell, then update/activate). It does not explicitly list scenarios where the tool should not be used, but the guidance is adequate.

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 behavioral burden. It discloses the multi-step lock/POST/unlock/lock/PUT/unlock sequence, inactive-creation behavior, default exposure of all provider fields, selection constraints (at least one characteristic and one key figure, all key fields required), and the failure condition for non-planning-enabled providers. This is rare specificity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is structured and information-dense with zero filler. Complex procedural and constraint information is organized into ordered statements that progress from creation sequence, to activation, to field-selection rules, to failure conditions. Front-loading the core purpose and immediate procedural requirement is effective.

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

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

Given the tool's complexity, no output schema, and lack of annotations, this description is remarkably complete. It covers prerequisites, procedure, activation follow-up, optional parameters, field-list expectations, and common errors. The agent has everything needed to invoke the tool correctly and interpret the workflow around 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 coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema, especially around the 'fields' parameter: its effect (restrict vs expose all), accepted formats for CompositeProvider fields, and the required content of a valid selection. It also reinforces the planning-enabled prerequisite for info_provider, which is only implied in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a specific action ('Create a new Aggregation Level') on a clearly identified resource type (TLOGO ALVL) with a defined underlying object (planning-enabled InfoProvider). It clearly scopes this tool relative to related operations like activation and update, so an agent can distinguish it 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?

The description clearly identifies the intended creation scenario and prerequisites (planning-enabled aDSO or CompositeProvider), and it tells the agent to use bw_activate for activation. It does not explicitly name bw_update_aggregation_level as the alternative for existing levels, so it stops short of full when-to-use versus when-not-to-use 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?

With no annotations the description carries the full burden, and it delivers non-obvious behavior: transport recording is conditional on package + transport_request, and the result reports where the entry landed in "recorded_in". It omits activation requirements, error/failure handling, and permission needs, so it is strong but not complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences, front-loaded with the create action, then the formula contract, then transport behavior. Efficient with no filler, though the middle sentence is slightly dense.

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

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

There is no output schema, but the description covers the key return signal ("recorded_in") and the formula input contract, which is enough to call the tool correctly. Minor gaps remain around activation and error behavior for a creation tool with 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 coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema by documenting the formula tree's round-trip interchangeability with bw_get_ckf's formula_tree field. It still leaves the transport/package interaction largely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a specific verb and resource ("Create a reusable Calculated Key Figure (CKF) on an InfoProvider") and situates it among related tools, naming bw_get_ckf and bw_update_query_key_figures. An agent can distinguish this from bw_create_rkf and bw_update_ckf 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?

The description explains the formula syntax interoperates with bw_update_query_key_figures' "add_formula" and that a tree from bw_get_ckf can be reused, which implies the workflow. However it never states explicit when/when-not conditions or how to choose this over bw_create_rkf for a different key-figure type.

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 available, the description fully carries the behavioral transparency burden. It disclose materials hidden side effects: a JOIN node without inputs crashes the server/creates a server dump, copied objects inherit mappings, and the created object is inactive and must be activated separately. These are not inferable from the name or schema and are highly decision-relevant.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is dense and well-front-loaded, starting with the action, then covering the no-copy path, the special JOIN/Union behavior, the copy path, and the final activation step. Every sentence earns its keep and no line is filler or repeated schema 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?

Given that there is no output schema and no annotations, the description explains everything needed to call this tool correctly and safely: the Join-with-inputs strict prohibition, copy_from templating behavior, required post-creation mapping step, and required activation step. The only remaining details come from the fully-documented 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?

Since schema_description_coverage is 100%, the baseline is 3. The description adds real semantic value on top by explaining that inputs are required in practice for JOIN, that copy_from overrides view_type/inputs/stackable, and that a fresh creation produces an entity-only node requiring a mapping update. It does not add depth on every parameter, but it covers the materially tricky ones.

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 first sentence states the exact action and resource: 'Create a CompositeProvider (HCPR).' It then distinguishes fresh creation from copy-based creation and pairs the tool with the follow-up tools bw_update_composite_provider and bw_activate, clarifying the object lifecycle versus 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?

The description is explicit about when to use the copy_from path versus the fresh path, and about Union being allowed empty while JOIN must include inputs. It also directs the agent to the exact follow-up tools for mappings and activation, making the overall workflow unambiguous.

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 delivers several non-obvious behaviors: the object is saved directly to the active version with no activation step, the backend adjusts some option combinations on save so the response reflects the stored object, and description length is capped at 40/60 characters. It stops short of disclosing authorization or transport-obligation requirements beyond what the schema states.

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?

For a 19-parameter tool the single dense paragraph is proportionate and front-loads the purpose and no-activation fact. It would read better split into kind-specific bullets, and a few clauses (e.g. the delete line) could be trimmed, but there is little waste.

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

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

Given 19 parameters, nested source/target/time objects, no output schema and no annotations, the description covers both modes, the major optional behaviors, save-time normalization, and even the return-shape note ('the answer shows the object as stored'). The main omission is permissions/auth context for 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 coverage is 100%, so the schema documents all 19 parameters and the baseline is 3. The description adds a genuine cross-field constraint (exactly one of rate_type or rate_type_variable) and restates key defaults, but otherwise mirrors the schema rather than extending it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a precise verb and resource (create a currency translation type / unit conversion type), disambiguates the two modes with their TLOGOs, and is clearly separable from siblings bw_get_conversion_type and bw_delete. An agent knows exactly what object is produced.

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 the kind-selection context (currency vs unit) and routes deletion to the sibling bw_delete with object_type "ctrt"/"uomt". It does not spell out when a conversion type is preferable to alternative modeling constructs, but the create/delete pairing is explicit.

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 discloses several behavioral traits: the datasource is created inactive, the structure is derived from the remote entity, binding is via adapter externalObject (not name equality), and it only works with Development-Class $TMP (local objects). It also notes that field/key/partitioning editing is not supported. This provides a comprehensive behavioral picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured with essential information front-loaded. It is slightly longer than minimal but every sentence adds value. No redundant statements. A minor improvement could be to condense some details, but overall it is effective.

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

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

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is very complete. It explains creation behavior, constraints, prerequisites, and post-creation steps. Combined with the input schema, an agent has sufficient information to use the tool 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 coverage is 100% (all 5 parameters described), so baseline is 3. The description adds meaningful context: it explains that hana_entity is bound as adapter externalObject, defaults to datasource_name, and is case-sensitive. It clarifies that description defaults to hana_entity value. It also specifies that source_system must be a HANA/SDA/SDI source system. These details go beyond the schema definitions.

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 explicitly states the tool creates a DataSource (RSDS) from a remote entity's field proposal, leaving it inactive. It distinguishes from sibling tools like bw_activate by specifying that activation is separate. The verb 'Create' and resource 'DataSource' are clear, and the description highlights unique constraints like 'no field, key, or partitioning editing' and 'local objects only'.

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 clear when-to-use guidance: to create a DataSource on top of a remote entity. It specifies prerequisites: use bw_list_remote_entities to find a valid hana_entity. It also gives explicit next steps: after creation, activate with bw_activate. This helps the agent understand the sequence and alternatives.

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

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

With no annotations, the description carries full burden. It discloses that the variant is created and activated (mandatory), explains the branch structure (THEN/ELSE with default labels and event numbers), and describes transport behavior. It does not mention potential side effects (e.g., overwriting) or error conditions, but the key behaviors are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is relatively long but well-structured with a clear first sentence stating purpose, followed by details on branches, activation, and transport. Every sentence adds value, though a slight trim could improve conciseness without losing essential 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?

Given 9 parameters (3 required) and no output schema, the description is fairly complete but lacks information about the return value or possible errors. It also does not mention prerequisites or authentication requirements. This leaves gaps for an agent to fully understand the tool's behavior.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant context beyond the schema. It explains the purpose of each parameter: name is referenced by chains, formula is the branch condition, and defaults for optional parameters. It integrates parameter meaning with the tool's workflow (e.g., event numbers map to sub_status edges).

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 clearly states the tool creates a DECISION process variant as a standalone TLOGO object for use in a Process Chain. It specifies the action (create), the resource (decision variant), and the purpose (branch/decision step). It distinguishes from siblings by explaining how to use the variant afterward with specific chain creation tools.

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 clear context on when to use this tool (to create a decision variant) and offers guidance on package/transport choices, including default $TMP vs. transportable packages. It references related tools (bw_create_process_chain, bw_update_process_chain) for subsequent steps. However, it does not explicitly state when NOT to use it, leaving some ambiguity.

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

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

With no annotations provided, the description carries the full burden, and it does so well: it discloses automatic activation, server-generated naming, the persistent HTTP 500 when trfn_name_2 is omitted in two-step chains, and the internal RSDS compound-key construction. It could still be more transparent about failure modes, idempotency, or whether the operation is reversible, hence 4 rather than 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?

The description is dense and front-loaded, opening with the core purpose and then proceeding to the most consequential scenario (multi-step chains) before the filter and DataSource notes. It is slightly longer than necessary and contains minor redundancy between 'activate it' and 'activated automatically', but every major point 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?

Given 14 parameters, no annotations, and no output schema, the description covers the biggest hazards and option semantics very well: chain topology, 500 error, DataSource compound keys, and filter replacement behavior. It does not describe return values or post-creation verification, which would be helpful but not required for correct invocation.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of the parameters with solid descriptions, so the baseline is 3, but the description adds significant higher-level meaning: how trfn_name and trfn_name_2 are selected based on chain depth, how source_name/target_name relate to chain endpoints, the consequence of omitting trfn_name_2, and the special handling of DataSource keys. This is substantial added value 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?

The description opens with a specific and unambiguous action: 'Create a new DTP for an existing Transformation and activate it.' It clearly identifies the resource (DTP), the precedent requirement (existing Transformation), and the side effect (activation), which distinguishes it from run/update/get DTP siblings without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides strong situational guidance: it tells the agent to check the transformation chain first, names the lookup tools (bw_get_transformation, bw_xref), and explicitly describes how a two-step chain changes parameter usage. It does not explicitly state when not to use the tool or name sibling alternatives like bw_update_dtp, 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?

With no annotations, the description carries the full burden and does disclose mutation behavior: it creates AND activates, and the schema's activate description notes that false keeps a revised version. It also surfaces the prerequisite and the time/version-dependency restriction. It stops short of stating permissions or what the call returns, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Purpose and activation are front-loaded, and the node-structure and constraint sentences each add needed detail. It is slightly dense with a long final restriction clause, but there is little waste.

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

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

For a mutation tool with no annotations and no output schema, the description covers creation, the nested node contract, the activation toggle, the prerequisite, and the dependency restriction. Return values are not covered, but the input contract – the part an agent must get right – is well specified.

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 a 3 is the baseline, but the description adds genuine semantic value by explaining the nested node shape that the schema only gestures at: a text_node groups nodes while a value node is a value of the characteristic, and 'each node appears once'. That clarifies the otherwise opaque 'items: object' array.

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 hierarchy for a characteristic') and distinguishes it from the sibling CRUD set (bw_get_hierarchy, bw_update_hierarchy, bw_delete_hierarchy) by the creation action. It also names the activation side-effect, so the agent knows it is a create-and-maybe-activate operation.

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 prerequisite ('The characteristic must have hierarchies switched on') and an explicit exclusion ('Not time-dependent and not version-dependent hierarchies only'), which tells the agent when creation is valid. It does not explicitly name an alternative tool, but the create-vs-update vs get sibling split is self-evident.

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 provides one behavioral trait (immediately active, no activation step). However, it does not disclose other aspects like authentication requirements, side effects (e.g., overwriting existing InfoAreas), or what happens on duplicate names. Adequate but minimal.

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 redundancy. The first sentence states the core purpose, the second adds an important behavioral fact. 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?

Given the low complexity (4 parameters, no nested objects, no output schema) and full schema descriptions, the description is mostly complete. It explains the key activation behavior. It could be enhanced by specifying what the tool returns, but for a creation tool the current level is 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%, so the schema already defines parameter meanings. The description adds no additional parameter-level context beyond the schema. 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?

The description clearly states the action ('Create') and the resource ('InfoArea'), and adds a specific behavioral detail (immediately active, no activation needed), which distinguishes it from other create tools like bw_create_adso or bw_create_dtp.

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 tool vs alternatives. There is no mention of prerequisites, when-not-to-use, or comparison with sibling tools. 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 provided, so the description carries the full burden. It discloses the critical behavior that the object is created inactive and must be activated via bw_activate. It also mentions the lock/unlock sequence, which are important side-effects. This is above average disclosure for a tool with no annotations.

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 fluff. The first states the purpose, the second gives the essential workflow. All information is relevant and front-loaded.

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

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

For a tool with 18 parameters and no output schema, the description covers the critical lifecycle (creation is inactive, activation needed) and the locking sequence. The schema covers parameters exhaustively. It doesn't mention error cases or prerequisites, but those are minor given the rich schema and workflow disclosure.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage, with each parameter described including defaults, type-specific constraints (e.g., 'CHA only'), and examples. The tool description adds no parameter-specific information, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description explicitly states 'Create a new InfoObject' and specifies the two types (CHA or KYF), which is a clear verb+resource. It also distinguishes this from update tools by noting it creates an inactive object, making the purpose 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?

It gives explicit operational guidance: the sequence 'lock → POST create → unlock' and instructs to call bw_activate after creation. This tells the agent exactly when and how to use the tool. It doesn't explicitly mention alternatives (e.g., bw_update_infoobject), but the create vs update distinction is clear from 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?

Discloses that the creation results in an inactive shell and that copying is optional. No annotations present, so description carries full burden; however, it does not cover permissions, error conditions, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences, front-loaded with the main action, no redundant information. Every sentence adds value.

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?

Covers creation, optional copy, and subsequent steps (activate, update). No output schema, but the description explains the lifecycle well. Missing details about validation or defaults, but sufficient for a creation 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 has 100% coverage with descriptions for each parameter. The description adds context about the copy_from_* parameters and the inactive state, but does not significantly enhance individual parameter understanding 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?

The description clearly states it creates a new InfoSource shell with optional copying from specified object types. It distinguishes from sibling tools like bw_update_infosource and bw_activate by mentioning post-creation steps.

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 explicit guidance: created inactive, requires bw_activate for activation, and bw_update_infosource for adding fields. Lacks explicit when-not-to-use or alternatives for other object types, but context is clear.

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

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

With no annotations the description carries full load, and it discloses real behavior: restrictions are applied in the same call, a variable is embedded as the modeling tools do, and the result is 'Saved active.' It still omits auth/authorization needs and failure/conflict behavior, so it is not fully complete 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?

Three tight sentences, front-loaded with the verb and resource before elaborating on restrictions and variables. Dense but each clause earns its place; 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?

No output schema exists, but the description handles that by pointing to bw_get_planning_filter for read-back. For a mutation tool with 6 params and no annotations it is reasonably complete, though permission/transport behavior (transport is in schema) could be surfaced.

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 3 baseline is met, but the description adds genuine meaning about the operations model — fixed values, ranges (via high), exclusions, and characteristic variables — which goes beyond the raw schema field list.

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) plus resource (planning filter on an aggregation level) and clarifies what a planning filter is — the selection a planning sequence step or input template works on. This distinguishes it cleanly from siblings like bw_update_planning_filter and bw_get_planning_filter.

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 bw_get_planning_filter for reading back, giving clear context for creation vs retrieval. However it doesn't state when to use this versus bw_update_planning_filter, nor any prerequisites beyond the implicit create vs modify distinction.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the server fills the parameter skeleton, defaults each characteristic to usage NONE, applies supplied usage/conditions/values after create, and that the object is saved active with no activation step. It doesn't cover permissions or transport-obligation behavior beyond the schema, leaving a minor 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?

Three front-loaded sentences: what is created, how defaults/application behave, and where to look up parameters. Dense but every sentence carries actionable information 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 an 11-parameter mutation tool with no annotations and no output schema, the description covers creation semantics, default behavior, and parameter lookup adequately. It leaves the return value (e.g. confirmation or created object identity) undiscussed, which is the only notable 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 the baseline is 3, but the description adds semantics the schema does not: defaults for rule (1-based), the sequencing of characteristic usage/conditions/parameter application, and pointer to the parameter tree of bw_get_planning_function as the source of valid parameter names.

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 and scope ('Create a Planning Function (TLOGO PLSE) of a given function type on an aggregation level'), and names the read-side sibling bw_get_planning_function so the agent can distinguish it from get/update variants 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?

Gives clear context ('saved active — there is no activation step') and routes to bw_get_planning_function to discover which parameters a type has before creating. It stops short of explicit when-not-to-use or a direct contrast with bw_update_planning_function, so it's clear context rather than full exclusion 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?

With no annotations, the description carries the full behavioral burden. It does disclose two genuinely useful traits: the object is 'Saved active' immediately, and InfoArea/package default from the first step's aggregation level and "$TMP" respectively. It stops short of permissions required, error conditions (e.g. a nonexistent filter reference), or how activation failure is surfaced, which for an unannotated mutation tool leaves real gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences, front-loaded with the core action and artifact, then the composition detail, then the defaults. No filler, no restatement of the tool name, and the ordering follows what an agent needs to know first.

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

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

For a 6-parameter create tool with 100% schema coverage and no output schema, the description covers composition, execution order, and defaulting well. It omits what the call returns (e.g. the created sequence name/status) and any failure modes, which is acceptable without an output schema but leaves the preconditions for the referenced filter/function 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 baseline is 3, and the description genuinely adds meaning by explaining the execution-order semantics of the steps array and the defaulting rules for info_area and package. It reinforces rather than merely repeats the schema, though most of the default behavior is already documented per-parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description names a specific verb and resource ('Create a planning sequence') and immediately characterizes what the artifact contains ('its steps in execution order: planning functions, each with the filter that selects its data, and input templates'). That composition detail cleanly separates it from the sibling create_planning_function and create_planning_filter tools, which build the components rather than the container.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the agent can infer this is the tool to use when assembling an ordered sequence of planning steps, and the step-type semantics ('a planning_function step runs the function... an input_template step only opens that selection') hint at intent. However, there is no explicit when-to-use/when-not guidance, no mention of prerequisites such as the referenced filter or planning function having to exist first, and no routing against siblings like bw_update_planning_sequence.

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 fully discloses the skeleton-then-update mechanism, the implicit TRIGGER node, edge status defaults, the non-emission of negative edges by default, DECISION branch semantics, and which generic reference paths are verified versus untested.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is dense but all content earns its place for such a complex, multi-typed tool. It opens with the core operation and then methodically covers step types, edges, defaults, and use-before prerequisites without filler or 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?

The description, along with the rich schema, gives an agent everything required to construct a valid call: how to compose steps and edges, which fields are needed per step type, default edge conditions, decision-variant prerequisites, and start/activation options. The absence of an output schema does not create a serious gap.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description still adds substantial meaning: implicit TRIGGER index 0, per-step field requirements, edge status defaults, sub_status semantics, the bw_create_dtp relationship, and verified/untested step-type behavior. This goes well beyond the schema definitions.

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 action — creating a Process Chain (RSPC) — and explains the exact operation: build from steps and edges, create a trigger-only skeleton, then update with the full model. It clearly distinguishes this from sibling mutation/editing tools such as bw_update_process_chain and bw_add_process_chain_edge.

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 explicitly says to use bw_create_dtp first for two-step DTP loading and to use bw_create_decision_variant before referencing DECISION variants. It also marks verified vs untested paths and unsupported process types. However, it does not explicitly name sibling alternatives for modifying an already-created chain.

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 reveals key behaviors: empty query creation without copy_from, full copy behavior with copy_from, defaulting of infoprovider, and limitation to $TMP package. It does not mention potential side effects like locking or permissions, but overall is transparent.

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 efficiently convey all necessary information without redundancy. The main action is stated upfront, and each clause adds distinct value.

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?

Covers the two main use cases (empty and copy) and the package limitation. Does not describe return values or error handling, but for a creation tool the output is implicit. Overall sufficiently complete for the complexity.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value beyond the schema by explaining the semantics of copy_from (full copy), defaulting of description, and conditional requirement for infoprovider. This aids in correct invocation.

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?

Clearly states the tool creates a new BW Query (TLOGO ELEM) on an InfoProvider in package $TMP, with specific details about the creation process including empty vs copy modes. This distinguishes it from sibling tools like bw_update_query_layout or bw_create_adso.

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 guidance on when to use copy_from vs empty creation, and notes that only $TMP package is supported. However, it does not explicitly state when not to use this tool or compare directly to alternatives like bw_update_query.

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 provided, so description carries full burden. It details validation, internal key mapping, consistent write without activation, and naming conventions. Covers key behavioral aspects for a creation 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 pack purpose, usage pattern, and detailed behavior without waste. Front-loaded with core purpose, then specific details. Highly efficient.

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?

Lacks output schema and return value description, but thoroughly explains creation process, validation, and constraints. Adequate for an agent to understand tool behavior.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining technical naming requirement, restrictions structure, and package/transport context, going beyond schema descriptions.

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?

Description clearly states it creates a Restricted Key Figure (RKF) on an InfoProvider. Distinguishes from siblings like bw_get_rkf and mentions it's for mass creation with looping.

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 says 'Built for mass creation: one RKF per call — the agent loops,' indicating when to use and pattern. No explicit when-not or alternatives, but context is clear.

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

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

With no annotations, the description must carry behavioral disclosure itself. It does describe the structure's reuse semantics and member composition, but it does not disclose operational side effects such as whether the object needs activation, how transport/package choices affect persistence, or what happens if the technical name 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 tight sentences front-load the core purpose and then clarify what members contain. No filler or repetition of schema details.

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

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

The schema is rich and the description explains the domain concept, but without an output schema or annotations the agent is left without explicit information about return values, prerequisites, or post-creation activation/transport behavior. This is adequate but not complete for a creation 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?

Input schema covers all 7 parameters, so the baseline is 3. The description adds only mild extra meaning by explaining that members can be either reusable CKF/RKF or basic key figures; the remaining parameters are already well-described in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description names a specific action and resource: create a reusable key figure structure on an InfoProvider. It immediately clarifies the object's purpose as a shared query axis, distinguishing it from sibling tools that create individual key figures or queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear usage context: use this when you want one structure definition to drive all reporting queries that embed it as an axis. The schema adds that members can be added later via bw_update_structure, which is an implicit exclusion, though the description itself does not explicitly name alternatives.

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

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

No annotations are provided, so the description carries the full burden, and it discloses genuinely non-obvious behaviors: the Transformation name is server-generated (32-char UUID-like), the object is created inactive by default, and transport requires a request. It omits permission/auth requirements and error conditions, but the key state and lifecycle traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Four tight sentences, front-loaded with the core action then the non-obvious behaviors (server-generated name, inactive state, transport). Every sentence carries information an agent needs; nothing is padded.

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 11-parameter mutation tool with no annotations and no output schema, the description covers the crucial lifecycle facts (auto-generated name, inactive creation, activation path, transport recording). It could say more about what the response returns or failure modes, but the essentials for calling it correctly are present.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 11 parameters including activate, transport, package, and the object type/subtype values. The description reinforces the semantics of activate and transport but adds little beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a specific verb (Create) and resource (Transformation) plus its scope (between two BW objects, listing types). The resource is unique among siblings (bw_create_adso, bw_create_infoarea, bw_update_transformation), so an agent can distinguish it immediately.

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 completing the operation: created objects are inactive, so either call bw_activate with object_type "trfn" afterwards or pass activate:true, and for transportable packages pass the transport request. It routes to the activation sibling, though it doesn't contrast against bw_update_transformation for modifying existing transformations.

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 full burden. It discloses that the call is a single ADT call, no lock or activation, and returns the created task number. It does not detail side effects or error conditions, but for a creation tool, it provides reasonable behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two sentences, front-loaded with the action, and contains no unnecessary words. Every sentence adds value.

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

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

Given no output schema, the description mentions the return value ('Returns the created task number'). It covers prerequisites (modifiable parent) and the call's nature. For a simple two-parameter creation tool, it is 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 coverage is 100% with descriptions for both parameters. The tool description adds minimal extra meaning beyond examples; it mostly restates the parameter purposes. 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?

The description clearly states the action ('Add a task'), the resource ('sub-request for a user to an existing workbench transport request'), and context. It distinguishes from sibling tools, none of which create transport tasks.

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 guidance on when it can be used ('parent request must be modifiable') and notes the call is single and has no lock or activation. However, it does not explicitly compare to alternatives or state when not to use it.

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

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

With no annotations, the description carries the full burden and mostly delivers: it discloses the non-obvious trait that the variable is 'created active and consistent', explains ready_for_input interactions with the user variable screen, the ReplacementPath limitation, and even the default_value decimal-notation permission caveat (USR01 via ADT DataPreview). It stops short of covering prerequisites like transport, locking, or error/rollback 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?

Front-loaded correctly with the core purpose, and nearly every sentence carries substantive detail. But it is presented as one dense, comma-laden block of run-on sentences with heavy parenthetical nesting, which hurts scanability for such a complex parameter space.

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 22-parameter creation tool with no annotations and no output schema, the description plus the exhaustive schema give an agent enough to invoke it correctly across the main variable types. Missing only lifecycle/workflow context (transport handling, activation, locks) that a create operation would benefit from.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all 22 parameters including per-type applicability. The description adds some cross-parameter logic (which type needs iobj_name, what makes a formula vs text variable), but this largely duplicates what the individual schema descriptions 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 ('Create a reusable BW Variable') and goes further by enumerating the five variable types and what each stands for, so an agent knows exactly what is being produced. It names consuming siblings (bw_update_query_key_figures, bw_create_ckf, bw_update_ckf) for formula variables, but never explicitly contrasts create against the sibling bw_update_variable/bw_get_variable, leaving that distinction implicit.

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?

Rich selection guidance for which variable_type to choose and how it feeds downstream tools, and it flags a hard constraint ('replacement from a query result is not supported'). However there is no explicit when-to-use-this-over-alternatives statement (e.g. create vs update_variable), so usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses permanence/immediacy of deletion, the lock/unlock sequence, that query deletion spares referenced variables/CKFs/RKFs, the active-path behavior for planning sequences/filters/conversion types, and the refusal case when a filter is still referenced. This is exactly the destructive-operation context 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?

Front-loaded with the core purpose, then dense supporting detail; every sentence (sequence, query exception, planning/filter rules, dependency note) contributes actionable information. It is long but not padded, staying just short of maximal efficiency.

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 destructive tool with no annotations and no output schema, the description covers the sequencing, type-specific exceptions, refusal conditions, and cross-object dependencies that an agent needs to invoke it correctly. Nothing material is left unspecified.

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 baseline is 3, but the description adds meaning beyond the schema by naming additional object_type values (plsq, filter, ctrt, uomt) and the "elem" alias for queries. It does not describe the object_name format beyond what the schema already gives.

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 (Delete) and resource (BW object) and enumerates the covered types (aDSO, InfoObject, Transformation, DTP, Query), making the scope concrete. It does not explicitly route the agent away from the more granular siblings (bw_delete_hierarchy, bw_delete_request, bw_delete_transformation_routine), so sibling differentiation is only partial.

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 operational context (lock → DELETE → unlock, no activation needed) and a dependency rule (delete aDSOs before their InfoObjects), which implies correct usage. However it never states when to choose this generic tool versus the specialized delete siblings, so alternative-selection guidance is missing.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the active version is destroyed by default, that version M only discards a pending revised version, and that dependent queries lose access. It stops short of stating permission/authorization requirements or whether the change needs activation/transport.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences, front-loaded with the action, then version semantics, then downstream impact. Each sentence is informative, though sentence two partially overlaps the schema's version 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 destructive mutation with no annotations and no output schema, the description covers the key behavioral question (what is destroyed under which version) and the consequence for dependent queries. Authorization and activation/transport requirements are the remaining omission.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the version enum is already documented in the schema, so the baseline is 3. The description's restatement of the A/M semantics adds only marginal clarification beyond what the schema's enum description already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a specific verb (Delete) and resource (a hierarchy of a characteristic), and the first sentence alone lets an agent distinguish this from the sibling create/update/get hierarchy tools. The scope 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?

Usage is implied by the verb and by the note about queries no longer finding the hierarchy, but the description never explicitly names when to use this versus bw_update_hierarchy or the generic bw_delete. No alternatives or exclusions are given.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that load requests are deleted, activation requests are rolled back with a cascade that undoes later activations, the call is asynchronous, and the return identifies rolled-back vs. deleted requests. Authorization details are absent, but the destructive and irreversible nature is clear from 'delete' and 'removing the data'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is front-loaded with purpose and sibling distinction, then moves through behavior, usage, async confirmation, and return values. Every sentence carries decision-relevant information, and the length is justified by the tool's destructive, multi-mode complexity.

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

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

Given no annotations and no output schema, the description is complete: it covers purpose, when to use it, alternatives, both request-type behaviors, asynchronous confirmation, and what the call returns. Nothing an agent needs in order to call it correctly is missing.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 even without additional parameter detail. The description adds usage context for all_requests=true with target, clarifying the common extraction-mode-change scenario, but most individual parameter meanings are already fully documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a specific verb and resource: delete load requests from an InfoProvider, including removal of data and request-management entries. It explicitly distinguishes itself from selective record deletion and clarifies how load vs. activation requests are handled, giving the agent a precise mental model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the primary use case (precondition for switching a DTP from delta to full extraction), the regular case for all_requests=true with target, and the exclusion (not selective deletion of records by condition). It also directs the agent to bw_list_requests for asynchronous confirmation.

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 full burden. It discloses side effects (removing entire group if no rules remain) and return value ('lock_handle for bw_activate'), providing useful behavioral context beyond a simple delete statement.

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 concise sentences: first for action, second for effect, third for return value. No unnecessary words, front-loaded with the core purpose.

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 delete tool with 2 parameters and no output schema, the description covers purpose, side effects, and return value. However, it lacks preconditions (e.g., whether the transformation must be locked beforehand), leaving minor gaps.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters. The description does not add new meaning beyond what the schema provides (e.g., 'routine_type' enum values). 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?

The description clearly states the verb 'Remove', the resource 'Start, End, or Expert routine from a Transformation', and specifies the types. It distinguishes from sibling tools like bw_set_transformation_routine by focusing on deletion.

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 explicit guidance on when to use this tool vs alternatives, prerequisites, or order of operations. The description only states what it does, leaving the agent to infer usage 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 provided, so description must fully disclose behavior. Only states 'Read' (safe), but omits error handling (e.g., missing aDSO), return format details beyond the three listed items, and any authentication or permissions requirements.

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?

Single sentence front-loaded with action verb, using dash-separated list for clarity. No redundant or irrelevant content. Efficient for the tool's simplicity.

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 tool with two parameters and no output schema, the description covers the core output (fields, settings, version). Lacks details on edge cases (e.g., non-existent aDSO) and permissions, but suffices for typical use.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and parameter descriptions are clear. The tool description adds no additional semantic value beyond the schema, including no mention of parameters. 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?

Description clearly states the tool reads an aDSO structure, listing specific components (fields, settings, version). Distinguishes well from sibling creation/update tools (e.g., bw_create_adso, bw_update_adso) and other get tools targeting different objects.

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 explicit when-to-use or when-not-to-use guidance. The verb 'Read' and context of sibling tools imply read-only use, but the description does not explicitly direct the agent away from alternatives or mention prerequisites.

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

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

With no annotations, the description carries the full behavioral burden, and it only implies read-only via the verb 'Read'. It says nothing about authorization/permission requirements, what happens if the name does not exist, or whether the result is cached or object-level scoped. The detailed element enumeration describes payload content, not 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?

One long but well-structured sentence that front-loads the purpose before enumerating outputs. The verbose field list is defensible because there is no output schema, though the nested characteristic/key-figure detail could be tightened.

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?

Since no output schema exists, the description usefully compensates by enumerating returned fields (name, status, InfoArea, package, InfoProvider, characteristics vs key figures, AMO/QUA/NUM semantics, unit/currency reference). What is missing is sibling routing and any read-time caveats, but for a single-object getter the payload coverage is strong.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with only 2 parameters, so the schema already documents both aggregation_level_name (with an example) and the format enum. The description adds no parameter-level detail — it never mentions the 'raw' vs 'text' format choice — so it stays at 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+resource ('Read an Aggregation Level (TLOGO ALVL) definition') and defines the domain concept precisely as the planning-enabled view on top of an InfoProvider, which meaningfully separates it from bw_get_adso and bw_get_composite_provider. It never names those siblings explicitly, so an agent must infer the distinction rather than being routed to the right 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?

No when-to-use guidance at all: it never says to call this when you need to inspect an ALVL rather than its underlying aDSO/CompositeProvider, nor what prerequisite (an existing ALVL name) is needed. The nearby siblings bw_create_aggregation_level and bw_update_aggregation_level are the obvious routing alternatives and are not mentioned.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discharges much of it: it enumerates the exact return payload (technical name, description, rendered formula, structured formula_tree, exception aggregation, metadata, full dependency graph) and notes the round-trip contract that write tools accept the formula_tree unchanged. It stops short of stating read-only safety, error behavior, or what happens for non-existent or non-global CKFs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded with the action and resource, then a single enumeration of return fields; no filler sentences. The enumeration is dense and long, but each listed item (formula_tree round-trip, exception aggregation shape) carries information an agent needs given there is no output 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?

With no output schema and no annotations, the description is the only source of return-value and contract information, and it covers that fully, including the round-trip compatibility with the CKF write tools. Nothing essential for correct invocation is missing.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter, so the schema already documents component_name fully. The description adds no format, naming, or lookup guidance beyond what the schema provides, 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 ('Read') and resource ('global Calculated Key Figure defined at CompositeProvider level'), and the qualifier 'global... at CompositeProvider level' distinguishes it from the sibling bw_get_rkf (reusable key figure) and bw_get_structure. An agent can tell what it retrieves without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the read semantics and by the mention that the formula_tree is consumed by bw_create_ckf and bw_update_ckf, which hints at a read-before-write workflow. It never states when to prefer this over bw_get_rkf, bw_get_composite_provider, or bw_get_aggregation_level, nor any prerequisites.

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

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

With no annotations, the description carries the full burden, and it does disclose a non-obvious behavioral trait: it returns the inactive version. It also enumerates the returned structure in detail (view node type, source providers with mapping counts, field groups, join condition, temporal join). It omits authorization/lock-state or error behavior, which keeps it from 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?

It is a single long, comma-heavy sentence, but the purpose is front-loaded and every clause maps to return content that is otherwise undocumented (no output schema). Slightly denser than ideal, but nothing is wasted.

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

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

Because there is no output schema, the description must describe the return value, and it does so thoroughly for a complex structure. The main gap is that it says nothing about failure modes or the practical consequence of reading only the inactive version.

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% for the single parameter, and the schema already explains the technical name with an example. The description adds no parameter-level 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 ('Read') plus resource ('a CompositeProvider (HCPR) structure') and enumerates exactly what is returned, which cleanly separates it from the sibling create_/update_composite_provider tools. An agent can tell what it gets without opening any other definition.

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 read-only intent and the note that it returns the inactive version imply usage, but there is no explicit 'use this when…' statement and no reference to when to prefer it over siblings such as bw_get_adso or bw_get_infosource. Guidance is inferable rather than stated.

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

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

With no annotations, the description carries the full burden, and it does disclose the fallback behavior when 'kind' is omitted plus the shape of the returned record. However it says nothing about permissions needed, behavior on a non-existent name, or error/empty-result handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded with the verb and resource, but it is a single dense sentence with nested parentheticals and semicolons that is hard to parse. The long enumeration of returned fields arguably belongs in documentation rather than the 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?

With no output schema, the description compensates well by enumerating what the returned record contains (source/target, rate type, exchange rate, time reference, factor determination) and what 'format' controls. Only failure and empty-result behavior is unaddressed.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents kind, name, and format, including the 'omit to try both' behavior that the description merely restates. The description adds little semantic detail beyond what the structured fields provide.

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 ('Read') and resource ('currency translation type / unit conversion type'), and even names the underlying TLOGO types (CTRT/UOMT). The read verb inherently separates it from the sibling bw_create_conversion_type at a glance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: it is the read counterpart to bw_create_conversion_type. The one conditional ('Without kind both types are tried') describes parameter behavior rather than when to prefer this tool, and no prerequisites, permissions, or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It discloses output format thresholds (tree vs flat table) and direction conventions. It does not mention nondestructive nature or permissions, but the behavioral details are adequate for correct usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is concise at about 5 sentences, with the main action front-loaded. The important instruction about printing the result adds length but is valuable. Some redundancy in listing object types could be trimmed, but overall it's well-structured.

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

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

Given the 6 parameters (2 required), no output schema, and no annotations, the description covers essential behavioral aspects: output format, direction, and object types. It could mention read-only nature, but it provides enough for an agent to invoke 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 coverage is 100%, so baseline is 3. The description adds some value by explaining the direction convention more thoroughly and noting defaults. However, most parameters are well-described in the schema, and the description doesn't significantly augment them.

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 clearly states the tool traces the data flow graph for a BW object, specifies the output format (tree or flat table) based on node count, lists included object types, and explains direction convention. It distinguishes from sibling tools which are for creation, activation, deletion, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the use case: 'Use this to understand the full lineage of an object without navigating each connection manually.' It also provides an important instruction to always print the complete result. However, it does not mention when not to use it or compare to alternatives like bw_xref.

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 implies a read-only operation without side effects. However, it does not disclose error handling, return behavior for invalid inputs, or performance implications. The description is adequate for a standard 'get' operation but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, well-structured sentence that front-loads the key purpose. Every part is meaningful, no redundancy, and it efficiently conveys the tool's function.

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

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

For a read tool with 3 parameters and no output schema, the description adequately outlines what is returned (metadata, fields, adapter config). It could mention output format details, but the schema covers the format parameter. Overall complete given the tool's simplicity.

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 explains all parameters. The description adds no additional semantics beyond what the schema provides. 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?

The description clearly states the action (Read) and the resource (DataSource/RSDS), specifying it returns the full structure including metadata, fields, and adapter configuration. This distinguishes it from sibling tools like bw_list_datasources (listing) and bw_get_infosource (different object).

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 lacks any guidance on when to use this tool versus alternatives such as bw_get_infosource or bw_get_adso. No prerequisites, exclusions, or context are provided, leaving the agent to infer usage solely from the tool name and 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 burden. It does disclose the returnable content (source, target, transformation settings, filter routines) and a performance trade-off versus the alternative, which is useful. However it does not state permission/auth requirements, whether the operation is strictly read-only, or any response-format caveats beyond what the schema's format enum implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences, front-loaded with the core purpose, then the prerequisite lookup, then the cheaper alternative. Every sentence earns its place with no redundancy or filler.

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

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

For a two-parameter read tool with no output schema, the description is nearly complete: it enumerates the returned definition contents and routes the agent to prerequisites and alternatives. The only gaps are auth/permission behavior and explicit confirmation that the call is non-mutating, which annotations would normally cover.

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 format enum (text/raw) and a description for dtp_name, so the schema already documents both parameters. The description mentions filter fields and settings but adds no syntax or format guidance 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 (Read) and resource (DTP definition) and enumerates exactly what is retrieved: source, target, transformation, extraction settings, and filter fields. It also explicitly contrasts itself with bw_xref, so an agent can distinguish it from the sibling without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: use bw_xref on an aDSO to obtain the DTP name first, and use bw_xref with object_type=DTPA when only the owning process chain is needed. Both the when-to-use and the when-to-use-alternative are spelled out, including the performance reason ('faster and avoids loading the full DTP definition').

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 bears full burden. It discloses that the tool uses the 'xref endpoint filtered to DTPA object type,' which is a behavioral detail. However, it does not mention permissions, side effects, or error handling. As a read-only operation, the lack of destructive hints is acceptable but could be clearer.

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 primary purpose, followed by a technical detail. No wasted words. Efficient and clear.

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 does not specify what the tool returns (e.g., list of DTP names/IDs). For a list tool, omitting the return format is a gap. However, the description is adequate for basic use. Not 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 coverage is 100% with clear descriptions for both parameters. The description adds a usage hint for object_type=TRFN but does not enhance the semantic meaning beyond what the schema already provides. 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?

The description clearly states the verb 'List' and the resource 'DTPs (Data Transfer Processes)' and specifies the context 'that depend on a BW object.' It distinguishes from siblings like bw_get_dtp (single DTP) by focusing on dependents.

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 usage example: 'Use object_type=TRFN and the transformation name to find DTPs after activating a transformation.' This gives clear guidance for a common use case. However, it does not explicitly state when not to use or list alternatives.

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

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

With no annotations, the description carries full burden. It explains the return value (CHAVL_INT), notes differences between CHAVL_EXT and CHAVL_INT for date types, and describes wildcard behavior. It does not mention if it's read-only, but 'look up' implies a safe operation. Overall, good transparency.

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?

All four sentences are concise and informative. The purpose is front-loaded, and each sentence adds new, essential information without redundancy. No unnecessary 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?

Given 4 parameters with complete schema descriptions, the description adds context on usage and return values. It could mention default for max_rows (201) but that is in schema. No output schema, but return value semantics are covered. Adequate for the tool's complexity.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds significant value: explains search_string wildcard usage with examples, recommends info_provider scoping, and clarifies that returned value is CHAVL_INT (internal key). This goes well beyond the schema's descriptions.

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 clearly states the tool's purpose: 'Look up valid characteristic values for use in query filters or variable inputs.' It specifies the resource (characteristic values) and action (look up), and mentions internal key usage. However, it does not explicitly differentiate from sibling tools like bw_search, but the purpose is distinct enough.

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 explicit guidance on when to use the tool ('for use in query filters or variable inputs') and how to use it (wildcard search, scoping with info_provider). It lacks explicit when-not-to-use or alternative tools, but the context is clear.

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

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

With no annotations, the description carries the full burden, and it does disclose the payload of both output modes — including that nodes are typed (text node vs. characteristic value) and indented by level, which is not derivable from the input schema. It omits any note on permissions, size limits, or pagination for large trees, so it is not fully complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded with the core action, then the two-mode split, then the routing guidance — a sensible order. The second sentence is long and packed with a comma-list of node attributes, which costs some readability but every clause carries 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?

There is no output schema and no annotations, yet the description describes the shape of both return modes, which is the most important gap to close for this tool. It stops short of covering the raw/version parameters in prose, but those are adequately 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 coverage is 100%, so the baseline is 3; however the description adds meaning the schema only hints at by spelling out the semantic switch on hierarchy_name (absent = list hierarchies, present = full tree) and framing each mode's output. The format and version parameters are left entirely to the schema, but that is acceptable at full coverage.

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 ("Read the hierarchies of a characteristic") and then splits the two distinct behaviors by parameter presence: list mode (versions, validity, levels, node count) vs. tree mode (each node with type, name, text, id, indentation). An agent can distinguish this from bw_query_data and bw_update_hierarchy without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names both downstream alternatives and the condition selecting each: use this to find the node to filter on in bw_query_data, and to read a tree before modifying it with bw_update_hierarchy. That is a genuine when-to-use statement tied to named siblings.

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

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

No annotations are provided, so the description must convey behavioral traits. It states 'Read', indicating a non-destructive operation. The description is clear about what it retrieves but does not disclose potential side effects, authorization requirements, or performance characteristics. However, for a simple read tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single sentence that efficiently communicates the tool's action and output. It is front-loaded with the verb and resource, and every word adds value. No unnecessary 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?

The tool has one required parameter and no output schema. The description compensates by listing the four fields returned (name, label, parent area, object status), which gives a clear idea of the response structure. This is sufficient for a simple read operation, though it does not specify data types or formats.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides a clear description of the single parameter (name with an example). Schema coverage is 100%. The description does not add further parameter semantics beyond stating the tool's output. Thus, it meets the baseline but does not enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses the verb 'Read' and explicitly mentions the resource 'InfoArea definition', listing the specific fields returned (name, label, parent area, object status). This clearly identifies the tool's purpose and distinguishes it from sibling tools that operate on different SAP BW objects.

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 does not provide explicit guidance on when to use this tool versus alternatives. The purpose is implied (retrieve InfoArea details), but there is no mention of prerequisites, limitations, or when not to use it. Given the presence of many other 'get' tools for different objects, some differentiation would help.

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 clearly indicates a read operation with no side effects, lists return fields (data type, length, etc.), and is consistent with the tool name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single sentence of 16 words, front-loaded with the action and resource. Every word adds value, making it highly efficient.

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 tool with one parameter and no output schema, the description covers the core functionality and return content. It could optionally mention authorization or error conditions, but the current level is adequate.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description. The tool description adds the constraint that the object must exist, which provides useful context beyond the schema, but does not add further detail about the parameter format or values.

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 clearly states the action ('Read'), the resource ('InfoObject definition'), and a constraint ('must already exist in the system'). It also specifies the return content, distinguishing it from creation tools like bw_create_infoobject.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for reading existing objects but does not provide explicit guidance on when to use this tool versus alternatives (e.g., bw_update_infoobject) or 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?

The description states 'Read,' implying a non-destructive, idempotent operation. No annotations are provided, so the description carries the burden of behavioral disclosure. It does not mention side effects, authentication requirements, or rate limits, but for a simple read operation, the transparency is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, well-structured sentence that immediately states the action and lists the key components. There is no extraneous information, and it is front-loaded with the purpose.

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 tool with one parameter and no output schema, the description covers the essential elements: the resource type and what the structure contains. It could be improved by noting the return format or whether the entire structure is returned, but it is largely 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?

The input schema has 100% coverage, with the single parameter 'name' already described as 'InfoSource name'. The description adds no additional semantics beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

Description clearly specifies the verb 'Read' and resource 'InfoSource (TRCS) structure', listing specific components like fields, key fields, label, InfoArea, version status. This distinguishes it from sibling tools such as bw_get_adso or bw_get_infoobject, which read different BW objects.

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 guidance on when to use this tool versus alternatives like bw_get_adso or bw_get_infoobject. Given the large number of sibling tools, providing context on when to choose this tool would be beneficial for agent decision-making.

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?

The description clearly indicates that this is a read operation ('Read') and details the extensive output content. It discloses that only the definition is retrieved and includes specific behavior for FILE destination types. However, without any annotations, it does not explicitly state that no modifications are made or mention required permissions. It effectively conveys the scope and nature of the 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?

The description is a single, well-structured sentence that begins with the core purpose ('Read an Open Hub Destination...'). It efficiently lists the key aspects of the definition without unnecessary words. While it is somewhat dense, it remains clear and front-loads the essential 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?

Given the absence of an output schema, the description thoroughly enumerates the return values, including destination type, source, DB table, InfoArea, package, status, output field list (with type/length, InfoObject binding, conversion routine, compounding, key flag), and file properties conditionally for FILE type. This provides complete contextual information for an agent to understand the output without needing additional documentation.

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 one parameter 'open_hub_name' described in the schema as 'Technical name of the Open Hub Destination (e.g. "OBJECT_NAME").' The tool description does not add further semantics about the parameter beyond what the schema already provides. The baseline of 3 is appropriate since the schema covers the parameter adequately.

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 begins with 'Read an Open Hub Destination (TLOGO DEST) definition', clearly stating the action (read) and the specific resource (Open Hub Destination). It lists detailed components such as destination type, source, DB table, InfoArea, package, status, output field list, InfoObject binding, conversion routine, compounding, key flag, and file properties for FILE type. This specificity distinguishes it from sibling get_* tools that target other BW objects (e.g., bw_get_adso, bw_get_infoobject).

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 does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusion criteria or context for selection. It implicitly suggests use when reading an Open Hub Destination definition, but lacks explicit guidance such as 'Use this when you need the full OHD definition with field details'. No mention of when not to use or alternative tools is made.

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. 'Read' implies a non-mutating operation and the description usefully discloses the shape of the response (aggregation level, InfoArea, package, restrictions, variables with type/processing/input settings). But it says nothing about permissions needed, behavior on a missing filter, or whether output is paginated.

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 no filler; the core definition is front-loaded and the return-contents list and cross-reference follow. It is dense but every clause carries information, with only slight compression that makes the enumeration read as a run-on.

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 correctly compensates by enumerating the salient return fields, and it anchors the resource to its parent sequence step. It is nearly sufficient for calling the tool, missing only error/permission context and any note on the format parameter's practical effect.

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 both the 'format' enum and 'filter_name' documented in the schema itself, so the schema does the heavy lifting and a baseline of 3 applies. The description adds only indirect meaning by noting that a sequence step 'names its filter,' and does not touch the text/raw format choice.

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 opens with a specific verb+resource ('Read a planning filter') and immediately clarifies the concept ('the selection a planning sequence step or an input template works on'). It enumerates the returned contents, so an agent knows exactly what this retrieves. It stops short of explicitly differentiating itself from sibling getters like bw_get_planning_sequence or bw_get_aggregation_level.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the context in which a filter exists (a sequence step or input template) and cross-references bw_get_planning_sequence, which gives the agent a hint about when to reach for it. However, it states no explicit when-to-use vs. when-not-to-use condition and names no alternative getter to prefer.

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