bw-modeling-mcp

bw_update_infoobject

Update SAP BW InfoObject details such as description, lower case flag, attribute list, and key figure units or currencies, with locking, activation, and unlocking handled in one call.

Instructions

Update a Characteristic InfoObject: change description, the lower case flag, and/or replace the attribute list. Supplying attributes replaces all existing ones (pass an empty array to remove all); omitting them leaves the list untouched. Also supports Key Figure (KYF) updates: set fixed_unit or fixed_currency, or unit_currency_infoobject to take the unit/currency from a unit characteristic. Sequence: lock → GET → PUT → activate → unlock — all in one call.

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": {
      "name": "<name>"
    },
    "name": "bw_update_infoobject"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	InfoObject name (e.g. "IOBJ_NAME").
`transport`	No	Workbench transport order number (e.g. "DEVK900000"). Required when object is in a non-local package.
`attributes`	No	New attribute list, replacing all existing ones. Pass [] to remove all attributes; omit to leave them unchanged.
`fixed_unit`	No	KYF only. Fixed unit of measure (e.g. "KWH", "M3"). Sets fixedUnit on a QUAN key figure.
`lower_case`	No	CHA only. Allow lower case letters (RSDCHABAS-LOWERCASE). Omit to keep existing. Set true for characteristics whose values may contain lower case letters or characters outside the permitted character set (RSKC), such as umlauts. Changing the flag on a characteristic already used by a provider that holds data is accepted; a load that failed activation on such a value can then simply be activated again.
`description`	No	New short and long description text. Omit to keep existing.
`fixed_currency`	No	KYF only. Fixed currency (e.g. "EUR"). Sets fixedCurrency on a CURR key figure.
`unit_currency_infoobject`	No	KYF only. Unit characteristic that supplies the unit or currency per record (e.g. "0CURRENCY", "0UNIT"). Replaces a fixed unit/currency; excludes fixed_unit/fixed_currency.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.10.0Nov 10, 2026

addedInput schema / properties / unit_currency_infoobject

Added value: +{
+  "description": "KYF only. Unit characteristic that supplies the unit or currency per record (e.g. \"0CURRENCY\", \"0UNIT\"). Replaces a fixed unit/currency; excludes fixed_unit/fixed_currency.",
+  "type": "string"
+}

Changed2 schema fields changedv1.5.0Sep 19, 2026

changedInput schema / properties / attributes / description

Previous value: -"New attribute list. Omit or pass [] to remove all attributes."New value: +"New attribute list, replacing all existing ones. Pass [] to remove all attributes; omit to leave them unchanged."

addedInput schema / properties / lower_case

Added value: +{
+  "description": "CHA only. Allow lower case letters (RSDCHABAS-LOWERCASE). Omit to keep existing. Set true for characteristics whose values may contain lower case letters or characters outside the permitted character set (RSKC), such as umlauts. Changing the flag on a characteristic already used by a provider that holds data is accepted; a load that failed activation on such a value can then simply be activated again.",
+  "type": "boolean"
+}

First observedv0.7.0May 26, 2026

TDQS

A4.1/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 load and does well: it discloses the internal sequence lock → GET → PUT → activate → unlock executed as a single call, revealing that an activation side effect occurs and that locking is involved. It also spells out destructive replacement semantics for the attribute list. It stops short of describing failure behavior, rollback, or what happens if activation fails mid-sequence.

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 primary mutation, then the replacement rule, then the KYF variant, then the execution sequence — a logical progression with no filler sentences. It is dense but slightly long; the attribute-replacement rule is stated twice (once in prose, once implicitly via schema).

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the essentials: what can change, replacement vs omission semantics, mutual exclusivity, and the activation sequence. The main remaining gap is return/error signaling — an agent cannot tell what a partially failed activation yields.

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 every parameter including the replace/omit semantics for attributes and the exclusion between unit_currency_infoobject and fixed_unit/fixed_currency. The description largely restates these and adds only the CHA-vs-KYF scoping framing. Baseline 3 applies when the schema does the heavy lifting.

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 and resource ("Update a Characteristic InfoObject") and enumerates the exact editable facets: description, lower case flag, attribute list, and the KYF unit/currency settings. This makes it distinguishable from sibling update tools such as bw_update_adso, bw_update_ckf, or bw_update_infosource 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?

Gives clear conditional guidance for the trickiest parameter: supplying attributes replaces the whole list, an empty array clears it, omitting leaves it untouched. It also flags that unit_currency_infoobject replaces and excludes fixed_unit/fixed_currency. However, it never names an alternative tool or says when to prefer this over bw_update_ckf for key-figure edits, and it does not state prerequisites beyond what the schema says about transport.

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

Deploy Server