bw-modeling-mcp

Overview Schema Source Related Servers Discussions Admin

bw_write_composite_provider

Create or modify SAP BW CompositeProviders: add or remove fields and source InfoProviders, set join conditions, mappings, groups, and navigation attributes, or copy an existing structure.

Instructions

Create or change a CompositeProvider. The operation enum lists every operation with what it requires; bw_describe(tool: "bw_write_composite_provider", operation: "…") gives the complete parameter definition of one.

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

Input Schema

Name	Required	Description
`label`	No	Defined per operation — bw_describe(tool: "bw_write_composite_provider", operation: "…") gives each definition.
`action`	No	Defaults to "add_field". [update]
`inputs`	No	Source InfoProviders to attach right away. Required in practice for a Join node. [create]
`enabled`	No	update_navigation_attributes: true (default) switches the attributes on, false switches them off. [update]
`package`	No	Development package (default "$TMP"). [create]
`mappings`	No	add_input / update_mapping. Full definition: bw_describe(tool: "bw_write_composite_provider", operation: "update"). [update]
`copy_from`	No	Copy the structure of this existing CompositeProvider. view_type, inputs and stackable are then irrelevant — they come from the template. [create]
`dimension`	No	g. "GROUP_NAME"). add_field / add_input / update_mapping: group for the fields the call creates, defaults to CHARACTERISTICS or KEYFIGURES. [update]
`info_area`	No	InfoArea to create it in (e.g. "AREA_NAME"). [create]
`join_type`	No	update_join: "inner" (default), "leftOuter", etc. — lowercase first letter. [update]
`key_pairs`	No	update_join: the join key field pairs, named as they appear on each side's own source. [update]
`operation`	Yes	Operation — one of: create: Create a CompositeProvider (HCPR). Requires composite_provider_name, label, info_area. \| update: Change a CompositeProvider (HCPR): its fields, its source providers, their field mappings, the join condition, or root settings. Requires composite_provider_name.
`stackable`	No	Defined per operation — bw_describe(tool: "bw_write_composite_provider", operation: "…") gives each definition.
`transport`	No	Optional transport request (e.g. DEVK900123). Omit for local objects. [update]
`view_type`	No	View node type. Defaults to "Join". [create]
`left_alias`	No	update_join / remove_join: alias of the left input. [update]
`name_usage`	No	How an InfoObject-bound field is exposed. Full definition: bw_describe(tool: "bw_write_composite_provider", operation: "update"). [update]
`cardinality`	No	update_join: defaults to "CN_N". [update]
`input_alias`	No	remove_input / update_mapping: alias of the input (e.g. "U1.ADSO.1"). [update]
`right_alias`	No	update_join / remove_join: alias of the right input. [update]
`default_node`	No	update_settings: path reference to the default view node (e.g. "#///U1"). [update]
`provider_name`	No	add_input: technical name of the source InfoProvider to attach. [update]
`provider_type`	No	add_input: TLOGO-style suffix used in the generated alias (e.g. "ADSO"). Defaults to "ADSO". [update]
`info_object_name`	No	g. "IOBJ_NAME" or "IOBJ_A,IOBJ_B"). update_navigation_attributes: the one field whose navigation attributes change. [update]
`source_providers`	No	add_field only.g.1") to restrict which inputs get a mapping. Omit to map the field in every part provider that contains it. [update]
`new_dimension_name`	No	update_group: rename the group to this name; its fields move along. [update]
`aggregation_behaviour`	No	update_settings. [update]
`navigation_attributes`	No	update_navigation_attributes: attributes to switch, by attribute name ("ATTR_NAME") or as "<FIELD_IOBJ>__<ATTR_NAME>". [update]
`composite_provider_name`	No	Defined per operation — bw_describe(tool: "bw_write_composite_provider", operation: "…") gives each definition.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Nov 12, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing: no side effects, no reversibility, no transport/lock semantics, no activation requirement, and no note that created objects may need bw_activate. The two sentences mostly redirect the reader to the schema and to bw_describe rather than describe behavior.

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?

Two short sentences, front-loaded with the core action, with zero filler. The second sentence is a deliberate pointer to a companion tool rather than padding.

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

Completeness2/5

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

For a 29-parameter mutation tool with no annotations and no output schema, the description is far too thin: it says nothing about return values, activation state, locking, transport handling, or what happens to existing structure on update. It leans on the enum and bw_describe for nearly everything an agent needs to call this safely.

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% and all 29 parameters are tagged with their applicable operation, so the schema does the heavy lifting and the baseline of 3 applies. The description's only extra contribution is telling the agent that bw_describe returns the full definition of one operation, which is helpful but adds no semantics of its own.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb plus resource: "Create or change a CompositeProvider." The resource name is specific enough to separate it from siblings like bw_write_adso or bw_write_infosource, though the description never explicitly contrasts them.

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

Usage Guidelines3/5

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

Implies usage through the operation split (create vs update) and routes the agent to bw_describe for per-operation parameter detail, but gives no when-to-use/when-not-to-use guidance, no prerequisites (e.g. an existing provider or transport request for updates), and no alternative tools named.

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