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 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?

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 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?

Discloses that the InfoObject is created inactive and that a lock/unlock sequence is used. Since no annotations are provided, the description carries the burden and adds useful behavioral context beyond the schema, such as requiring activation post-creation.

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

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

Three sentences, front-loaded with purpose, then sequence and activation step. No fluff, 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 17 parameters, no output schema, and no annotations, the description explains the core purpose and activation step but lacks details on return values, error handling, or when to use this over other creation tools (e.g., bw_create_adso). Adequate but leaves some gaps.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-level details beyond what the schema already provides; it focuses on the overall workflow.

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 'Create a new InfoObject — Characteristic (CHA) or Key Figure (KYF) — inactive', specifying verb, resource, and types. It distinguishes from sibling tools like bw_activate and bw_update_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?

Provides explicit instructions: 'After creation call bw_activate with object_type "iobj" to activate.' and describes the sequence 'lock → POST create → unlock'. Does not explicitly mention alternatives but context with siblings makes creation purpose 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?

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?

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 carries the full burden. It discloses two key behaviors: server-generated name (32-char UUID-like) and inactive creation. It does not cover permissions, failure modes, or side effects, so it's adequate but not comprehensive.

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 containing essential information: purpose, name behavior, and post-creation action. No redundant words, 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?

Given no output schema, the description is complete enough for the tool's complexity. It explains the result (inactive transformation), references the needed sibling tool (bw_activate), and covers parameters adequately. Could mention the return value or confirmation, but not critical.

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 noting that source_system is required for RSDS and that copy_from_transformation exists. It does not elaborate on parameter formatting beyond the schema, but the added context justifies the baseline.

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

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

The description uses specific verbs and resources: 'Create a new Transformation between two BW objects'. It lists object types (aDSO, DataSource, etc.), distinguishes from sibling tools like bw_delete or bw_activate by stating it creates and is followed by activation.

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

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

Explicitly states the created transformation is inactive and instructs to call bw_activate with object_type 'trfn'. This provides clear post-creation guidance. However, it does not mention when not to use this tool or list alternatives for other creation tasks.

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 disclosure burden. It states observable behaviors: 'The variable is created active and consistent', and explains that setting ready_for_input false keeps a variable out of the variable screen. It also states scope limits on replacement path and unsupported variable types. Missing detail such as overwrite behavior or permissions is 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?

Four dense sentences with no filler. The core purpose and resource are front-loaded, then the caveats and exclusions are listed efficiently. Every sentence carries information necessary for invocation.

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

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

For a 13-parameter tool with no output schema and no annotations, the descption provides enough context to understand supported types, representation, and key value (ready_for_input). The schema already covers all parameters, so the description does not need to restate them. It only omits details like whether an existing variable is overwritten, but that is a reasonable and not total 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 complete at 100%, so the baseline is 3.0. The description adds value beyond the schema by clarifying the enum semantics, such as what 'UserEntry' means, the current-member-only restriction on ReplacementPath, and what 'ready_for_input' controls. This helps the agent choose valid parameter combinations.

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 on a characteristic' and connects it to a concrete purpose ('use as a filter parameter in queries'). This distinguishes it from sibling create tools like bw_create_infoobject or bw_create_adso without needing to inspect the schema.

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

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

The description lists exactly which processing types are covered and explicitly excludes unsupported types: 'Text and formula variables are not supported' and 'replacement path is limited to the current-member variant'. While it does not name an alternative tool, there is enough context to decide whether this tool applies, and clear when-not-to-use signals are present.

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 permanent, immediate deletion, no activation needed, query deletion scoping, and dependency constraints. With no annotations, description fully carries the burden of behavioral disclosure.

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

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

Five sentences, front-loaded with main action, then sequence and clarifications. Every sentence adds distinct information; no redundancy or fluff.

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 all essential aspects: deletion semantics, sequence, special cases (queries), and dependencies. No output schema needed; description is complete for this simple 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 already describes both parameters (100% coverage). Description adds value by elaborating object types, query alias, and contextual usage notes (dependency order), but does not introduce new parameter syntax.

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?

Clear verb ('Delete') and resource ('BW object') with explicit examples (aDSO, InfoObject, etc.), distinguishing from sibling delete tools like bw_delete_transformation_routine.

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 sequence (lock -> delete -> unlock), notes immediacy, and clarifies query deletion behavior and dependency order (aDSO before InfoObject). Lacks explicit exclusion of alternative tools but sufficiently covers when to use.

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 full burden. It transparently details the returned fields, including nested structures, without contradictory claims.

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 with front-loaded purpose and detailed breakdown of return fields. Slightly lengthy but necessary for completeness.

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 one parameter and no output schema, the description fully compensates by listing all returned elements, making it self-sufficient.

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

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

Schema coverage is 100% for the single parameter. The description adds an example but no extra semantics beyond what the schema provides.

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

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

The description clearly states it reads an Aggregation Level definition and explains its role. It distinguishes from sibling getters by focusing on this specific object type.

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 context for retrieving ALVL definitions but provides no explicit guidance on when to use alternatives 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?

With no annotations provided, the description carries full responsibility. It clearly indicates a read operation ('Read') and details what is returned, including recursive resolution and dependency graphs. No behavioral contradictions are present.

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 no wasted words. The first sentence front-loads the action and resource, making the purpose immediately 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?

The description covers what the tool returns without an output schema, listing key components. While it could specify the exact output format, it provides sufficient context for an agent to understand the tool's capability.

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% (one parameter with full description). The description adds context by specifying the CKF is at the CompositeProvider level, enriching the parameter's meaning beyond the schema's technical name hint.

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 reads a global CKF at CompositeProvider level and specifies the exact return data (technical name, description, formula, metadata, dependency graph). This differentiates it from sibling tools like bw_get_rkf which deals with RKFs.

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?

While it does not explicitly state when not to use it or name alternatives, the description and tool name make it clear that it is intended for CKF retrieval. The context is implied but could be more explicit about exclusions.

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

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

No annotations are provided, so the description carries full behavioral burden. It states 'Read' (implies no modification), lists return content in detail, and notes 'Returns the inactive version'. It does not explicitly assert idempotency or safety, but the read nature is clear.

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

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

The description is a single sentence that front-loads the action and then lists what is returned. It is informative without unnecessary fluff, though the list is somewhat lengthy.

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 fully explains what the tool returns (general info, view node type, source providers, fields, join conditions, temporal details). The single parameter is clearly documented in schema, and the description specifies the version ('inactive'). No gaps remain.

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

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

Schema description coverage is 100% (parameter described as technical name). The tool description does not add additional meaning beyond what the schema already provides; baseline 3 applies.

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

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

The description uses a specific verb ('Read') and resource ('CompositeProvider (HCPR) structure'), and lists detailed contents (view node type, source providers, fields, etc.). It clearly distinguishes from sibling get_* tools that target 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?

Usage is implied by the tool name and description (use when you need CompositeProvider details), but there is no explicit guidance on when not to use it or comparison to alternatives like other get_* 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 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 provided, so description carries full burden. Clearly indicates a read operation ('Read'), but does not explicitly state non-destructiveness or permission requirements. Notes that loading the full definition is heavier than alternatives, which adds useful behavioral context.

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

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

Two sentences with clear front-loading. First sentence conveys purpose and scope concisely. Second sentence provides usage guidance. Very efficient, though the second sentence could be slightly more integrated.

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 one parameter and no output schema, the description adequately explains what will be returned (source, target, transformation, etc.) and how to use the tool in context. No missing critical information.

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%: one required parameter dtp_name with schema description. The description adds an example format ('DTP_...') but no additional semantic detail beyond the schema. 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 uses a specific verb ('Read') and clearly identifies the resource ('DTP definition') with a detailed list of included components. It distinguishes itself from sibling tools like bw_get_dtps and bw_xref by specifying the scope.

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

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

Explicitly states prerequisite: use bw_xref on an aDSO to find the DTP name first. Provides alternative: for process chain membership only, use bw_xref with object_type=DTPA, which is faster.

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?

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?

The description states 'Read' which implies a read-only operation, but it does not explicitly declare this or mention any side effects, permissions, or restrictions. Since no annotations are provided, the description could be more explicit about the safe, non-destructive nature of the 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 concise and informative, covering the purpose, return fields, and example types. It could be slightly more structured (e.g., breaking out the returned items), but it is efficient and free of extraneous 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 lack of an output schema, the description lists the key returned elements (name, description, function type, aggregation level, etc.) and includes specific details like FOX code for formula functions. It adequately covers the tool's capabilities for a read operation, though it could mention prerequisites (e.g., existence of the planning function).

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 single parameter that has a clear description. The description adds context about what the tool retrieves (e.g., function types, FOX code) but does not add significant meaning beyond the schema for the parameter itself. 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 'Read a Planning Function (TLOGO PLSE) definition' and specifies the types of planning operations. It distinguishes from sibling tools like 'bw_get_planning_properties' and 'bw_get_planning_sequence' by focusing on the full definition including characteristic usage and parameter tree.

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 what the tool does and what it returns, implying usage when a detailed definition of a planning function is needed. However, it lacks explicit guidance on when not to use it or alternatives among the many read tools.

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

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

With no annotations, the description carries full burden. It correctly identifies the tool as read-only ('Read') and lists returned data. However, it does not disclose error behavior (e.g., if provider is not plan-enabled or missing), nor any potential side effects or permissions needed.

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 purpose and scope, no fluff. Every sentence adds meaningful context.

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 thoroughly lists the returned fields. It covers provider identification, settings, and naming. Lacks mention of error handling but is generally complete for a read tool.

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

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

Schema coverage is 100% for the single parameter, which is well-described. The description adds value by clarifying the naming convention (PLCR shares name with provider) and reinforcing the 'plan-enabled' requirement, exceeding what the schema alone provides.

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

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

The description clearly states it reads Planning Properties of plan-enabled InfoProviders, specifies the provider types (real-time aDSO or CompositeProvider), and lists the returned fields. It distinguishes from siblings like bw_get_planning_function that read different planning 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 implies when to use (to read planning settings of a provider) but does not explicitly state when not to use or suggest alternatives among siblings. Given the presence of bw_get_planning_function and bw_get_planning_sequence, clearer guidance would be beneficial.

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 correctly indicates a read operation and details the returned fields, but does not mention authorization needs, potential errors, or rate limits.

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 with two sentences. The first sentence states the purpose and main output, while the second details the step list content. 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 the tool has only one parameter and no output schema, the description is fairly complete. It explains the return value including step details. However, it does not mention what happens if the sequence does not exist, which is a minor 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?

The input schema has 100% description coverage with a clear parameter description. The tool description adds no additional semantic value beyond restating the parameter's purpose, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool reads a Planning Sequence definition, specifying the exact resource ('Planning Sequence') and what it returns (name, description, InfoArea, etc.). It also distinguishes from sibling tools like bw_get_planning_function by focusing on the sequence of 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?

The description implies usage by stating what the tool does (read a Planning Sequence definition), but does not explicitly specify when to use this tool over alternatives or provide any 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?

No annotations provided, so description carries full burden. It discloses default behavior of fetching variant details, steps without detail, and that include_variant_details=false provides faster structural overview. It does not mention potential timeouts or rate limits but is otherwise 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?

Description is front-loaded with a summary sentence, then details on default behavior and exceptions. Every sentence provides value, though slightly wordy. Well-structured and informative.

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

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

No output schema, but description lists all components: header, scheduling/monitoring, steps, edges, and variant details. It addresses missing detail for some step types and redirects to alternative tools. Complete enough for an AI agent to understand the return 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% (baseline 3). Description adds meaning beyond schema by explaining default behavior of include_variant_details, what happens for steps without variant detail, and providing context for format parameter (human-readable vs raw JSON). Adds significant value.

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 reads a Process Chain definition and lists components. It uses a specific verb 'Read' and resource 'Process Chain definition', and distinguishes from siblings by mentioning alternatives for specific step types and suggesting bw_search for finding chain names.

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

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

Explicit guidance on when to use this tool (to get full definition) and when not (for DTP_LOAD steps use bw_get_dtp, for CHAIN steps use recursively). Also suggests bw_search to find chain names first and explains trade-off of include_variant_details parameter.

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 explains the tool is read-only ('Read') and details the output structure. Does not disclose any limitations or restrictions beyond the data returned, but for a read operation this is sufficient.

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?

Concise 4-sentence description with no filler. Purpose is stated first, followed by key details and prerequisites. 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?

Without output schema or annotations, the description adequately covers what is returned (steps, messages, relationships). Could include more detail on ordering or number of steps, but sufficient for agent understanding.

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 baseline is 3. The description reiterates the origin of parameters and adds a usage context, but does not provide new semantic meaning beyond the 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 'Read the execution detail of one process chain run' and enumerates exactly what is included: process steps with type, variant, status, timestamps, predecessor graph edges, and message log. It differentiates from sibling tools like bw_get_process_chain and bw_list_process_chain_runs.

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 use case: 'Use this to diagnose a failed run' and specifies where to obtain input parameters (from bw_list_process_chain_runs or bw_list_process_chain_last_status). Does not explicitly mention when not to use, 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?

No annotations are provided, so the description carries full responsibility. It clearly states the tool is read-only ('Read'), describes how unknown types are handled (oDetail as indented JSON), and explains the 'raw' format option. This provides sufficient 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 a single paragraph with no redundancy. It front-loads the purpose, then lists process types, input sourcing, and format options—each 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 three parameters and no output schema, the description covers input sourcing, return format variants, and behavior for unknown types. It lacks explicit output structure details for each process type, but the format options and example of indented JSON provide adequate guidance.

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 critical context: it tells that process_type and variant_name come from specific fields in bw_get_process_chain output. For the format parameter, it clarifies the difference between 'text' and 'raw' beyond the enum 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 starts with a clear verb+resource: 'Read the detail configuration of a single Process Variant from a Process Chain step.' It lists specific process types and distinguishes from the sibling tool bw_get_process_chain by instructing where to obtain inputs.

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 tool: to read a process variant detail from a chain step. It explicitly ties inputs to the output of bw_get_process_chain. While it doesn't list negative conditions, the context is well-defined.

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 describes the fetch operation as non-destructive and lists return values (field names, data types, required fields). No side effects or hidden behaviors left unexplained.

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

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

Two sentences with zero waste. First sentence states action and result, second sentence gives usage direction. Information is front-loaded and every sentence earns its place.

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

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

For a simple getter with one required parameter and no output schema, the description adequately communicates what is returned (field names, data types, required fields). No missing or confusing details.

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

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

Schema coverage is 100% (single parameter adso_name fully described). Description adds usage context ('for an aDSO write interface') but doesn't enrich parameter semantics beyond what schema provides. Slight bonus for contextual framing.

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 'Fetch the JSON schema for an aDSO write interface' with specific verb and resource. Distinguishes from sibling tools as it is unique for push schema, and explicitly mentions it returns field names, data types, and required fields.

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 states 'Use this before bw_push_data to know what fields to include in records.' This provides clear when-to-use guidance and an alternative sibling tool reference (bw_push_data). No 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?

Discloses fallback behavior for inactive versions and two format outputs. With no annotations, this provides moderate transparency, but lacks details on permissions 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?

Two sentences, front-loaded with purpose, no wasted words. Clear structure and 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?

Without an output schema, the description sufficiently explains return values for both formats and the fallback behavior, making it complete for a two-parameter read 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, but description adds meaningful output descriptions for each format (human-readable vs JSON), enhancing understanding beyond 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 tool reads a BW Query definition and lists its components (variables, filter, layout, etc.). It is specific to queries but does not explicitly differentiate from sibling 'get' tools like bw_get_structure.

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 versus alternatives such as bw_get_structure or bw_get_ckf. The description only explains format options without 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?

With no annotations, the description is the sole source of behavioral info. It discloses that the tool retrieves assignments, returns specific fields, and provides a clear message when no results. However, it does not mention permissions, side effects (presumably read-only), or performance implications. The disclosure is adequate for a simple get operation.

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

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

Two sentences, each essential. The first sentence states the action and what is returned; the second handles the edge case. 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?

With no output schema, the description must explain return structure. It does so by listing fields (role name, description, folder) and implies a list via 'for each assignment.' It also covers the empty case. The tool is simple with one param, and the description provides sufficient context for an agent to use it 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% (one parameter with description). The schema already documents 'Technical name... (case-insensitive).' The tool description adds no additional parameter details beyond the schema, so baseline score 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 clearly states the verb 'Get' and the resource 'roles and folders where a specific BW query is published.' It specifies output fields (role name, description, folder) and handles the case of no results, distinguishing it from siblings like bw_get_role_queries which likely queries in reverse.

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 when needing to know where a query is published, but it does not explicitly state when not to use this tool versus alternatives like bw_get_role_queries or bw_get_roles. There is no mention of preconditions or exclusions.

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

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

With no annotations provided, the description carries the full behavioral burden and it does so richly: it marks the operation read-only, explains the buffered 'Running' behavior, says the status is cross-checked against runtime tables and the batch job, notes that a corrected status names its source, and warns when the header lags. This goes well beyond a simple getter description and prepares the agent for a commonly confusing 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 concise for the behavioral complexity it has to convey, and the key facts are front-loaded: what is returned and read-only first. Each subsequent sentence adds new information about diagnosis, the buffered status pitfall, and polling, rather than repeating the schema. It is longer than a two-line description, but the length is justified by the non-obvious status behavior.

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

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

For a fairly complex diagnostic tool with no output schema, the description covers what an agent needs: returned fields, the log as diagnostic carrier, the meaning of the status edge cases, and the polling recommendation. The five-step list, corrected-source behavior, and lag-warning behavior provide context an agent would otherwise not infer from the schema.

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

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

Schema description coverage is 100%, so the baseline is 3: the schema already documents every parameter including the enum, defaults, case-insensitivity, and the auto-resolution of the request number. The description does not add much parameter-level semantics, though it does mention bw_list_remodeling_requests as the source for two of the identifiers, which is mildly useful.

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 ('get') and resource ('one remodeling request') and states exactly what is returned: header, per-step statuses for the five processing steps, and log messages. It distinguishes itself from the sibling bw_list_remodeling_requests by being the single-request status/diagnosis tool, so an agent can pick it apart from the list tool without opening the schema.

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

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

The description says this is 'the tool to diagnose a failed remodeling' and explicitly instructs to 'poll this tool to wait for a run to finish', which gives concrete when-to-use guidance. It does not name the alternative tools or explicitly say when not to use it, but the context makes the intended use 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?

The description explicitly states 'Read-only', which is a key behavioral trait. It also discloses what components are bundled (header, DTP info, process chain, message log). With no annotations provided, the description carries the full burden and adequately conveys the non-destructive, informational nature of the 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 two sentences: the first states purpose and bundled components, the second adds read-only nature and prerequisite. No redundant information; every sentence serves a clear 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?

Given no output schema and moderate complexity, the description adequately outlines the returned sections (header, DTP info, process chain, message log) and the source of the TSN. However, it does not mention error behavior (e.g., storage code causing partial results) or the output structure for raw vs text format, which is partially covered in parameter 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 baseline is 3. The description adds marginal value by specifying that request_tsn comes from bw_list_requests output, but does not add new meaning for format or storage beyond what the schema already describes.

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 'get' and resource 'request', specifying that it provides 'full status analysis' bundling header, DTP info, process step chain, and message log. It distinguishes from siblings by emphasizing the comprehensive single-call bundling, which is not available in other get tools like bw_get_dtp or bw_get_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 mentions the prerequisite that the request TSN comes from bw_list_requests output, providing context. However, it does not explicitly state when to use this tool versus alternatives (e.g., bw_get_dtp for detailed DTP info) or when not to use it, leaving the agent to infer usage from the bundling 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 provided; description correctly indicates a read operation and lists return fields, but lacks information on error conditions, permissions, or side effects beyond the obvious.

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 that concisely states the action and outputs, with 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?

For a simple read tool with one well-documented parameter, the description covers purpose and outputs; however, no output schema and limited behavioral context make it minimally 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?

Single parameter has full 100% schema coverage including description; tool description adds no extra semantics beyond what is already 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 clearly states the tool reads a global Restricted Key Figure (RKF) and lists the returned fields (technical name, description, etc.), differentiating it from other BW get tools like bw_get_ckf.

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 (e.g., bw_get_ckf), nor any preconditions or context for usage.

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

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

No annotations are provided, so the description carries full burden. It discloses the return structure and exclusions (only SAP_BW_QUERY objects, not other PFCG types). However, it does not mention read-only nature explicitly, potential errors, or performance characteristics.

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 defines purpose and return, second clarifies behavioral boundary, third gives usage guidance. No redundant or extraneous 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 no output schema and no annotations, the description covers the core functionality, parameter usage, and return structure reasonably well. Lacks details on error handling, sorting, or pagination, but these are minor 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?

The schema with 100% description coverage already documents the role_name parameter. The description adds value by connecting role_name to bw_get_roles and reiterates the filtering logic, clarifying the behavior 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 the tool lists BW queries published in roles via the 'Publish to Role' mechanism, and specifies the returned information (role, query technical name, description, object type, InfoProvider). It distinguishes itself from sibling tools by focusing on published queries only, not other PFCG entries.

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 using the role_name parameter to filter or omitting it to get all roles. However, it lacks explicit direction on when to use this tool versus alternatives like bw_get_query_roles or bw_set_query_roles, relying on contextual understanding from sibling names.

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