Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev

bw_update_variable

Change a reusable BW variable's description, input readiness, input type, selection type, or processing type without breaking references to it, preserving the UID across updates.

Instructions

Change a reusable BW Variable in place: description, input readiness, input type (optional / mandatory), selection type and processing type. 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
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.
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.
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. Addedv1.6.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden and exceeds it. It discloses that the UID stays stable so references survive, that BW silently accepts unsupported writes as consistent while keeping old values, and that the tool therefore rejects those fields before sending. This gives the agent accurate expectations about both BW behavior and the tool's guardrails.

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?

The description is longer than average but every sentence earns its place: scope, benefit, guardrail against silent failure, and verification step. Key information is front-loaded, and no filler or repetition of schema content exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation tool with no annotations and no output schema, this description is complete. It tells the agent what is updatable, what is not, the behavioral consequences of both paths, and how to verify the result. The schema covers parameter-level details, and the description covers operational context.

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%, so the baseline is 3, but the description adds genuine value beyond the schema. It warns that ReplacementPath is limited to the current-member variant and ties it to what bw_create_variable writes, and it frames the mutable fields as a coherent in-place update, supplementing the raw parameter descriptions.

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?

The description opens with a specific verb and resource—'Change a reusable BW Variable in place'—and enumerates exactly which attributes can be changed. It also distinguishes itself from the delete-and-recreate alternative and from the read-back tool bw_get_variable, so an agent can tell it apart from siblings.

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

Usage Guidelines5/5

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

The description explicitly explains when this tool is the right correction path versus delete-and-recreate, including why the alternative fails when references exist. It also states that reference characteristic and variable type cannot be changed and are rejected rather than sent, and it directs the agent to read the result back with bw_get_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