mcp-bw-modelling-api

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are mostly distinct by object type (list_* for different resources), but some overlap exists: get_object_details is generic and could conflict with get_infoobject_details, and get_infoarea_contents overlaps with list_* for hierarchical access. Descriptions clarify usage, but a few boundaries are fuzzy.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case (search_, list_, get_, check_). The pattern is uniform across the entire set, with predictable verb choices and plural nouns for list operations.
Tool Count5/5
15 tools is well-scoped for a BW modeling API. Each tool serves a distinct functional need (listing, details, specific operations), and the count feels neither sparse nor overwhelming for the domain.
Completeness3/5
The API covers read-only exploration of major BW objects (InfoAreas, InfoObjects, ADSOs, CompositeProviders, Queries), but lacks listing for transformations (only get_transformation_details) and no list for Open ODS Views. There are no write operations, which may be intentional, but the missing listing for some object types creates notable gaps.
Average 3.2/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'List all objects', but does not mention pagination, the max_results parameter's effect, or any limitations (e.g., whether 'all' is truly all or capped at max_results). Without such detail, the agent cannot anticipate the tool's runtime 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 a single, direct sentence with no filler. It front-loads the core action and scope. However, it is almost too terse—slightly more detail on the result set or usage constraints would improve it without harming conciseness.
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?
An output schema exists, which likely covers return structure, so that gap is mitigated. However, the description does not mention the max_results default or that results may be limited, nor does it hint at any prerequisites (e.g., needing a specific InfoArea technical name). For a listing tool with 2 parameters and no annotations, it is adequate but not comprehensive.
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 both parameters (info_area and max_results) are fully documented in the schema. The description adds no parameter-specific meaning, but since the schema covers them, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('objects within a specific InfoArea'), which conveys the core action. However, it does not explicitly differentiate from sibling tools like list_infoobjects or list_adsos, leaving ambiguity about what 'objects' encompasses and how this differs from related listings.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context where it should be preferred, or situations where a sibling tool would be more appropriate.
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 of behavioral disclosure. It only states 'Search,' implying a read operation, but does not explicitly mention read-only nature, potential limitations (e.g., max_results default), pagination, or any side effects. The description adds no behavioral context beyond the schema's parameter details.
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 a single short sentence, which is concise, but it lacks structure and depth. It conveys the core purpose yet omits crucial context that would be expected in a well-formed description (e.g., which object types are covered, how to use filters). It is efficient but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generic search nature and the many sibling tools for listing specific object types, the description is incomplete. It does not mention that this tool can search across all object types, that object_type filtering is available, or how it relates to the more specific list_* tools. The presence of an output schema doesn't compensate for the lack of usage guidance.
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% — all three parameters have detailed descriptions including valid values, defaults, and wildcard support. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search') and a resource ('BW modeling objects'), and mentions the search criteria ('by name or description'). This is clear but does not differentiate from sibling list_* tools, which list specific object types; it doesn't state that it can search across all types or how it differs from those lists.
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 usage guidance is provided. The description does not indicate when to use this tool versus the many sibling list_* tools (e.g., list_infoareas, list_queries), nor does it mention that object_type can filter results. An agent would have to infer the intended use from the schema.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get detailed properties', implying a read operation, but does not mention permissions, error behavior, or side effects. This is a minimal disclosure that adds little beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is front-loaded and clear, though it could optionally expand on the nature of 'detailed properties' without losing conciseness.
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 get tool with one parameter and an output schema present, the description is adequate but lacks any usage context or differentiation from siblings. It does not mention when to prefer this over related tools, and no behavioral details are given, leaving some gaps for an agent.
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 parameter 'infoobject_name' is fully documented in the schema, including example values. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb 'Get' and resource 'detailed properties of an InfoObject', and specifies the type (characteristic or key figure). It distinguishes from the generic sibling get_object_details by focusing on InfoObjects, though it doesn't enumerate what 'detailed properties' include.
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 is provided on when to use this tool versus alternatives like get_object_details or list_infoobjects. The description does not mention any conditions, exclusions, or context for selection, leaving the agent to infer when this is the appropriate choice.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read operation via 'List', but does not state side effects, permissions, or any constraints such as object version dependencies. The output schema exists, but the description adds no behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the purpose without redundancy. It is appropriately concise, though it could include a hint about how to distinguish itself from similar tools without adding much bulk.
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 presence of an output schema, return values are covered. However, the description does not provide context on when to use this tool versus the many sibling tools, nor does it mention the object_version default behavior beyond what the schema already notes. It is minimally sufficient for calling but lacks context that would aid selection.
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 schema provides 100% coverage with descriptive comments for both parameters (query_name and object_version). The description adds no additional semantic value beyond what the schema already states, so the baseline of 3 applies.
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 action ('List') and the resource ('characteristics and key figures used in a BW Query'), which is specific and distinct from generic object details. It does not explicitly differentiate from sibling tools like get_query_filters or get_object_details, but the focus on structure elements is unambiguous.
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 is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or conditions that would select this tool over its siblings. The agent is left to infer usage from the description alone.
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?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It states 'List' implying a read-only operation, but it does not elaborate on any side effects, pagination behavior, rate limits, or the format of the returned data. The description omits details about whether the operation is safe (read-only) or has any side effects, leaving the agent with minimal information.
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 to the point, consisting of two sentences with no extraneous text. It efficiently states the tool's purpose and provides a brief explanation of ADSOs. The structure is clean and front-loaded with the core action. This is slightly above average because it avoids unnecessary wording while delivering the essential message.
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?
Although an output schema exists (per context signals), which clarifies return values, the description lacks guidance on when to use this tool, and does not mention any filtering capabilities or limitations beyond what the schema outlines. For a listing tool with optional filters, this is adequate but not fully complete, as it does not address usage context or behavioral characteristics that an agent might need to make an informed decision.
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 provides 100% coverage for all three parameters: info_area, max_results, and search_term, each with clear descriptions. The tool description does not add any parameter-specific semantics beyond what the schema already provides. Per the baseline, a score of 3 is appropriate when the schema is fully descriptive and the description doesn't compensate further.
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 that the tool lists ADSOs in the BW system, with a specific verb and resource. It also provides a brief definition of ADSOs, which adds context. However, it does not explicitly differentiate this tool from sibling tools like search_bw_objects or list_composite_providers, though its specificity to ADSOs does distinguish it implicitly.
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 does not provide any guidance on when to use this tool versus the alternatives. It only mentions that ADSOs are primary data storage objects, which is background information but does not explain when an agent should choose list_adsos over search_bw_objects or list_infoareas. No exclusions or alternative conditions are given.
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 of behavioral disclosure, yet it reveals nothing about behavior: no read-only hint, no pagination behavior (max_results hints at limits but is not explained), no error/empty-result behavior, no performance caveats. Since this is a safe listing operation, a minimal read-only note would substantially improve it.
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 the core purpose front-loaded, followed by a single clarifying clause. There is no filler or repetition; every sentence earns its place.
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?
The output schema exists, so return values need no explanation, and all parameters are schema-documented. The gaps are a missing behavioral note (no safe-read disclosure, given zero annotations) and no routing guidance against search_bw_objects or the other list_* siblings. For a listing tool of moderate complexity, this is adequate but leaves the sibling-differentiation question open.
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 fully documents all four parameters — the baseline of 3 applies. The description adds only conceptual grounding (queries sit on CompositeProviders/ADSOs) which helps interpret the info_provider filter, but it does not add syntax or format details beyond the schema's own parameter 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 states a specific verb and resource ('List BEx/BW Queries in the system') and adds domain context ('Queries are reporting definitions built on top of CompositeProviders or ADSOs') that clarifies what queries are. It's clear, though it doesn't explicitly distinguish itself from sibling search_bw_objects, which could conceivably also surface queries.
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 main description offers no when-to-use or when-not-to-use guidance relative to siblings such as search_bw_objects or list_composite_providers. The only usage hint is buried inside the info_provider parameter description ('This is the recommended way to list the queries built on a specific provider'), which is not front-loaded and does not address the broader routing question.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does, and gives no hints about potential errors, permission requirements, or side effects. For a getter, it likely performs a read, but this is not stated.
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 exactly one sentence with zero filler. Purpose is front-loaded and clear, making it highly efficient for an agent to parse quickly.
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?
The presence of an output schema covers return values, and the input schema covers the parameter. However, the description lacks any behavioral or usage context, and the absence of annotations underscores that this is a minimal description. Still, for a simple getter tool, it is arguably adequate, hence a mid-level score.
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 parameter is fully documented in the input schema. The description adds no additional semantic context, but the baseline of 3 is appropriate since the schema already handles parameter documentation.
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 verb 'get' and the resource 'part providers (data sources) of a CompositeProvider'. It is specific enough to distinguish from siblings like get_object_details, though it does not explicitly reference any alternative or contrast.
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 is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or exclusions. An agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. The description only states it 'gets' metadata, implying a read operation, but it does not explicitly confirm read-only behavior, whether it requires special permissions, or what 'detailed metadata' includes. No side effects or constraints are mentioned. Given zero annotation support, this is a significant gap for an agent relying on the description alone.
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, focused sentence with no filler. It conveys the essential action and target immediately. It is appropriately short and front-loaded, earning a top score for conciseness.
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?
An output schema exists, so return values are covered elsewhere. However, the description omits any mention of which object types are supported or how this differs from sibling getters, which is relevant given the large sibling set. The minimalism might be acceptable for a simple getter, but the lack of guidance on when to choose this over specialized tools makes it incomplete for effective selection.
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 both parameters and even lists the valid object_type codes. The description adds no additional semantic depth beyond what is in the schema. Per the guidelines, baseline is 3 when schema coverage is high, and the description does not meaningfully enhance parameter understanding.
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 action ('Get detailed metadata') and resource ('a specific BW object'). It is distinct from the siblings in that it is a generic getter, but it doesn't explicitly name any alternative or what makes it different from the more specialized getters like get_infoobject_details. It distinguishes by being general, which is clear enough for an agent to understand its primary scope.
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 is provided on when to use this tool versus the specialized sibling tools (e.g., get_infoobject_details, get_transformation_details). The description does not mention selection criteria or situations where this generic getter is preferred. The agent is left to infer from the schema that it handles multiple object types, but the description offers no explicit routing or exclusions.
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 of behavioral disclosure. It does not mention any filtering, pagination, return format, or performance characteristics. It only states the action and definition of InfoObjects, leaving out operational behavior such as whether it sorts results, how max_results is applied, or what happens when search_term is empty.
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 with no unnecessary words. The action verb is front-loaded, and the second sentence adds concise, relevant context about what InfoObjects are. Every sentence earns its place, and the structure is easy to scan quickly.
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 list tool with an output schema, the description is minimally adequate. It does not explain return values (covered by output schema) and parameters are covered by the schema. However, it lacks any usage context or differentiation from sibling tools, and with no annotations, it misses an opportunity to contextualize the tool's role in the BW system. It is complete enough for a basic call but not for informed selection among similar tools.
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 schema description coverage is 100%, so all three parameters (info_area, max_results, search_term) are already documented with their purposes and defaults. The description adds no additional meaning or clarifications beyond what the schema provides. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 states 'List InfoObjects in the BW system' with a specific verb and resource, and explains what InfoObjects are. It is clear and unambiguous, though it does not explicitly differentiate from sibling tools like search_bw_objects or list_infoareas. The purpose is easily understood without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as search_bw_objects or list_infoareas. It does not mention exclusions, prerequisites, or typical scenarios. An agent would have to infer usage from the name alone, which is insufficient given the context of many similar list/detail siblings.
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?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but doesn't state whether any modification occurs, whether special permissions are required, or what happens on error. No side effects or limitations are mentioned.
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 concise sentence that identifies the action and the object. It is front-loaded and contains no clutter, making it easy to parse quickly.
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 simplicity (one parameter, fully documented in schema) and the existence of an output schema, the description is sufficient for an agent to call it correctly. It tells what the tool does and the parameter is clear, so no critical information is missing.
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 fully describes the single parameter (object_name) with an example, giving 100% coverage. The description adds no additional semantic information beyond the schema, so it doesn't enhance parameter understanding.
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 states a clear verb ('Get') and target ('field list (InfoObjects) of an Advanced DataStore Object'), which distinguishes it as a retrieval operation for ADSO fields. It is not tautological and identifies a specific resource type, though it doesn't explicitly differentiate from similar list tools like list_infoobjects or get_object_details.
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 provides no guidance on when to use this tool versus alternative tools such as list_infoobjects or get_object_details. It only states what it does, leaving it to the agent to infer the appropriate context.
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?
With no annotations, the description must carry the full burden of disclosing behavioral traits. It uses the verb 'get' implying a read-only operation, but it does not explicitly state that it is safe, non-mutating, or what permissions are required. It also omits any mention of pagination, empty results, 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?
The description is a single, well-structured sentence that leads with the action and object, followed by the key metadata types. There is no fluff, and it is appropriately brief for a tool with one parameter.
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 getter with one parameter and an output schema, the description is functionally adequate. However, it could clarify how this differs from get_object_details and whether the transformation must be of a specific type, and it doesn't mention if the metadata is always available. These are minor gaps for a low-complexity 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%, and the schema already documents the transformation_id parameter with an example. The tool description adds no additional meaning about the parameter beyond what the schema provides, so it meets the baseline for high coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('get'), the resource ('transformation'), and the specific kind of information ('detailed metadata including source, target, and rule information'). This distinguishes it from sibling tools that target other object types such as infoobjects or queries, and it is not a tautology.
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 provides no guidance on when to use this tool over alternatives like get_object_details or list_queries. It does not mention any prerequisites, exclusions, or conditions that would help an agent decide between this and similar getters.
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 of behavioral disclosure. It only adds domain context (what HCPRs are) but does not disclose behavior such as result limits, pagination, ordering, whether it performs a read-only scan, or response characteristics. Listing implies non-destructiveness, but the description relies on that inference rather than stating it.
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. The core purpose is front-loaded, and the second sentence adds a genuinely useful definition of the domain concept rather than filler. Every sentence 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?
An output schema exists, so return values need not be explained, and all parameters are documented in the schema. The description covers the domain concept and resource type. The main gaps are routing guidance versus siblings and explicit behavioral disclosure, which are minor for a straightforward list 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 the schema already documents all three parameters (info_area, max_results, search_term) with defaults and wildcard semantics. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') + resource ('CompositeProviders / HCPRs') + system ('BW'), and the second sentence explains what an HCPR is. This clearly distinguishes it from sibling list tools like list_adsos, list_infoobjects, and list_queries without needing to open their schemas.
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 purpose, but there is no explicit routing guidance. The description does not mention alternatives such as search_bw_objects or list_infoarea_contents, nor does it state when this tool should NOT be used. Adequate for a self-explanatory list tool, but no exclusions or when/when-not conditions are provided.
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 of behavioral disclosure. While it implies a read-only list operation, it does not disclose that the 'all' claim is subject to max_results (default 500), nor does it mention any pagination, ordering, or cost implications. This is a notable gap given the tool may not actually return all results.
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: two sentences that front-load the action and provide a brief context for InfoAreas. Every sentence earns its place, with no fluff or 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 the low complexity (one optional parameter) and the existence of an output schema (which covers return structure), the description is largely complete for calling it correctly. It misses explicit usage guidance (e.g., when to prefer this over search), but that is already penalized in usage_guidelines. For a simple list tool, the essential information is present.
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 single parameter max_results is fully documented in the schema (description and default value), giving schema coverage of 100%. The description adds no further meaning about the parameter's behavior, such as how it affects the result set. Therefore, the baseline of 3 applies—the schema already handles parameter semantics 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 clearly states the action ('List all InfoAreas') with a specific resource ('InfoAreas in the BW system'). It also explains what InfoAreas are, making the purpose unambiguous and distinct from sibling tools like list_infoobjects or get_infoarea_contents.
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 usage is implied: if you need a list of all InfoAreas, use this tool. However, it does not explicitly contrast it with alternatives like search_bw_objects or get_infoarea_contents, so there is no direct exclusion or guidance on when not to use it. This is acceptable but not explicit.
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 of behavioral disclosure. It communicates the read-only nature by stating 'Read' and 'Retrieves', and it explains the semantics of each filter type (Fixed Filter, Default Value, combination) and that they are derived from usageType. It also gives concrete examples (e.g., 0FISCVARNT = V5). However, it does not mention potential edge cases, error conditions, or authentication requirements, but for a read operation these are less critical. It provides solid transparency 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 well-structured and front-loaded with the primary action. It uses bullet points for the filter types, which improves readability and comprehension. Every sentence contributes value, though it is slightly verbose with examples. It is appropriately sized for the complexity of the tool and avoids fluff.
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 moderate complexity and the presence of an output schema, the description provides sufficient context about what the tool returns (filter types and their meanings). It explains the three filter categories with examples, which is essential for the agent to interpret results correctly. It does not cover all possible scenarios (e.g., no filters, invalid query name), but for a read-only retrieval tool this level of completeness 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?
The input schema already provides full descriptions for both parameters (query_name and object_version), including an example and the default value. The description adds no extra parameter-specific information—it only explains the overall tool behavior. With 100% schema coverage, the baseline is 3, and the description does not need to duplicate or extend parameter documentation. Thus, a 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 filter restrictions from a BW Query, identifying the specific resource (query filters) and the action (read/extract). It details what it returns (fixed values and variable references) and distinguishes between filter types, making its purpose unambiguous and differentiated from siblings that handle other aspects of 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 implies usage (if you need to know the global filter restrictions on a query, use this tool) but does not explicitly mention alternatives or when not to use it. There is no comparison to sibling tools like get_query_structure or list_queries, nor any exclusion criteria. The context is clear from the content, but no explicit 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 are provided, so the description carries the burden of behavioral disclosure. It states the return value (connection status, system info, or error details), implying a read-only, non-destructive action. However, it does not explicitly mention side effects, potential risks, or network dependencies beyond the system info. For a simple test tool this is adequate but not enriched.
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 exceptionally concise: two short sentences, front-loaded with the core action and immediately followed by the return type. No wasted words or 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 an output schema exists, the description does not need to detail the return structure further. The purpose and outcome are both covered. The only missing element is an explicit note on when to invoke this tool (e.g., before other operations), but for a zero-parameter health check, the description is minimally 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?
The tool has zero parameters, so parameter semantics are trivial. The schema coverage is 100% (empty schema), and the description correctly omits parameter details. Per the baseline, a zero-parameter tool earns 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 a specific verb ('Test') and a specific resource ('connection to the BW system'). It distinguishes itself from sibling tools, which are all search or retrieval operations, by its connection-checking purpose. No ambiguity about what it does.
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 implies usage as a connectivity probe ('Test the connection'), but does not explicitly state when to use it versus alternatives or when not to use it. Since no sibling tool serves a similar purpose, the context is clear, but explicit guidance is absent. This is a minor gap.
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:

[![mcp-bw-modelling-api MCP server](https://glama.ai/mcp/servers/felipetomazzi-source/mcp-bw-modelling-api/badges/card.svg)](https://glama.ai/mcp/servers/felipetomazzi-source/mcp-bw-modelling-api)

Score Badge

Copy to your README.md:

[![mcp-bw-modelling-api MCP server](https://glama.ai/mcp/servers/felipetomazzi-source/mcp-bw-modelling-api/badges/score.svg)](https://glama.ai/mcp/servers/felipetomazzi-source/mcp-bw-modelling-api)

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/felipetomazzi-source/mcp-bw-modelling-api'

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