bw-modeling-mcp

bw_update_query_characteristic

Set display and access properties for characteristics in an existing BW Query, including text, sorting, hierarchy, result rows, and read mode, for selected or all layout characteristics.

Instructions

Set the display and access properties of the characteristics in an existing BW Query - the per-characteristic settings of the rows, columns, and free-characteristics areas: the query-specific description of the characteristic, display of result rows, display as key/text, access type for result values (read mode), sorting, cumulation, display level, and the hierarchy assignment with its display options. Pass "*" as infoobject to apply one set of properties to every characteristic in the layout. Every property also accepts "default", which drops the explicit value and falls back to the InfoObject/query default. All specs are applied in a single save. Characteristics must already be in the layout - add them with bw_update_query_layout first. All names must be technical names (e.g. "QUERY_NAME", "CHAR_NAME").

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": {
      "query_name": "<query_name>",
      "characteristics": "<characteristics>"
    },
    "name": "bw_update_query_characteristic"
  }
}

Input Schema

Name	Required	Description
`transport`	No	Transport request number (e.g. DEVK900123). Only needed when the query lives on a transportable package; omit for $TMP queries.
`query_name`	Yes	Technical name of the query to modify (e.g. "QUERY_NAME").
`characteristics`	Yes	One entry per characteristic, or a single entry with infoobject "*" for all of them.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.10.0Nov 10, 2026

addedInput schema / properties / characteristics / items / properties / description

Added value: +{
+  "description": "Query-specific description of the characteristic, shown instead of the InfoObject text in the query and in Analysis for Office (e.g. to avoid a truncated short text). \"default\" drops it and falls back to the InfoObject text.",
+  "type": "string"
+}

Addedv1.4.0Aug 21, 2026

TDQS

A4.5/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 does well: it discloses atomicity ('All specs are applied in a single save'), the reset semantics of 'default', the wildcard scope, and the naming constraint (technical names). It stops short of saying whether unspecified properties are left untouched, what happens on an invalid characteristic name, or what the call returns, which are the remaining gaps for a mutation tool.

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?

Purpose and scope are front-loaded in the first clause, followed by wildcard and default behavior, then the layout precondition. The long enumeration of individual properties partly duplicates what the schema already lists and could be trimmed, but it is a single coherent block with no filler sentences.

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, the description supplies the essentials an agent needs: precondition, wildcard behavior, reset semantics, atomic save, and naming conventions; transport is covered in the schema. Only the failure/response behavior is undocumented, which is a modest gap.

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 real meaning beyond the schema: the '*' wildcard value for infoobject, the cross-cutting 'default' sentinel that every property accepts, the single-save semantics for the array, and the technical-name requirement. The per-property semantics are left to the rich schema, which is appropriate.

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 ('Set the display and access properties of the characteristics in an existing BW Query') and immediately scopes it to per-characteristic settings in rows, columns, and free-characteristics areas, which separates it from siblings like bw_update_query_cells, bw_update_query_exceptions, and bw_update_query_key_figures. It even enumerates the property families it controls (description, result rows, key/text, read mode, sorting, cumulation, display level, hierarchy).

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?

It states a hard precondition ('Characteristics must already be in the layout') and routes the agent to the alternative that satisfies it ('add them with bw_update_query_layout first'), and it explains the wildcard mode ('Pass "*" as infoobject to apply one set of properties to every characteristic in the layout'). It also clarifies that 'default' drops an explicit value, giving the agent a reset path rather than a guess.

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

Deploy Server