Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_update_variable

Update a reusable BW variable in place—description, input, selection, processing, and formula defaults—without delete/recreate; its UID and existing query, CKF and structure references stay intact.

Instructions

Change a reusable BW Variable in place: description, input readiness, input type (optional / mandatory), selection type and processing type, and on a formula variable its default value, unit and currency. The UID stays the same, so references from queries, CKFs and structures survive the change — unlike the delete-and-recreate that was the only correction path before, which BW refuses as soon as anything references the variable, and deleting a query does not remove its reusable components either. The reference characteristic and the variable type cannot be changed: BW accepts such a write, reports it as consistent and keeps the old value, so both are rejected here instead of being sent. Read the result back with bw_get_variable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
unitNoFormula variables only: unit of measure (dimension Quantity or Price); an empty string removes it where the dimension allows.
currencyNoFormula variables only: currency key (dimension Amount or Price); an empty string removes it where the dimension allows.
input_typeNoWhether a value is required: Optional, MandatoryWithInitial (entry required, initial value allowed) or MandatoryWithoutInitial (entry required, initial value rejected).
representsNoSelection type. Interval is a from/to range, SelectionOption allows the full set of comparison operators.
descriptionNoNew description.
default_valueNoFormula variables only: new default value, or null to remove it. A fractional value needs the logon user's decimal notation, as in bw_create_variable.
variable_nameYesTechnical name of the variable.
processing_typeNoHow the variable is filled. ReplacementPath is limited to the current-member variant, the same one bw_create_variable writes. A formula variable takes UserEntry or CustomerExit only.
ready_for_inputNoWhether the variable is shown on the variable screen for user input.
transport_requestNoTransport request to record the change in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.8.1
    • addedInput schema / properties / currency
      Added value: +{
+  "description": "Formula variables only: currency key (dimension Amount or Price); an empty string removes it where the dimension allows.",
+  "type": "string"
+}
    • addedInput schema / properties / default_value
      Added value: +{
+  "description": "Formula variables only: new default value, or null to remove it. A fractional value needs the logon user's decimal notation, as in bw_create_variable.",
+  "type": [
+    "number",
+    "null"
+  ]
+}
    • changedInput schema / properties / processing_type / description
      Previous value: -"How the variable is filled. ReplacementPath is limited to the current-member variant, the same one bw_create_variable writes."New value: +"How the variable is filled. ReplacementPath is limited to the current-member variant, the same one bw_create_variable writes. A formula variable takes UserEntry or CustomerExit only."
    • addedInput schema / properties / unit
      Added value: +{
+  "description": "Formula variables only: unit of measure (dimension Quantity or Price); an empty string removes it where the dimension allows.",
+  "type": "string"
+}
  2. Addedv1.6.0

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 burden and delivers strong context: the write is in-place with a stable UID, references survive, and BW silently accepts writes to the immutable reference characteristic/variable type while keeping the old value, so those are rejected client-side. It omits whether the change needs activation or how transport recording behaves, which keeps 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 core action and mutable fields before the rationale and constraints. The second sentence is dense and runs long (delete-and-recreate aside, query-deletion aside), but each element carries useful behavioral information rather than filler.

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 10-parameter mutation tool with no annotations and no output schema, the description covers scope, immutability constraints, the silent-write hazard, decimal-notation caveat, and a read-back pointer. Missing activation/transport semantics are the only notable gap.

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 all ten parameters (including enum meanings) are already documented in the schema, making 3 the baseline. The description adds only light framing such as which fields are formula-variable-only, largely restating rather than extending the schema.

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 ('Change a reusable BW Variable in place') and enumerates the mutable fields (description, readiness, input/selection/processing type, formula default/unit/currency). It distinguishes itself from the delete-and-recreate path and implicitly from bw_create_variable by emphasizing in-place mutation with UID stability.

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?

Clearly frames when to use it: to correct a variable while preserving references from queries, CKFs and structures, since delete-and-recreate fails once anything references it. It also states the excluded cases (reference characteristic and variable type) and names bw_get_variable for read-back, though it does not explicitly route to a sibling tool for creating a new variable.

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