bw-modeling-mcp

Server Quality Checklist

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

Latest release: v1.2.1
Disambiguation5/5
Each tool targets a specific BW object and operation, with clear descriptions that distinguish purposes. Only minor overlap between bw_get_dtps and bw_xref is clarified by descriptions, ensuring no ambiguity.
Naming Consistency5/5
All tools follow a consistent 'bw_verb_noun' pattern using lowercase and underscores. The verbs and nouns are predictably used across the set, with no mixing of conventions.
Tool Count4/5
At 50 tools, the set is comprehensive for the complex BW modeling domain. While high, each tool serves a distinct purpose and contributes to covering the necessary operations.
Completeness3/5
Full CRUD is provided for core objects like aDSO, DTP, InfoObject, InfoSource, and Transformation. However, important objects such as queries, composite providers, process chains, datasources, and source systems lack creation/modification tools, leaving notable gaps.
Average 4.2/5 across 50 of 50 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 13 of 14 community issues answered or closed in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on August 4, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It fails to mention side effects, overwriting behavior, permissions, or error conditions, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no fluff, front-loaded with purpose and usage. 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?
While the description covers core purpose and usage, it lacks details on effect (e.g., overwrite behavior), error handling, and return value, which is important given no output schema and no annotations.
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 parameters. The description adds minimal value beyond the schema, only echoing the 'plain text' detail and global_code optionality.
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 an ABAP filter routine on a DTP filter field, and distinguishes itself from simple value filters, making the specific verb and resource clear.
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 on when to use ('only when custom ABAP code is needed') and when not ('not for simple value filters'), though it does not name alternative tools for simple filters.
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?
Discloses automatic unlock behavior (except DTP/DataSource) and that response lists deactivated DTPs requiring re-activation. Since no annotations are provided, this description carries the full burden and covers important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and is concise given the complexity. It could be slightly shorter, but every sentence adds necessary detail 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?
Covers prerequisites, special cases, response content, and object types. No output schema is provided, so the description of the response (deactivated DTPs) helps fill the gap. Parameter and usage details are comprehensive.
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?
All 5 parameters are described in the schema (100% coverage). The description adds value by explaining lock_handle usage (source and empty string condition) and source_system requirement for rsds, going beyond schema definitions.
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 activates one BW object and lists supported object types. It distinguishes from siblings like bw_activate_process_chain implicitly, but does not explicitly contrast, leaving some ambiguity.
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 prerequisites (lock_handle from update tools) and special case handling (empty lock for DTP/DataSource). However, it does not explicitly state when to use this tool versus sibling activation tools (e.g., bw_activate_process_chain).
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.
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 delta-init implications for extraction mode switches but omits details on whether the update is incremental or full, error conditions, or prerequisites like object locking. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main actions and uses two sentences plus a concise note. It is efficient without being overly terse; the note is placed appropriately.
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 10 parameters, no output schema, and no annotations, the description is relatively brief. It covers the core purpose and a key behavioral note but lacks details on return values, synchronous/asynchronous behavior, or error scenarios. Acceptable but could be more 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 filter use case and extraction mode implications. It does not add additional meaning for all parameters (e.g., transport_lock_holder), but the added context warrants 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 states it updates DTP properties (description, filter, extraction mode) and specifies the use case 'setting filter values on existing filter fields'. It distinguishes from sibling tools like bw_create_dtp and bw_get_dtp.
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: 'Use this for setting filter values on existing filter fields' and notes extraction mode implications. It doesn't explicitly exclude other use cases or compare with alternatives like bw_set_dtp_filter_routine, but the context is sufficient.
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 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?
Describes the tool's behavior: releasing a lock, discarding changes, no activation. Specific DTP lock behavior mentioned (SM12: RSBKDTP). Without annotations, this is sufficient; could note that unsaved changes are lost, but 'discard changes' implies this.
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: first states core purpose, second provides critical DTP-specific nuance. No wasted words, front-loaded.
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 tool with 2 parameters, no output schema, and no nested objects, the description covers the behavior, use case, and special cases (DTP lock). 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 does not add further semantic meaning 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?
Clearly states the action (release a lock without activating), the resource (BW object), and provides a typical use case (after aborted create/update). Distinguishes from siblings like bw_activate and bw_delete.
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 (to discard changes and free a lock) and gives a concrete example (aborted create/update). Also provides DTP-specific detail. Does not explicitly state when not to use, but context is clear for a simple operation.
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, 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.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Comprehensively details ETag handling, trigger preservation, optional overrides, activation behavior, error 412 meaning, supported step types, edge conditions, and DECISION branch specifics.
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 relatively long but well-structured and front-loaded with purpose. Every sentence contributes meaningful information; slight verbosity is justified by tool complexity.
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?
Comprehensive for a complex tool with 8 params and nested objects. No output schema, but description mentions 412 error. Could explicitly describe success response, but overall covers most behavioral aspects.
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 good descriptions. Description adds context beyond schema (e.g., implicit TRIGGER node, default statuses, preservation behavior). Not all parameters get extra nuance, but overall 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?
Description clearly states it replaces the step model of an existing Process Chain via REST API. Distinguishes from sibling tool bw_create_process_chain explicitly.
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 indicates when to use this tool (update existing chain) and when to use the sibling (create new chain). Also mentions unsupported process types, but does not provide alternatives for those cases.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses important behaviors: the TRIGGER node is implicit (index 0), edge status defaults, collectors require no extra fields, and supported step types. It also mentions what is not supported and prerequisites. However, it does not describe return values or error handling, which is a minor gap given the lack of an output 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 long but dense with necessary information. It is front-loaded with the main action and then provides details on step types, edges, and prerequisites. While it could be more structured, every sentence adds value for a complex tool with many parameters and nested objects.
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 (7 parameters, 5 required, nested objects) and 100% schema coverage, the description is remarkably complete. It covers step type definitions, edge defaults, the implicit TRIGGER, prerequisites, unsupported types, and event-based triggers. The agent has sufficient information to construct the process chain 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 beyond the schema by explaining the implicit TRIGGER, edge default rules, step type requirements (e.g., collectors need no extra fields), and prerequisites like creating DTPs and decision variants first. These details help the agent construct valid 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: 'Create a Process Chain (RSPC) via the BW/4HANA Cockpit REST API.' It details the construction from steps and edges, and activation option. It differentiates from siblings like bw_create_dtp and bw_activate_process_chain by explaining that DTPs must be created first and that this tool builds the chain around them.
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 explicit guidance on when to use this tool versus alternatives. It states 'For two-step DTP loading always use bw_create_dtp first; this tool builds the process chain around existing DTPs.' It also advises creating decision variants with bw_create_decision_variant before use. It notes unsupported types and untested paths, giving clear when-not 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 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.
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 fully discloses behavioral traits: in-place edit (read, modify, PUT), idempotency (skip if DTP exists), ETag handling (412 error explanation), optional activation/verification. 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 a single dense paragraph; it contains all necessary information but could be more scannable (e.g., bullet points). Still, it is front-loaded with the core action and is 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 the complexity (7 parameters, many optional) and no output schema, the description covers all essential aspects: mechanism, defaults, idempotency, error handling, and optional behaviors. No gaps.
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 meaning: explains default predecessor behavior, adsoact adds a step, activate includes verification, edge_mode options, and transport request handling. This goes beyond the schema's attribute 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 appends a DTP load step to an existing Process Chain, specifying the verb, resource, and mechanism (in-place edit via REST API). It distinguishes the tool from siblings like bw_swap_process_chain_dtp and bw_add_process_chain_program.
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 default behavior (append behind strand end closest to trigger), how to use predecessor, edge_mode options, and idempotency. It does not explicitly state when not to use the tool or compare to alternatives, 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 are present, so the description carries the full burden. It discloses key behaviors: server-generated name, automatic activation, filter restrictions (Equal operator only, one field), two-step chain logic, and IOBJ sub-object handling. It omits authorization requirements or whether it overwrites existing DTPs, but the level of detail is high.
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 but well-structured, starting with the core action, then detailing parameters and special cases, and ending with important warnings. Every sentence adds value, though a more bulleted format could improve scannability.
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 (13 parameters, no output schema), the description is thorough. It covers prerequisites, parameter interdependencies, special cases (two-step chain, RSDS, IOBJ), and an explicit error warning. No essential information 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?
Schema description coverage is 100%, yet the description adds substantial meaning beyond the schema: explains auto-generation of DTP name, the Equal-only filter constraint, the two-step chain parameter interplay, and the RSDS compound key construction. This provides vital context for correct 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 it creates and activates a DTP for a transformation, specifying the resource and action. It differentiates from siblings like bw_get_dtp, bw_run_dtp, and bw_update_dtp by detailing creation-specific constraints and prerequisites.
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 explicit guidance: check transformation chain before use, distinguish single-step vs two-step, warn about omitting trfn_name_2 causing errors, and recommend using bw_get_transformation or bw_xref. It also covers DataSource source with RSDS and the need for source_system. This is comprehensive 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?
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?
No annotations exist, so description carries full burden. It discloses that updates require a lock_handle and a specific activation sequence, describes the effect of remove_field on key fields, and notes transport requirements. This is comprehensive.
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 action bullets and a sequence outline. It is somewhat lengthy but necessary for the tool's complexity. Could be slightly more concise by avoiding redundancy with schema descriptions.
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 9 parameters, nested objects, and no output schema, the description fully covers all actions, explains the lock_handle and activation chain, mentions transport, and provides examples in parameter descriptions. Very 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 coverage is 100%, but description adds significant meaning: explains defaults, constraints (e.g., pattern for UNIT, date fields), and action-specific parameter usage (e.g., key_fields for manage_keys). This goes 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?
The description clearly states the tool modifies aDSO by listing multiple actions: add/remove fields, change type/settings, manage keys, update field properties. It distinguishes from sibling tools like bw_create_adso (creation) and bw_get_adso (reading).
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?
Each action is explained with its purpose and required parameters (e.g., add_field requires infoobject_name). The activation sequence is provided. However, it doesn't explicitly state when NOT to use this tool or mention alternatives for similar 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?
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 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?
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.

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