bw-modeling-mcp

bw_write_planning

Create or modify SAP BW planning objects—aggregation levels, functions, sequences, filters, and currency/unit conversion types—to define and adjust planning logic.

Instructions

Create or change planning objects: aggregation levels, planning functions, sequences, filters, conversion types. The operation enum lists every operation with what it requires; bw_describe(tool: "bw_write_planning", operation: "…") gives the complete parameter definition of one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation": "<operation>"
    },
    "name": "bw_write_planning"
  }
}

Input Schema

Name	Required	Description
`kind`	No	currency translation or unit conversion. [create_conversion_type]
`name`	No	Technical name of the new conversion type (e.g. [create_conversion_type]
`rule`	No	For function types with several rules: the 1-based rule that conditions and parameters apply to. Defaults to 1. [create_function, update_function]
`time`	No	Currency: the time reference of the rate. [create_conversion_type]
`label`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [create_aggregation_level, create_function]
`steps`	No	The steps in execution order. Full definition: bw_describe(tool: "bw_write_planning", operation: "create_sequence"). [create_sequence, update_sequence]
`action`	No	Defaults to "add_fields". [update_aggregation_level]
`fields`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [create_aggregation_level, update_aggregation_level]
`source`	No	Source currency or unit. [create_conversion_type]
`target`	No	Target currency or unit. [create_conversion_type]
`factors`	No	Unit: where the conversion factors come from, in order (default T006). [create_conversion_type]
`inverse`	No	Currency: use the inverse rate. [create_conversion_type]
`package`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [5 of 9 operations]
`info_area`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [create_aggregation_level, create_function, create_sequence]
`operation`	Yes	Operation — one of: create_aggregation_level: Create a new Aggregation Level (TLOGO ALVL) on top of a planning-enabled InfoProvider (aDSO or CompositeProvider), for Integrated Planning / embedded BPC. Requires aggregation_level_name, label, info_area, info_provider. \| update_aggregation_level: Add fields to or remove fields from an existing Aggregation Level (TLOGO ALVL). Requires aggregation_level_name, fields. \| create_function: Create a Planning Function (TLOGO PLSE) of a given function type on an aggregation level. Requires planning_function_name, label, aggregation_level, function_type. \| update_function: Change an existing Planning Function (TLOGO PLSE): the characteristic usage (FIELDS_TO_BE_CHANGED / FIELD_FOR_CONDITIONS / NONE), the conditions, single-value… Requires planning_function_name. \| create_sequence: Create a planning sequence with its steps in execution order: planning functions, each with the filter that selects its data, and input templates. Requires sequence_name, description, steps. \| update_sequence: Change a planning sequence: replace its steps with the list given, in that order, and/or change its description. Requires sequence_name. \| create_filter: Create a planning filter on an aggregation level — the selection a planning sequence step or an input template works on — with its restrictions in the same cal… Requires filter_name, aggregation_level, description. \| update_filter: Change a planning filter: set the values or the variable of a characteristic (replacing its current restriction), remove a restriction, or change the descripti… Requires filter_name. \| create_conversion_type: Create a currency translation type (kind "currency", TLOGO CTRT) or a unit conversion type (kind "unit", TLOGO UOMT), saved straight to the active version — th… Requires kind, name, description.
`rate_type`	No	Currency: exchange rate type (e.g. [create_conversion_type]
`transport`	No	Transport request number. Required on systems with transport obligation.
`char_usage`	No	Characteristic usage per characteristic. Full definition: bw_describe(tool: "bw_write_planning", operation: "create_function"). [create_function, update_function]
`conditions`	No	Conditions of the rule, per characteristic. Full definition: bw_describe(tool: "bw_write_planning", operation: "create_function"). [create_function, update_function]
`operations`	No	Restrictions to set or remove, applied in order. Full definition: bw_describe(tool: "bw_write_planning", operation: "create_filter"). [create_filter, update_filter]
`parameters`	No	Parameter values of the rule, as shown in the parameter tree of bw_get_planning_function. Full definition: bw_describe(tool: "bw_write_planning", operation: "create_function"). [create_function, update_function]
`description`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [6 of 9 operations]
`filter_name`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [create_filter, update_filter]
`function_type`	No	Planning function type (e.g. [create_function]
`info_provider`	No	Technical name of the underlying planning-enabled InfoProvider — an aDSO or a CompositeProvider (e.g. [create_aggregation_level]
`rate_specific`	No	Currency: which rate of the rate type to use (default No). [create_conversion_type]
`sequence_name`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [create_sequence, update_sequence]
`via_fi_modules`	No	Currency: translate through the FI modules (default true). [create_conversion_type]
`aggregation_level`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [create_function, create_filter]
`factors_infoobject`	No	Unit: the InfoObject with its own conversion factors, for the InfoObject-based modes. [create_conversion_type]
`rate_type_variable`	No	Currency: variable that supplies the exchange rate type, instead of rate_type. [create_conversion_type]
`aggregation_level_name`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [create_aggregation_level, update_aggregation_level]
`in_transformation_only`	No	Currency: offered in transformations only. [create_conversion_type]
`planning_function_name`	No	Defined per operation — bw_describe(tool: "bw_write_planning", operation: "…") gives each definition. [create_function, update_function]
`exchange_rate_infoobject`	No	Currency: InfoObject that supplies the exchange rate; omit for the rate from the rate tables. [create_conversion_type]
`allow_initial_source_value`	No	Unit: allow an initial source unit. [create_conversion_type]
`no_conversion_if_factors_not_found`	No	Unit: leave the value unconverted when no factor is found. [create_conversion_type]

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Nov 12, 2026

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden, and it does not state that this mutates persisted planning objects directly, whether changes are reversible, what permissions or transport obligations apply, or whether a created object is still inactive. The only behavioral hint ('saved straight to the active version') lives in the schema's operation enum rather than the description.

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

Conciseness5/5

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

Two sentences, zero filler, front-loaded with the scope and then the disambiguation mechanism. Nothing repeats the schema or the title.

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 37-parameter polymorphic mutation tool with nested objects and no annotations or output schema, deferring detail to the enum and bw_describe is a reasonable strategy and keeps the definition small. However, it omits anything about the result of an operation and the follow-up activation step implied by the sibling bw_activate, which an agent needs to complete a create workflow.

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

Parameters4/5

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

Schema description coverage is 100% and the operation enum already spells out per-operation requirements, so the baseline is 3. The description earns one step above baseline by telling the agent that per-operation parameter definitions are obtainable via bw_describe, which is genuinely useful routing for a 37-parameter tool whose fields are polymorphic by operation.

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

Purpose5/5

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

States a specific verb pair (create or change) and a specific resource class (planning objects), then enumerates the covered object types: aggregation levels, planning functions, sequences, filters, conversion types. That enumeration cleanly separates it from siblings such as bw_write_adso, bw_write_query, or bw_write_transformation without needing to name them.

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

Usage Guidelines4/5

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

Gives clear routing guidance: pick the operation from the enum, which states what each operation requires, and call bw_describe for a single operation's full parameter definition. It stops short of explicit exclusions (e.g. that deletion belongs to bw_delete, or that creation may need a follow-up activation), so the agent must infer the boundary.

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