bw-modeling-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation4/5
Most tools have clearly distinct purposes and the descriptions explicitly resolve near-overlaps (e.g., bw_search vs bw_get_*, bw_preview vs bw_query_data). Some overlap remains: bw_get_dtps is essentially a filtered bw_xref, and multiple process-chain editing tools have very similar boundaries, but the detailed descriptions keep confusion low.
Naming Consistency5/5
All tool names follow the bw_verb_noun pattern consistently (bw_get_adso, bw_create_dtp, bw_add_process_chain_edge). The only outliers are bw_xref and bw_search, but they are short idiomatic verbs rather than convention breaking. No camelCase or mixed styles.
Tool Count1/5
With 99 tools, the surface is far larger than what an agent can handle precisely in one decision loop, even for a modeling domain. Many tools are related to four or five object types and could be grouped into sub toolsets. The extreme count fits the '50+ tools' boundary described as an extreme mismatch.
Completeness4/5
The set provides broad CRUD/lifecycle coverage across aDSOs, InfoObjects, Transformations, DTPs, DataSources, Queries, CompositeProviders, Process Chains, and planning artifacts. Major gaps include lack of variable update/delete, rout access but not creation of global CKFs/Structures, and only limited planning modification, but core workflows are complete.
Average 4.3/5 across 99 of 99 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 13 of 17 community issues answered or closed in the last 6 months
- 54 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description reveals it is a single POST operation with no lock/unlock required. This gives mild behavioral insight, but missing details on reversibility, permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no fluff. Essential information is front-loaded, and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a move operation with three parameters and no output schema, the description covers the basic purpose. However, it lacks details on return values, error conditions, or idempotency, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond schema descriptions. It reinforces the purpose but does not provide additional parameter-level detail that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (move), the resource (BW object with examples), and the destination (different InfoArea). It effectively distinguishes from sibling tools like bw_delete 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that no lock/unlock is needed, providing some usage context. However, it does not specify when to use this tool versus alternatives or when not to use it, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacking annotations, the description carries the burden. It discloses that operations are applied in a single save and that key figure members are unsupported, but does not address side effects, permissions, reversibility, or failure behavior. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: three sentences covering purpose, supported operations, naming rules, and a limitation. Front-loaded with the core action, no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify return behavior (e.g., success indication), which it omits. It does cover the main use case, operations, and limitations, but lacks completeness on what the tool returns after modification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 context about technical naming conventions and unsupported key figure members, though much of this information is already in the schema descriptions. No significant new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Modify', the resource 'BW Query filter', and the supported restriction types. It distinguishes from siblings like bw_update_query_layout or bw_update_query_key_figures by focusing specifically on filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing supported operations and limitations (no key figure members), but does not explicitly state when to use this tool versus alternatives (e.g., update_layout, update_key_figures). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It explains the creation of routine group and method stub, and the return value (lock_handle), but does not disclose side effects, idempotency, or how conflicts are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action, the second provides the outcome and return value. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value. It covers the main behavior and the optional transport parameter. Lacks mention of prerequisites (e.g., transformation must exist), but overall adequate for a simple creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds value by stating the return value (lock_handle) but does not provide additional parameter-level details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Add') and resources ('routine to a Transformation'), and distinguishes from sibling tools like bw_delete_transformation_routine by specifying the creation of global routine group and method stub.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the purpose implies when to use it (when adding a routine), there is no explicit guidance on when not to use it or alternatives. No prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does so by stating the tool only changes HANARuntime, reads from active version, activates automatically, verifies the change, and returns an error if the switch does not persist. It also notes no separate bw_activate is needed. Missing details on permissions or rate limits, but good overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph. It front-loads the purpose and then provides behavioral details. It is concise with no wasted words, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description covers purpose, behavior, and conditional error return. However, it does not specify the success output format (e.g., what is returned on success), leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds minimal value beyond the schema; it mostly reiterates what is already in the schema descriptions (e.g., runtime enum meanings, transport requirement condition). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches a transformation between HANA and ABAP runtime, modifying only the HANARuntime attribute. It distinguishes this from other transformation tools like bw_update_transformation which handle other changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 switch runtime) and notes early return if already matches. However, it does not explicitly state when not to use it or mention alternatives (e.g., bw_update_transformation for other changes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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 states the operation is a read, but does not disclose authentication needs, rate limits, or behavior on missing source systems. It is adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Read' and the resource. No extraneous words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 lists the returned fields, which is sufficient. It could mention error handling or required permissions, but overall it provides a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter with 100% coverage. The description adds value by specifying what fields will be returned (type, description, etc.), helping the agent understand the tool's output beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('metadata of a single logical source system'), and specifies the fields (type, description, connection details, maintenance properties). It distinguishes itself from siblings like 'bw_list_source_systems' which lists all systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details of a single LSYS, but does not explicitly state when to use it over alternatives like 'bw_list_source_systems'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates this is a read operation (non-destructive) and details the specific data returned, providing good behavioral insight. However, it omits any mention of authentication requirements, rate limits, or potential side effects, though as a read operation, those are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences that convey the tool's purpose and return value without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 parameter, no output schema, no annotations), the description is sufficiently complete. It explains what the tool does and what it returns. It could add more on output structure or dependencies, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for a single parameter, so the baseline is 3. The description adds context ('global Structure at CompositeProvider level') but does not add significant meaning beyond the schema's description ('Technical name of the Structure'). The example 'STR_NAME' is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('global Structure'), and the scope ('at CompositeProvider level'), distinguishing it from sibling tools like bw_get_ckf or bw_get_rkf. It also lists what is returned (ordered member list, types, referenced components, filters, dependency graph).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a structure needs to be read, but does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites or when not to use it. Sibling tools exist for other get operations, but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that it triggers a load and returns a request_id, but does not disclose whether it is synchronous or asynchronous, or potential side effects like concurrent run restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, efficient. Every sentence adds value: first states action, second explains output usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential context: prerequisite (existing active DTP), action, and follow-up step. Lacks error scenario details but is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds a usage example ('e.g. "DTP..."'). This provides slight additional clarity but does not significantly exceed what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts an existing active DTP run. It differentiates from siblings by explaining that the returned request_id can be passed directly to bw_get_request, avoiding bw_list_requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use on an existing active DTP and guides how to monitor the load using the returned request_id with bw_get_request. Lacks explicit 'when not to use' or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes wildcard support and filtering but does not disclose output format, pagination, limits, error conditions, or any performance implications. This lack of detail reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear paragraph that front-loads the main purpose and then provides details. It is concise without being overly terse, though it could benefit from slightly more structure (e.g., separating usage notes from examples).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should ideally describe the return format or typical results. It does not mention what the search returns (e.g., list of object names with types). Additionally, it omits error handling or edge cases. The description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context: for object_type it lists common TLOGO values with human-readable names, and for search_term it explains wildcard usage with a concrete example. This goes beyond the basic schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a universal search tool for BW objects by name or description, listing many specific object types. It explicitly distinguishes from type-specific sibling tools by advising to prefer this tool when the object name is unknown or a pattern is given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use this tool (whenever the user wants to find, list, or look up any BW object), how to use wildcards, and when to pass object_type. It explicitly advises preferring this over type-specific tools when the name is unknown or a pattern is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly describes the tool's behavior: all operations are applied in a single save, it handles local restrictions, formula trees, and member properties. However, it does not explicitly state whether mutations are permanent or if write permissions are required, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose but is quite lengthy (about 20 lines) due to extensive formula details and edge cases. While these details are valuable, the description could be more concise by moving some technical specifics to the schema or a separate note. As is, it is adequately structured but not optimally succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operation types, recursive formula structures, optional restrictions), the description is comprehensive. It provides necessary context for operations, formula encoding, and interaction with reusable structures. The lack of an output schema means no return value explanation is needed. However, it omits error conditions and behavior for non-existent queries, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds significant value by explaining the formula tree in detail (recursive node types, operator codes, infix/prefix handling), which goes beyond schema descriptions. It also clarifies the 'structure_target' behavior and the interaction with reusable structures. This justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage the key figure structure of an existing BW Query' and lists specific operations (add key figures, references, formulas, set properties, remove members). It distinguishes itself from sibling tools by specifying it targets key figure structures, and mentions a related tool 'bw_update_query_layout add_structure' for reusable structures, providing differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (modifying key figure structures, single save operation) but does not explicitly state when to use this tool versus alternatives. It mentions that operations also apply to a reusable structure referenced via another tool, but lacks guidance on prerequisites, when not to use, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It discloses single-save behavior and technical naming requirement but lacks details on failure modes, authorization needs, or what happens if layout doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three clear sentences, front-loaded with purpose, then transactional behavior and naming convention. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 operation types, target containers, and naming. Missing details on error handling or what happens with invalid operations, but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 context like 'structure is a layout container' and emphasizes technical names, but the schema already describes each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Modify an existing BW Query layout' which clearly states the verb and resource. It enumerates specific actions (add/remove characteristics, add/remove structure references) that distinguish this from sibling query tools like bw_update_query_filter or bw_update_query_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'All operations are applied in a single save,' implying bundling. While the purpose is clear, there is no explicit guidance on when to use vs alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool modifies an existing query, applies only provided settings in one save, and lists immutable fields. It does not mention side effects, authorization needs, or concurrency considerations, but it covers basic behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each with a clear role: first states what the tool does, second clarifies partial updates, third lists what cannot be changed and naming convention. No redundant words; efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 parameters, nested objects) and no output schema, the description provides a solid overview. It covers the tool's effect, scope, and constraints. It could mention prerequisites like the query must exist, but the description is largely complete for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes each parameter. The description adds context by listing the categories of settings and noting that names must be technical names, but does not provide additional semantics beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'change' as the verb and specifies 'query-level display and behaviour settings', distinguishing it from sibling tools like bw_update_query_layout which handle layout. It lists specific settings (zero suppression, result position, sign presentation, etc.), making the purpose clear and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Only the provided settings are applied in a single save', indicating partial updates. It also says which properties cannot be changed (InfoProvider, technical name, package). However, it does not explicitly mention when to use this tool versus siblings like bw_update_query_filter, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only,' explains how remodeling rules arise, and notes that this tool family does not create rules. This meaningfully clarifies side effects and interpretation of returned remodeling_rule IDs, though it does not cover behaviors like ordering, errors, or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and then adds a concise but detailed explanation of remodeling semantics. Each paragraph earns its place; the text is somewhat dense and long, but it avoids filler and is structured from the list action to the conceptual background that an agent needs to interpret results.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the high schema coverage, the description gives enough to call and interpret the tool: it names output fields, explains what a remodeling_rule is, and clarifies key edge cases like the 'empty column' scenario. There is no output schema, so a fuller example of the returned request object would improve completeness, but the current text is not materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the three parameters with clear descriptions (top cap, status codes, info_provider filter). The description adds useful context around what 'status' refers to conceptually and how remodeling_rule IDs are created, but it does not add new parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List remodeling requests from the remodeling monitor.' It also names the meaningful output fields ('decoded status, last run and creator') and frames remodeling as a distinct operation from normal request listing, clearly distinguishing this sibling from bw_list_requests and bw_get_remodeling_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when remodeling concepts matter, including when a remodeling rule is automatically created vs. when appending a field does not trigger one. It does not explicitly name alternative list-based siblings or state 'use this instead of bw_list_requests,' but the remodeling-monitor framing implies the intended use strongly enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reasonably discloses the important behavioral traits: applying to every characteristic with '*', accepting 'default' to fall back, applying all specs in a single save, and requiring the characteristic to already exist in the layout. It does not describe output/response or rollback behavior, which prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and product, then packs the key variants of the trait into a long but informative list. It contains no real filler, although the run-on enumeration and the slight overgeneralization about 'default' keep it from being a model of discretion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is complete enough for a complicated tool with a rich input schema: it explains the wildcard infoobject, the meaning of 'default', the single-save behavior, the necessity of a prior layout, and the need for technical names. It is less complete about the return contract or what happens after a failed save, but the operation itself is clearly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all parameters, so the description did not need to compensate heavily. It does add useful shorthand about 'default' and '*' semantics, but the statement that 'Every property also accepts default' is overbroad because the schema excludes 'default' from several enums items such as text_type and sorting.direction. Because schema coverage is 100%, the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a concrete verb-resource pairing: 'Set the display and access properties of the characteristics in an existing BW Query.' It enumerates the exact property groups affected (result rows, display as key/text, access type, sorting, etc.), which distinguishes it from related update tools like bw_update_query_layout, bw_update_query_key_figures, and bw_update_query_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states an explicit precondition: characteristics must already exist in the layout, and routes the agent to bw_update_query_layout if they need to be added first. It could be stronger by naming the alternative tools it should not be used for, but the very-specific scope ('characteristics' in a query layout) provides enough usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description indicates the tool loads hierarchy (read-only implied) and optionally filters. It does not mention any side effects or specific permissions needed, which would enhance transparency, but it is adequate given the operation nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, no wasted words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description states the return values include roles, folders, and nodeids. It lacks detail on the exact structure of the return, but for a simple list tool, it is nearly complete. Could mention the format or hierarchy depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the schema description already covers the parameter's meaning. The description adds minimal value by restating the optional prefix filter, but this is consistent. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads the BW query role hierarchy and returns roles and folder structure with nodeids. It distinguishes itself by mentioning it's for discovering names needed for a specific sibling tool (bw_set_query_roles).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for discovering role and folder names needed for bw_set_query_roles. It implies when to use it but does not provide explicit when-not-to-use or alternatives, though 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a read operation, but with no annotations, it doesn't disclose additional behavioral traits like permissions or rate limits. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. Each sentence adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains returned structure (source/target, mapping rules) and output formats. Covers key aspects for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining transformation names are UUID-like keys and suggesting how to find them. This enhances parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a Transformation structure' with specific content (source/target segments, mapping rules). It distinguishes from siblings like bw_xref by mentioning how to find the transformation name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use bw_xref before calling this tool, aiding in selecting the correct tool. Lacks explicit when-not-to-use but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the mechanism (cto/check), default filters (own_only, modifiable_only), and the output (list of requests and tasks). However, it does not describe the return format, error behavior, or any potential side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one stating the function and mechanism, another giving usage guidance. No redundant information. Front-loaded with key information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description adequately covers purpose, usage, defaults, and mechanism. It mentions that both requests and tasks are listed. Could hint at pagination or response structure, but overall sufficient for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by explaining the defaults for own_only and modifiable_only, and ties these to the usage context ('find an open request'). This goes beyond the schema descriptions, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (list), resource (transport requests and tasks), context (via BW transport state), and distinguishes from siblings like bw_list_requests by focusing on changeable/modifiable requests. It states the default scope (caller's modifiable requests) and the purpose (find an open request to assign an object).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to find an open request to assign an object to', providing clear guidance on when to use this tool. It implies that other tools might be used for different purposes, but doesn't explicitly mention alternatives. However, given the sibling context, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the two actions (add/remove) and their effects, but does not disclose side effects, permissions, or error handling. It implies a state change but lacks details on idempotency or concurrency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, starting with the main purpose, then detailing actions, then providing cross-references. No wasted words, well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description covers parameter usage and prerequisite tools. It lacks details on return values or success/failure indicators, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 'action' enum, clarifying that target_name depends on target_type, and specifying that parent_role_name is required for folders. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool publishes or unpublishes a BW query in a role or folder. It distinguishes from siblings by naming specific actions and referencing related discovery tools (bw_get_roles, bw_get_query_roles).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs users to use bw_get_roles for discovering names and bw_get_query_roles for current assignments, providing clear context for when to use this tool. However, it does not explicitly mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states that the tool does not activate but returns a lock_handle, and describes rejection conditions. However, it does not mention potential side effects like locking, permission requirements, or whether the change is reversible. Adds sufficient but not exhaustive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph. It front-loads the main purpose, then covers prerequisites, constraints, and return value concisely. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description covers the return value (lock_handle) and references related tools (bw_set_transformation_routine, bw_activate). The description is sufficient for an agent to understand the tool's role and constraints, though it could briefly mention that transformation_name is required (already in schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The tool description adds critical semantics: mutual exclusivity of fields and exclude_fields, case-insensitivity, and the condition that field names must exist in the target segment. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Edit' and the resource 'list of target fields' for the global END routine. It differentiates from siblings such as bw_set_transformation_routine (which creates the routine) and bw_activate (which activates after editing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (requires existing END routine), specifies mutually exclusive parameters (fields or exclude_fields), and lists rejection conditions. It indirectly suggests a workflow by returning a lock_handle for bw_activate. However, it does not explicitly state when not to use this tool (e.g., if the routine does not exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that existing fields are preserved, fields can reference InfoObjects or be local, and it returns a lock_handle. It lacks discussion of authorization or side effects but is sufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with three clear sentences. It is front-loaded with the main purpose and efficiently covers key behaviors and parameters without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description provides a good overview, including the return value. It could be improved by mentioning error handling or prerequisites, but it is adequately complete given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 preservation behavior, the distinction between InfoObject fields and local fields, and the lock_handle return. This goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'InfoSource', and specifies the modifiable aspects (description, fields, labels). It distinguishes itself from sibling tools like 'bw_create_infosource' and 'bw_get_infosource'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when updating an InfoSource) but does not explicitly differentiate from other update tools for different objects or provide when-not-to-use guidelines. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It specifies return fields (name, description, source_system_type, status, self_url, children_path) and filtering behavior. It does not explicitly state read-only status, but the 'list' verb implies it. Overall, clear 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, filtering, and output usage. No unnecessary words; each sentence contributes meaningful information. Excellent front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple list tool with one optional parameter and no output schema, the description covers the return structure, filtering, and how to chain with another tool. It is fully complete for the agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of the one parameter. The description repeats the filtering info and adds examples but does not provide new semantic meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists logical source systems (LSYS) registered in the BW datasource structure. It uses a specific verb-resource combination and distinguishes from sibling tools like bw_get_source_system (single) and bw_list_datasources (drill-down) by mentioning how the returned children_path can be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the optional filter and provides a clear chaining instruction: pass children_path to bw_list_datasources. However, it lacks explicit guidance on when not to use it (e.g., for retrieving a single LSYS) versus using bw_get_source_system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 delivers meaningful details: repeated calls replace the previous routine, existing value selections are preserved, and a failed attempt leaves no routine or generated report. This reveals side effects and failure atomicity well beyond the basic schema, though it does not discuss permissions or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack purpose, usage boundaries, and important behavioral caveats with zero filler. The most important distinction (when to use versus bw_update_dtp) comes in the second sentence, and the entire description remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description gives essential context about placement, conditions, and edge behavior. It could go slightly further by mentioning expected side effects on activation or what 'generated report' refers to, but the description is strong enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents each parameter, including that routine_code must not contain a FORM/ENDFORM wrapper. The description reinforces the domain of the code but does not add additional parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Set an ABAP filter routine on a DTP filter field'), making the tool's function unmistakable. It also differentiates itself from the value-based filtering path in bw_update_dtp, so an agent can distinguish the two at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is present: use only when custom ABAP code is needed, and use bw_update_dtp for value sets, ranges, and patterns. The repeatability caveat further clarifies when it is safe to invoke on the same field again.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that changes are discarded, the lock is freed without activation, and for DTPs the framework enqueue lock is released. It does not cover error conditions or authorization, but is transparent about core 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler, and each sentence earns its place: the core action, the concrete use case, and the important DTP-specific caveat. Front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema tool, the description is nearly complete. It covers behavior, use case, and a critical edge case. Minor gaps like idempotency or failure responses keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 beyond the schema by explaining the special meaning of dtpa (DTP framework enqueue lock) and how the object type/name combine in the unlock operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Release a lock on a BW object without activating it.' It also differentiates from sibling actions like bw_activate by explicitly noting the operation does not activate the object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use context: 'Use this to discard changes and free the lock, e.g., after an aborted create or update.' It does not explicitly list alternatives or when-not-to-use cases, but the usage guidance is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully disclose side effects: replaces all attributes, internal sequence (lock, GET, PUT, activate, unlock), and supports both Characteristic and KYF updates. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences. First sentence states purpose, second provides essential behavioral details. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behaviors for both InfoObject types and internal sequence. Lacks error conditions or prerequisite notes, but sufficient given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds significant context: explains that ommitting description keeps existing, attributes replaces list, transport required for non-local packages, and groups parameters by InfoObject type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates a Characteristic InfoObject, with specifics on changing description, replacing attributes, and handling Key Figure updates. It distinguishes from siblings like bw_create_infoobject and 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.
Usage Guidelines3/5
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, but the purpose is clear. Implied usage for updating existing InfoObjects, but no comparison with alternatives like bw_delete or bw_move_object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses recursive traversal and possible slowness. Describes the return fields and the filter behavior. With no annotations, this provides sufficient behavioral insight for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loading core purpose, then providing detail on traversal, output, and optional filter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: resource type, scope, behavior (recursive, slow), output fields, filter syntax, and default format. Lacks only pagination/limits, but this is acceptable for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains apco_path_filter with example, notes case-insensitivity for source_system, and confirms default format. Schema covers all params, but description enriches usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'List' and the resource 'DataSources (RSDS)' under a logical source system. Distinguishes itself from siblings like bw_get_datasource by listing all vs. single, and bw_search by focusing on hierarchy traversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contextually clear when to use (listing all datasources under a system) and mentions potential performance impact for large systems. Does not explicitly exclude alternatives but the purpose implies distinct use from single-resource tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It explicitly states it is a read operation, includes chains that never ran, returns one row per chain, and allows filtering. It does not mention permissions or rate limits, but the described behavior is transparent enough for a read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and output fields. The second sentence adds important edge cases (never-run chains) and filter options. No wasted words; every sentence is essential and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no output schema, the description covers the output content (fields listed), optional filters, and references a sibling for drill-down. It handles edge cases (chains that never ran) and mentions optional date range filtering. This is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining that the log_id can be used to drill down with a sibling tool and provides format hints for date parameters (ISO format with example). This extra context helps the agent use the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the latest execution status and scheduling state for every process chain, one row per chain. It distinguishes from siblings by specifying it returns aggregate per-chain info and mentions using bw_get_process_chain_run_detail for drill-down, showing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need an overview of all chains with their latest status, scheduling, and optional filtering by status or date. It also suggests an alternative (bw_get_process_chain_run_detail) for drilling into a specific run. However, it does not explicitly state when not to use it relative to other siblings like bw_get_process_chain, but the distinction is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return fields (status, runtime deviation, timestamps, duration, log_id), ordering by start time descending, default limit 20. No annotations provided, so description carries full burden. Covers main behavioral traits but omits potential rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with distinct purpose: purpose, row content, filtering and linking, ordering and limit. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description sufficiently explains return values and how to use them. Parameter descriptions are complete. Tool is simple but description covers all necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 ISO format for dates, optional nature of chain_name, and how status filter works (eq). Provides more meaning than schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists execution runs from process chain monitoring log, with specific fields and filters. Distinguishes from sibling bw_get_process_chain_run_detail by mentioning it returns log_id to pass for step-level details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (listing runs) and provides filtering options. Mentions linking to detail tool for step-level info. Implicitly distinguishes from bw_list_process_chain_last_status by offering full run data. Lacks explicit 'when not to use' but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that success returns an empty body (HTTP 204) and specifies format requirements for DATS and INT4 fields. Could mention error cases or idempotency, but provides adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus format notes. No wasted words. Prerequisites, success indicator, and constraints are front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisite tool, required interface setting, success response, and field formatting. Does not address error handling or record size limits, but for a data push operation it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters, but description adds significant value: explains default mode, clarifies that DATS fields require YYYYMMDD strings and INT4 as JSON integers, and details the messaging mode. These are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it pushes data records into an aDSO inbound table via the SAP BW/4HANA write interface, specifying the verb and resource. Distinguishes from sibling bw_get_push_schema by referencing it as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear prerequisite (use bw_get_push_schema first) and success condition (HTTP 204). Does not explicitly mention when not to use or alternatives, but provides strong context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 well, disclosing that the object becomes inactive, that skips are not errors, that invalid removals are refused, and that CompositeProvider accepts both prefixed and bare names. It does not mention potential failure modes like authentication or transport-level permissions, but it covers the most decision-relevant behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but never verbose. It front-loads the core purpose and action names, then adds procedural, edge-case, and compatibility details in a logical order with almost no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation, action-specific nuances, skipped-field behavior, post-update activation requirement, all fields the guard condition for removals, and special CompositeProvider handling. An agent has enough behavioral context to call this tool correctly even without annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 4 parameters well, giving a strong baseline. The description still adds meaningful semantics by explaining what add_fields and remove_fields actually do to the Aggregation Level, who field resolution works, and how CompositeProvider naming behaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing Aggregation Level by adding or removing fields, with explicit action names. It distinguishes itself from related siblings like bw_create_aggregation_level and bw_get_aggregation_level by emphasizing modification of existing objects rather than creation or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when fields need to be added to or removed from an existing Aggregation Level. It also explains the expected follow-up activation step with bw_activate, but it does not explicitly state when not to use it or name alternative update/create paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: how rule_type affects transformation, handling of combined rules, parameter dependencies, and return value (lock_handle). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured, though slightly lengthy. Every sentence adds value, but could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 params, no output schema), the description covers all rule types, parameter dependencies, and return values. It could mention error cases or prerequisites but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value with examples (e.g., formula syntax, unit_source_field usage) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: mapping a source field to a target InfoObject or converting an existing rule to a routine or formula. It distinguishes from sibling tools by focusing on updates to transformation rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on when to use each rule_type, with conditions and examples. It lacks explicit comparison to alternative tools but covers usage context well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description clearly labels the tool as read-only discovery, which is transparent. No annotations are provided, so the description carries the burden and does well. However, it could mention that it's a list operation without side effects, but the context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three sentences. It front-loads the purpose, then provides usage guidance. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, but the description gives enough context about the return (list of entities with technical_name). For a listing tool, it's adequately complete, though a mention of return structure would be slightly better.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. The tool description adds value by explaining the result_size parameter's role in truncation and the search_pattern's filtering on technicalName. It also emphasizes that technical_name is key for the binding tool, enhancing schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists remote entities (HANA views/virtual tables) exposed by a source system as DataSource basis. It specifies the read-only discovery nature and references the Eclipse value help, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to find a valid hana_entity before creating a DataSource. It also links the technical_name to the bw_create_datasource tool, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: read-only, per-row backend enrichment cost, how top and created_from affect performance, and that default parameter values exist. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but each sentence adds value. It could be slightly tighter, but it's well-structured and front-loaded with purpose and output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description sufficiently explains return content (request status, record counts, timestamps, TSN) and connects to sibling bw_get_request. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds meaningful context beyond schema: explains top's performance impact, created_from as a cost-reducer, default status codes, and case-insensitivity of target. Adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent load requests of an InfoProvider from the runtime request monitor. It specifies return details like request status, record counts, timestamps, and internal request TSN, distinguishing it from siblings like bw_get_request (which takes the TSN as input) and bw_search (used to find the target technical name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using bw_search first to find the target technical name, and provides performance guidance on using a narrow created_from window or small top. It does not explicitly state when not to use, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description handles the behavioral disclosure: it states it read-only, requires ADT authorization, is backed by the ADT DataPreview service, and describes a subtle ordering trait for RSPC (parallel branches have no fixed order, so the agent must read an "After" line to get the actual dependency). It doesn't describe the entire return shape, but the per-type notes already hint at the returned content quite clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries load: fallback role, system-profile check, supported types, an important delimiter for RSPC, an official auth requirement, and the preferred alternative. It introduces the core read-only behavior first and then builds from that description without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param, no-output-schema tool, the description is almost complete: it covers target object types, when to use, the correct alternative, how to discover it, auth, and even an unusual ordering caveat for process chains. A small gap, it could explicitly comment on the raw format or content returned, but the object-type notes already imply at least the high-level response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for both parameters, so the baseline is 3. The description adds meaningful extra context by clarifying the object_name format (UUID-like for TRFN) and giving semantic details about each object_type, especially RSPC ordering and TRFN routine source quoting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
It has a specific verb and resource — “Read a BW object definition directly from its metadata tables (via AD object definition directly from its metadata tables (via ADT DataPreview service)” — and lists every supported object type. It also distinguishes itself from sibling REST-based readers by calling out “Read-only fallback for object types the connected system does not publish as a REST resource.”
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to prefer an alternative (“Prefer bw_get_transformation where the REST endpoint exists”), when the tool is meant to be used (fallback when no REST resource is published), and how to verify that (“Use bw_system_profile to see which endpoints a system publishes”). This covers both the when and the when-not condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it largely succeeds: it reveals that the tool checks three preconditions, explains the Accept-header failure mode (HTTP 406 on BW 7.5), and states what the response effectively exposes. It does not explicitly say whether the call is read-only or whether any side effects exist, but the described behavior strongly implies discovery and inspection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then expands into concrete behavioral details. It is longer than strictly necessary, with 'One call beats inferring the release from failed ones' being a slightly rhetorical closer, but nearly every sentence carries useful operational meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter profiling tool, the description is complete: it covers the release distinction, endpoint-group discovery, precondition checks, failure modes, and the alternate tool path when REST resources do not exist. An agent can decide when to invoke it and what the answer will actually mean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is no semantic gap for the description to fill. The baseline of 4 applies, and the description correctly focuses on behavior rather than inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find out what the connected BW system is and which of this server's tools will work on it.' It clearly identifies the tool as a system-introspection/profiling capability and distinguishes it from the many sibling tools that perform CRUD or execution operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call it 'before planning work on a system whose release you do not already know.' It also notes the alternative route on classic BW systems — reading transformations, DTPs, and classic providers with bw_read_metadata_tables instead of REST tools — giving an agent concrete routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and succeeds admirably. It discloses side effects ('removes the element and all mappings referencing it', 'leaving its elements and any join reference behind'), the mandatory lock_handle return, replacement semantics of update_mapping, and the failure condition 'join fields need at least one common target field' plus the pitfall that 'auto-mapping does not do this'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long by necessity but front-loaded: the critical lock_handle activation requirement appears in the first two sentences. The body is organized under clearly labeled action groups ('Fields:', 'Sources:', 'Mappings:', 'Joins:', 'Settings:'), which aids scanning, though the dense semicolon-separated style makes some clauses hard to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 18 parameters, an 8-action enum, and the absence of any output schema or annotations, the description covers every important behavior: each action's effect, defaults, return lock_handle, the join-failure edge case, and the four settings sub-values. Nothing critical for an agent to invoke this tool correctly remains unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, giving baseline 3, and the description adds meaningful semantics on top: which parameters apply to which of the eight actions, defaults (action 'add_field' is default, provider_type defaults to 'ADSO'), the empty-list-means-one-to-one mapping rule, and examples like 'U1.ADSO.1' and 'DEVK900123'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the operation verb ('Change'), the resource ('CompositeProvider (HCPR)'), and enumerates what can be changed: 'its fields, its source providers, their field mappings, the join condition, or root settings'. This clearly distinguishes it from siblings like bw_create_composite_provider, bw_get_composite_provider, and bw_activate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the activation workflow: 'Every action returns a lock_handle that must be passed to bw_activate (object type hcpr) — an HCPR cannot be activated without it', naming the alternative tool directly. It also guides usage per action (e.g., 'This is also how an input attached at creation time gets its mappings'), though it never explicitly states 'use bw_create_composite_provider for creation instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so exceptionally: it discloses REPLACE semantics ('a second call on the same field replaces the first, it does not add to it'), the delta-init re-initialization hazard when switching extraction modes, and the failure mode of a wrong filter value ('activates cleanly and filters everything away'). This goes far beyond what a terse 'Update DTP' would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact for its payload: the first sentence, what? it's a large DTP with 11 params; all four sentences earn place. The behavior: REPLACE semantics is front-loaded rather than buried. No cleaned-up repetition between the description and the parameter schemas.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter mutation tool with no annotations and no output schema, the description plus param schemata cover virually every prerequisite call the agent needs: exact field naming, value lookup, transport control site, delta-init side effects, and the clear the semantic-optional rules. The missing piece is the return outcome confirmation — whether the successful call returns an ack, a status object, or the updated DTP — which an agent cannot know in advance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a rich description, so the baseline is 3. The tool description adds meaningful interaction-level semantics: the whole-selection contract, mutual exclusivity between filter_value and filter_selections, and the cross-tool reading order (bw_get_dtp' then bw_get_filter_values) — raising it to a 4 but not 5 since the schema itself does most parameter-legible work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb + resource statement: 'Update DTP properties' and enumerates the exact updateable aspects — description, value selection of one filter field, extraction mode, and semantic group. The phrase 'Use this for setting filter values on existing filter fields' differentiates it from the many bw_get_*/bw_create_*/bw_set_* siblings, especially bw_create_dtp and bw_set_dtp_filter_routine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the intended use case clearly ('Use this for setting filter values on existing filter fields') and names prerequisite tools — bw_get_dtp for exact field names and bw_get_filter_values for valid values — giving an actionable call order. It does not explicitly state when NOT to use this tool or name the alternative for filter routines (bw_set_dtp_filter_routine), so the 'when-not/alternatives' bar is not fully met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes the behavior as read-only, lists return fields, and explains how path affects output. No contradictions, and behavior is fully disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that packs in purpose, path details, and return fields. It is efficient but could be better structured with bullet points or sections for improved readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 relevant return fields. Covers navigation patterns, making the tool fully understandable for its browsing purpose. Complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds significant context by explaining the hierarchical path patterns with examples (e.g., 'area/{name}/{folder}', 'hcpr/CP_NAME'). This goes well beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads direct children of any node in the BW repository tree. It uses a specific verb ('Read') and resource ('direct children'), and distinguishes from sibling tools like getters and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit examples of path patterns for navigation (e.g., '/', 'area/{name}', '{type}/{name}') and advises that 'children_path' can be passed directly to drill down. Lacks explicit when-not-to-use guidance 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses it reads first N rows, returns formatted table, default 20 records, and SAP caps at that. However, it does not mention permissions or potential performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and efficient. Front-loads purpose, then usage guidance. Every sentence serves a purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description mentions return format. Covers purpose, usage, and parameter details adequately for a simple preview tool. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context: case-insensitivity, source system naming, default for records, and SAP behavior. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a live data preview from a DataSource, reads first N rows, returns formatted table. It distinguishes itself from bw_query_data for other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (user wants to preview data from DataSource) and when not (use bw_query_data for aDSO, CompositeProvider, BEx query), providing an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of explaining behavior, and it does so exceptionally. It discloses that this is an in-place read-modify-write operation, that edges and inline process variants are removed, that reconnection will bridge predecessors to successors, and it explicitly calls out the 412 ETag staleness condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. Every sentence contributes meaningful operational guidance: purpose, in-place behavior, reconnection semantics, intended use, restriction, and error handling. No filler or redundant restatement exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters and no annotations, the description is remarkably complete: it explains the full mutation lifecycle, the side effects on edges and process variants, how accurate reconnection behaves, the important TRIGGER restriction, invalid name behavior, and ETag failure handling. Even without an output schema, an agent has enough context to invoke the tool correctly and interpret the most likely error condition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all five parameters with meaningful descriptions, including the subtle semantics of step references. The tool description does not add much parameter-level meaning beyond that, so a baseline score of 3 is appropriate since the schema fully carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: removing one step/node from a Process Chain, and immediately distinguishes it from related tools like bw_remove_process_chain_edge by explicitly saying 'step (node)'. It also names the relevant API context and gives concrete behavioral detail, so an agent can tell this tool apart from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: to roll back a step inserted in the wrong place. It also gives exclusion guidance (the TRIGGER/Start step cannot be removed) and explains the consequence of reconnect=false, including how to recover by rewiring with bw_add_process_chain_edge. This gives clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the safety burden. It clearly warns that this is a WRITE OPERATION WITH DATA IMPACT, that data is restructured/converted, and that it cannot simply be undone. It also explains that the call is asynchronous, which prevents the agent from wrongly expecting immediate completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the most critical information, the destructive/asynchronous nature, before defining the actions. Each sentence contributes distinct information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex write operation with no output schema, the description covers the essential points: what the actions are, why the operation is dangerous, and how to check completion. It is complete enough for an agent to invoke the tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% description coverage, so the baseline is 3. The description adds real value by explaining what each action value does: execute starts, restart resumes, reset resets whole, reset_step resets the current step. This goes beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Start, restart or reset a remodeling request', and it goes beyond the name by enumerating the four actions. It immediately signals that this is not read-only, distinguishing it from monitoring tools like bw_get_remodeling_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to invoke it — for a new request, a failed one, or to reset whole/current step — and tells the agent to monitor completion via bw_get_remodeling_request. It does not explicitly spell out 'do not use this for plain reloads' but it says 'not a plain reload', which effectively excludes that alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses that source_system is required for RSDS and that the padded objectName is built automatically, but does not mention return format or side effects; however, as a read-only lookup, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding distinct value: purpose, examples, special case, and comparison with sibling. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when and how to use, but lacks description of the return value (a list of references) since no output schema is provided. Minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description enriches semantics by specifying that object_type=DTPA finds process chains and that source_system triggers auto-construction of objectName for RSDS.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find where-used / dependencies') and resource ('BW object'), and clearly distinguishes from sibling tools like bw_get_dtp by mentioning it is preferred when only the process chain is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (find dependencies) with concrete examples (Transformations, DTPs referencing aDSO) and provides an alternative (preferred over bw_get_dtp for process chain lookup).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behaviors: session-specific variable IDs that change between calls, trailing spaces in variable names, the need for a GET to discover layout and variables, and the key figure structure filter mechanism. It also mentions result rendering and raw XML output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but front-loaded with the core action and structured with clear steps. Some redundancy exists (e.g., mentioning bw_search twice), but every sentence delivers necessary information for correct usage. Slightly overlong but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers prerequisites, sequence, variable handling, hierarchies, filters, pagination, drill operations, and result format. It addresses all potential agent questions for a complex query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds substantial meaning: explains the workflow (GET before POST), variable ID reuse dangers, drill operations context, and how filterValues work on structure dimensions. This far exceeds the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a BW query or previews data from providers. It distinguishes from sibling read tools by specifying that users should call them first to get metadata. The wording is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use this tool versus alternatives: always call appropriate read tools first, perform GET before POST, call bw_get_filter_values before applying filters, and use bw_search or bw_list_contents when unsure. Provides step-by-step guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with no annotations provided, the description fully discloses behavioral traits: it performs an in-place read-modify-write via the REST API, removes all matching edges by default due to the two-edge representation of 'always continue', reports a skip if no edge exists, and surfaces ETag/412 stale-write behavior. This is unusually transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Six dense sentences, every one carrying operational information. The core operation is front-loaded; behavior details, warnings, and error handling follow logically. No filler or restatement of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 critical context an agent needs: what the tool does, how it mutates the model, the edge model behind 'always continue', skip behavior, stale-ETag failure, and the inability to activate until the chain is reachable. This is unusually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 interpretation, especially explaining why omitting 'status' removes both the on-success and on-error edges, and clarifying that 'sub_status' selects a DECISION branch. It builds on the schema without replacing it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Remove the dependency (edge) between two existing steps of a Process Chain (RSPC)', a specific verb and resource. It clearly distinguishes this from related tools like bw_remove_process_chain_step and pairs it with bw_add_process_chain_edge, making the tool's scope obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: together with bw_add_process_chain_edge to re-route a mis-wired chain. It also provides situational guidance about edge semantics, activation-preventing unreachable steps, and the behavior when no matching edge exists, giving an agent enough context to choose and invoke it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: full read-modify-write, only changes specified fields, skips transferNotAllowed fields, leaves DataSource inactive, and requires separate activation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise paragraph with no wasted sentences. Front-loaded main action, includes necessary details in logical order. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex domain (SAP BW), the description covers all essential aspects: parameters fully described in schema, behavioral details (read-modify-write, activation requirement), error scenario, and transport handling. No output schema exists, but the description adequately informs what the tool does and its side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, but the tool description adds meaningful context beyond schema: explains the language_field clearing fixes a specific error, clarifies transport requirement for transportable DataSources, and notes that fields with transferNotAllowed are skipped. Adds value without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets transfer flags of DataSource fields and/or the segment language field designation, specifying it is a full read-modify-write operation. It distinguishes from sibling tools like bw_change_datasource_delta or bw_get_datasource by focusing on transfer and language field settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: to change field transfer flags or the segment language field. Includes critical guidance: 'At least one of fields / language_field must be given', 'Fields marked transferNotAllowed are skipped', 'Leaves the DataSource inactive', and explains transport requirement. Also gives a concrete error-fix use case for clearing language_field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the internal mechanism (writes to master, re-saves, activates), constraints (AMDP 7-bit ASCII), and behavior when source is omitted. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being a single paragraph, every sentence adds unique information. No fluff, highly efficient use of words covering purpose, method, and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thoroughly explains the problem, solution, prerequisites, steps, and activation behavior. All 6 parameters are addressed directly or indirectly. No output schema needed given the descriptive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds value by explaining defaults (routine_type, method_name) and clarifying the source block shape. Adds context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool writes code into the transformation master to persist through regeneration. Distinguishes from sibling bw_set_transformation_routine by specifying that the routine must already exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this instead of abap-adt WriteSource, explains why WriteSource fails, and notes that the routine must be created first. Provides clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Thoroughly describes the read-PUT-write mechanism, that edges and other nodes are preserved, and the ETag stale error (412). With no annotations, this fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each serving a clear purpose: purpose, mechanism, usage guidance, activation, error handling. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters, the description covers the tool's behavior, error cases, parameter guidance, and relationship to siblings. Complete for an API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value: explains case-insensitivity for name, default values for activate and refresh_description, and the usage of transport_request for disambiguation. One point off because it's already well-covered in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Swap one DTP load variant for another in an existing Process Chain'. Uses specific verb+resource and explicitly distinguishes from sibling bw_update_process_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends this tool over bw_update_process_chain for single-variant swaps, explains the in-place edit advantage, and describes when to use optional parameters like activate and transport_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it honors that obligation: it states that remove_field also removes the field from the key if applicable, manage_keys replaces the complete list and allows an empty array, update_settings needs no infoobject_name, and adding a field without dimension falls into the catch-all group requiring an extra activation to move later. It also exposes the two-step lock+activate contract, which is a material behavioral side effect not evident from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is front-loaded with a clear action list and each of the six actions is described in 1–2 focused lines. However, the description is verbose and recreates a lot of action detail as prose; it also interleaves related logical consequences (like dimension and activation cost) in a way that requires careful rereading. The length is justifiable for a 6-action tool with nested objects, but it could be tighter by moving purely recursive details such as field-group examples entirely into the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, this definition is not only lists the lock_handle result but also gives the exact sequence of lock_handle return and success. It documents prerequisites (info_objects for add_field, the need for DIM from bw_get_adso, transport requirement conditionality), and all nested parameter structures. For a n-ten-parameter tool with complex nested objects, there are no decision-critical blank spots left.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers 100% of the parameter names, the description adds non-mechanical meaning that is not in the schema: action-specific parameter dependencies, that an infoobject_name can be a comma-separated list, that key_fields=[] clears all keys, that unit_currency_field should be a field reference to a UNIT/CUKY field, and that a missing transport should only be supplied when the BW system requires it. It also explains subtle type behavior such as fixed-length/scale constraints for pure fields, so the agent can correctly compose calls without trying every combination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise operation (updating an aDSO) and immediately breaks it into six specific, mutually exclusive actions, from adding/removing fields to updating settings and key management. This differentiates the tool from the sibling bw_get_adso and bw_create_adso by being the update/alter tool for aDSO resources. No ambiguity remains about what resource the tool operates on or what kinds of changes it can perform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Every action is given its own clear condition and prerequisite: infoobject_name is required for add_field/remove_field, fields array only for add_pure_field, settings only for update_settings, field_name/properties for update_field_properties, and key_fields for manage_keys. The description also explicitly warns about the cost of forgetting dimension (a second activation) and tells the caller to read the current group assignment from bw_get_adso. This gives an agent concrete when-to-use and when-to-omit guidance, plus the required follow-up activation sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and meets it thoroughly: the destructive replacement semantics ('a step left out is deleted'), the stale-ETag 412 behavior with explicit error reporting, preservation of the trigger node and existing event start-condition, the fact that on-error negative links are accepted but not emitted by default, and the support boundary for untested/unsupported step types. No annotation contradicts the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (~700 words), but the structure is exemplary: purpose first, then the core behavioral contract (read → preserve → replace), the safety-critical warning, named alternatives, then step types and edge semantics. Every sentence carries context-dependent information and there is no tautology or filler; it merely approaches the upper limit of what a single description should hold and would benefit from pushing some step-type detail into the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description carries the entire burden of agent-safe invocation. It covers the destructive edge (dropped steps), transport state ($TMP vs transportable), trigger semantics (implicit vs explicit event start), verified vs. unverified generic types, the ETag conflict path, and the full step-type catalog with required fields. Nothing a calling agent needs to decide whether to call, or what to pass, is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds crucial semantics the schema cannot express: the TRIGGER node is implicit and must be omitted from the step list, default edge statuses derive from source node type ('neutral' for TRIGGER/collector, 'positive' otherwise), re-specifying every existing ABAP step is required or it is dropped, 'program_variant' is an SE38 report variant distinct from the DECISION variant field, and transport_request auto-selection rules when exactly one request is available. These details turn a syntactically correct call into a semantically correct one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the operation concretely: 'Replace the step model (nodes and edges) of an existing Process Chain (RSPC)'. The verb 'Replace' plus the resource make the action unmistakable, and the description immediately contrasts with the create flow ('Use bw_create_process_chain to create a new chain; use this tool to update an existing one') and with targeted editing tools, so an agent cannot confuse it with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to and when-not-to guidance. It names the alternative tools for small edits (bw_append_process_chain_dtp, bw_add_process_chain_program, bw_add_process_chain_edge, bw_remove_process_chain_edge, bw_remove_process_chain_step) and explains the deciding factor — those tools 'edit the server's own model in place and cannot drop a step they do not model.' This is textbook usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bw-modeling-mcp MCP server](https://glama.ai/mcp/servers/dnic-dev/bw-modeling-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dnic-dev/bw-modeling-mcp)

Score Badge

Copy to your README.md:

[![bw-modeling-mcp MCP server](https://glama.ai/mcp/servers/dnic-dev/bw-modeling-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dnic-dev/bw-modeling-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dnic-dev/bw-modeling-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server