Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_update_planning_function

Updates an existing SAP BW Planning Function by changing characteristic usage, conditions, parameter values, or description and saves directly to the active version.

Instructions

Change an existing Planning Function (TLOGO PLSE): the characteristic usage (FIELDS_TO_BE_CHANGED / FIELD_FOR_CONDITIONS / NONE), the conditions, single-value parameter values (constant or variable, including the FOX code of a FORMULA function) and the description. Changes not passed stay as they are. The function is saved straight to the active version — there is no activation step. Before changing the code of a custom exit function, check the block characteristics with bw_get_planning_function: records meant to be combined in one call must not differ in any of them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ruleNoFor function types with several rules: the 1-based rule that conditions and parameters apply to. Defaults to 1.
transportNoTransport request number. Required on systems with transport obligation.
char_usageNoCharacteristic usage per characteristic. FIELDS_TO_BE_CHANGED: the function may change its values, and records that differ in it are processed together. FIELD_FOR_CONDITIONS: not changed, but conditions may restrict it. NONE: neither. Every characteristic that is not FIELDS_TO_BE_CHANGED is a block characteristic — the function runs once per combination of their values. On a CompositeProvider the bare characteristic name is accepted as well as the prefixed one.
conditionsNoConditions of the rule, per characteristic. The given constraints replace every constraint the characteristic has; an empty or omitted constraints list removes the condition. A condition is only valid on a characteristic with usage FIELD_FOR_CONDITIONS.
parametersNoParameter values of the rule, as shown in the parameter tree of bw_get_planning_function. Applies to single-value parameters; a nested one may be named by its path ("STRUCTURE/FIELD") or, where unambiguous, by its own name. Pass value for a constant or variable for a variable reference. The FOX code of a FORMULA function is the value of its FLINE parameter. A key figure selection (e.g. KYFSEL) takes key_figures, a data selection (e.g. the from and to selections of a copy) takes selection. In a table parameter row n of every field belongs together; row = current rows + 1 adds a row.
descriptionNoNew description.
planning_function_nameYesTechnical name of the Planning Function (e.g. "OBJECT_NAME").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses partial-update semantics ('Changes not passed stay as they are') and the non-obvious fact that the function is written straight to the active version with no activation step. It omits reversibility, permission requirements, and error behavior, keeping it from a 5.

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?

Front-loaded with the verb and the enumeration of changeable facets, followed by the update semantics and the prerequisite warning. Every sentence carries information, though the parenthetical lists make it dense; it is well organized rather than bloated.

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 annotations and no output schema, it covers the essentials: what changes, that changes are additive, that there is no activation step, and one safety prerequisite. It leaves permission/transport-obligation behavior and failure modes unexplained, so 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%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it maps the four changeable areas to the parameter set, clarifies that unpassed changes are preserved, and explains the block-characteristic interaction that governs how records are grouped across a call.

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 ('Change') and resource ('an existing Planning Function (TLOGO PLSE)'), then enumerates exactly which facets can be changed (characteristic usage, conditions, parameter values, description). It is trivially distinguishable from bw_create_planning_function and bw_get_planning_function without opening either 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?

Gives clear usage context: unmentioned fields are left untouched (partial update), and it names a prerequisite — check block characteristics via bw_get_planning_function before editing custom exit code. It stops short of explicit when-not or a named alternative for other update paths, so not a full 5.

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