Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_create_ckf

Create a reusable Calculated Key Figure on an SAP BW/4HANA InfoProvider using a formula tree. Records to a transport when specified, enabling consistent modeling.

Instructions

Create a reusable Calculated Key Figure (CKF) on an InfoProvider. The formula is passed as an operator/operand tree in the same node syntax bw_update_query_key_figures uses for "add_formula", so a tree read back from bw_get_ckf (field formula_tree) can be written again unchanged. Records to a transport when package and transport_request are given, and reports in "recorded_in" where the entry actually landed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formulaYesFormula tree. A node is one of: {"type":"operator","code":"+","operands":[...]} (codes as in the BW formula editor: + - * / , NDIV0, IF, MAX, %A, …); {"type":"component","component_name":"..."} for a reusable CKF/RKF; {"type":"key_figure","name":"..."} for a basic key figure InfoObject; {"type":"constant","value":100}. Operand counts are checked against the operator catalog before anything is written.
packageNoDevelopment package (default "$TMP").
decimalsNoNumber of decimal places (0-9). Server default when omitted.
info_areaNoInfoArea the CKF is filed under.
descriptionYesDescription of the CKF.
provider_nameYesInfoProvider the CKF is defined on (e.g. a CompositeProvider).
technical_nameYesTechnical name of the new CKF.
transport_requestNoTransport request to record the CKF in.
exception_aggregationNoException aggregation of the CKF itself, e.g. { "type": "SUM", "reference_characteristic": "IOBJ_NAME" }. Needed for a weighted average: a helper CKF "unit value * quantity" with SUM over the finest characteristic, divided by the quantity in a second CKF. Without it the product is formed from values already summed up — numerically plausible and wrong. Standard aggregation when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.7.1
    • addedInput schema / properties / exception_aggregation
      Added value: +{
+  "description": "Exception aggregation of the CKF itself, e.g. { \"type\": \"SUM\", \"reference_characteristic\": \"IOBJ_NAME\" }. Needed for a weighted average: a helper CKF \"unit value * quantity\" with SUM over the finest characteristic, divided by the quantity in a second CKF. Without it the product is formed from values already summed up — numerically plausible and wrong. Standard aggregation when omitted.",
+  "properties": {
+    "exclude": {
+      "description": "Aggregate over all characteristics except the reference characteristics. Default false.",
+      "type": "boolean"
+    },
+    "reference_characteristic": {
+      "description": "Reference characteristic the exception aggregation runs over (e.g. \"IOBJ_NAME\").",
+      "type": "string"
+    },
+    "reference_characteristics": {
+      "description": "Several reference characteristics (up to five). Takes precedence over reference_characteristic.",
+      "items": {
+        "type": "string"
+      },
+      "maxItems": 5,
+      "type": "array"
+    },
+    "type": {
+      "description": "Aggregation type: SUM, MAX, MIN, AVG (all values), AV0 (average of non-zero values), AV1 / AV2 (average weighted by calendar / working days), CNT (count all), CN0 (count non-zero), FIR / LAS (first / last value), NO1 / NO2 / NOP (no aggregation if more than one record / value / non-zero value), STD, VAR. Any other literal is refused, because the backend would silently store standard aggregation instead.",
+      "enum": [
+        "SUM",
+        "MAX",
+        "MIN",
+        "AVG",
+        "AV0",
+        "AV1",
+        "AV2",
+        "CNT",
+        "CN0",
+        "FIR",
+        "LAS",
+        "NO1",
+        "NO2",
+        "NOP",
+        "STD",
+        "VAR"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "type"
+  ],
+  "type": "object"
+}
  2. Addedv1.5.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and delivers: it discloses transport recording behavior (records to a transport when package and transport_request are given) and where results land ("recorded_in"). It also conveys round-trip fidelity with bw_get_ckf. It doesn't mention authorization requirements or failure handling, but the key behavioral traits 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.

Conciseness5/5

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

Two tight sentences, front-loaded with the core verb/resource, then the round-trip and transport behavior. No filler; every clause carries information an agent needs.

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 complex nested-schema creation tool with no output schema, the description covers the formula interchange format, transport recording, and the returned "recorded_in" field. Some gaps remain (permissions, validation failure behavior), but the essentials for correct invocation are present.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine cross-parameter semantics: the formula tree is interoperable with the node syntax of bw_update_query_key_figures and reusable from bw_get_ckf's formula_tree field. The transport pairing of package/transport_request is also clarified beyond raw schema text.

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

Purpose5/5

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

States a specific verb+resource (Create a reusable Calculated Key Figure (CKF) on an InfoProvider) and differentiates clearly from siblings like bw_update_ckf and bw_get_ckf by naming the create/read/update roles. An agent can identify this as the creation path without opening the schema.

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

Usage Guidelines4/5

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

Provides clear context: the formula uses the same node syntax as bw_update_query_key_figures, and a tree from bw_get_ckf can be reused unchanged, so round-tripping is supported. It doesn't explicitly state when to choose create vs bw_update_ckf, but the create/read/update sibling distinction is strongly implied.

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