Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_get_aggregation_level

Retrieve the full definition of an SAP BW/4HANA Aggregation Level (TLOGO ALVL) for Integrated Planning. Returns InfoProvider, characteristics, key figures, and metadata.

Instructions

Read an Aggregation Level (TLOGO ALVL) definition — the planning-enabled view on top of an InfoProvider (aDSO or CompositeProvider) used for Integrated Planning / embedded BPC. Returns name, description, status, InfoArea, package, the underlying InfoProvider, and the full element list split into characteristics and key figures. Characteristics include type, length, conversion routine, base InfoObject, compounding, and dimension group. Key figures additionally include aggregation behavior, semantics (AMO/QUA/NUM), and the unit/currency reference (unit characteristic, fixed unit, or fixed currency).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNo"text" (default): readable summary. "raw": the unmodified XML.
aggregation_level_nameYesTechnical name of the Aggregation Level (e.g. "OBJECT_NAME").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.1
    • addedInput schema / properties / format
      Added value: +{
+  "description": "\"text\" (default): readable summary. \"raw\": the unmodified XML.",
+  "enum": [
+    "text",
+    "raw"
+  ],
+  "type": "string"
+}
  2. Addedv0.9.1

TDQS

B3.1/5.0
Behavior2/5

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

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

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

Conciseness4/5

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

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

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

Completeness4/5

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

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

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

Parameters3/5

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

Schema coverage is 100% with only 2 parameters, so the schema already documents both aggregation_level_name (with an example) and the format enum. The description adds no parameter-level detail — it never mentions the 'raw' vs 'text' format choice — so it stays at the baseline 3.

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

Purpose4/5

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

States a specific verb+resource ('Read an Aggregation Level (TLOGO ALVL) definition') and defines the domain concept precisely as the planning-enabled view on top of an InfoProvider, which meaningfully separates it from bw_get_adso and bw_get_composite_provider. It never names those siblings explicitly, so an agent must infer the distinction rather than being routed to the right tool.

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

Usage Guidelines2/5

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

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

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

Deploy Server

Other Tools