Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_create_transformation

Create a new inactive Transformation between two SAP BW/4HANA objects, such as aDSOs, DataSources, or InfoSources. Optionally activate it and record it on a transport request.

Instructions

Create a new Transformation between two BW objects (aDSO, DataSource, InfoSource, etc.). The Transformation name is server-generated (32-char UUID-like key). Created inactive — call bw_activate with object_type "trfn" afterwards, or pass activate: true. In a transportable package pass the transport request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packageNoDevelopment package. Default "$TMP".
activateNoActivate the transformation in the same call (default false). The answer then carries the activation messages, and success reflects the activation.
transportNoTransport request (e.g. "DEVK900123") to record the transformation on. Needed for a transportable package; with "activate" it is passed to the activation as well.
source_systemNoSource system name. Required when source_object_type is RSDS (DataSource).
source_object_nameYesTechnical name of the source object.
source_object_typeYesSource object type. Valid values: HCPR (CompositeProvider), ADSO (aDSO), RSDS (DataSource — requires source_system), HAAP (HANA Analysis Process), IOBJ (InfoObject), TRCS (InfoSource), QVIW (Query).
target_object_nameYesTechnical name of the target object.
target_object_typeYesTarget object type. Valid values: ADSO (aDSO), IOBJ (InfoObject), TRCS (InfoSource), DEST (Open Hub Destination).
source_object_subtypeNoInfoObject sub-type of the source. Only applies when source_object_type is IOBJ. Valid values: TEXT (text table), ATTR (attributes / master data), HIER (hierarchy).
target_object_subtypeNoInfoObject sub-type of the target. Only applies when target_object_type is IOBJ. Valid values: TEXT (text table), ATTR (attributes / master data), HIER (hierarchy).
copy_from_transformationNoTechnical name of an existing Transformation to copy rules from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.8.1
    • addedInput schema / properties / activate
      Added value: +{
+  "description": "Activate the transformation in the same call (default false). The answer then carries the activation messages, and success reflects the activation.",
+  "type": "boolean"
+}
    • addedInput schema / properties / transport
      Added value: +{
+  "description": "Transport request (e.g. \"DEVK900123\") to record the transformation on. Needed for a transportable package; with \"activate\" it is passed to the activation as well.",
+  "type": "string"
+}
  2. Changed2 schema fields changedv0.9.2
    • addedInput schema / properties / source_object_subtype
      Added value: +{
+  "description": "InfoObject sub-type of the source. Only applies when source_object_type is IOBJ. Valid values: TEXT (text table), ATTR (attributes / master data), HIER (hierarchy).",
+  "type": "string"
+}
    • addedInput schema / properties / target_object_subtype
      Added value: +{
+  "description": "InfoObject sub-type of the target. Only applies when target_object_type is IOBJ. Valid values: TEXT (text table), ATTR (attributes / master data), HIER (hierarchy).",
+  "type": "string"
+}
  3. First observedv0.7.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it discloses genuinely non-obvious behaviors: the Transformation name is server-generated (32-char UUID-like), the object is created inactive by default, and transport requires a request. It omits permission/auth requirements and error conditions, but the key state and lifecycle traits are covered.

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?

Four tight sentences, front-loaded with the core action then the non-obvious behaviors (server-generated name, inactive state, transport). Every sentence carries information an agent needs; nothing is padded.

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 11-parameter mutation tool with no annotations and no output schema, the description covers the crucial lifecycle facts (auto-generated name, inactive creation, activation path, transport recording). It could say more about what the response returns or failure modes, but the essentials for calling it correctly are present.

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 all 11 parameters including activate, transport, package, and the object type/subtype values. The description reinforces the semantics of activate and transport but adds little beyond the schema, so baseline 3 applies.

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 (Create) and resource (Transformation) plus its scope (between two BW objects, listing types). The resource is unique among siblings (bw_create_adso, bw_create_infoarea, bw_update_transformation), so an agent can distinguish it immediately.

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 context for completing the operation: created objects are inactive, so either call bw_activate with object_type "trfn" afterwards or pass activate:true, and for transportable packages pass the transport request. It routes to the activation sibling, though it doesn't contrast against bw_update_transformation for modifying existing transformations.

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