Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev

bw_create_dtp

Create a Data Transfer Process (DTP) for an existing transformation and activate it, with optional source-field filter.

Instructions

Create a new DTP (Data Transfer Process) for an existing Transformation and activate it. The DTP name is server-generated. Optionally set a filter on one source field (Equal operator). After creation the DTP is activated automatically. IMPORTANT: Before calling this tool, always check the full transformation chain. Single-step chain (e.g. ADSO->ADSO): use trfn_name only. Two-step chain (e.g. ADSO->TRCS->ADSO): use trfn_name for the first transformation and trfn_name_2 for the second; source_name/source_type = the start object, target_name/target_type = the end object. Omitting trfn_name_2 in a two-step chain causes a persistent HTTP 500 error. Use bw_get_transformation or bw_xref to determine the chain before creating the DTP. DataSource source: set source_type "RSDS" and pass source_system (the DataSource source system). source_name is then the plain DataSource name; the tool builds the RSDS compound source key internally.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packageNoDevelopment package (default "$TMP").
trfn_nameYesTechnical name of the existing Transformation (UUID-like key).
descriptionNoOptional DTP description text (default: empty).
source_nameYesSource object name (e.g. "SOURCE_NAME").
source_typeYesSource object type (e.g. "ADSO", "TRCS", "RSDS"). Use "RSDS" for a DataSource source — source_system is then required.
target_nameYesTarget object name (e.g. "TARGET_NAME").
target_typeYesTarget object type (e.g. "ADSO"). Use "IOBJ" to load into an InfoObject; the loaded sub-object (attributes / texts / hierarchies) is selected with target_object_subtype.
trfn_name_2NoOptional second transformation in a multi-step chain. Include when the DTP spans two transformations (e.g. ADSO→TRCS→ADSO).
filter_fieldNoFilter field to set. Use the exact field name from bw_get_dtp; a name that does not exist is rejected. Requires filter_value or filter_selections.
filter_valueNoOne or more values for an Equal selection, comma-separated (e.g. "VAL1,VAL2,VAL3"). REPLACE semantics: the list is the complete selection of that field, so pass all values in one call. An empty string selects the BW initial value (not the literal "#"). For ranges, patterns, exclusions or values containing a comma, use filter_selections. Look values up with bw_get_filter_values first — a wrong value activates cleanly and filters everything away.
source_systemNoSource system name of the DataSource. Required when source_type is "RSDS".
filter_excludingNoIf true, all values of filter_value are excluded instead of included. Default false. Applies to filter_value only; filter_selections carries a sign per entry.
filter_selectionsNoFull selection vocabulary for one filter field, equivalent to an ABAP RANGE table. REPLACE semantics like filter_value, and mutually exclusive with it. Each entry is validated against the operators the field itself publishes, so an unsupported operator is an error instead of a silently ignored setting.
target_object_subtypeNoInfoObject sub-object to load into. Only applies when target_type is "IOBJ". ATTR (default) = attributes/master data (IOBJA), TEXT = texts (IOBJT), HIER = hierarchies (IOBJH). Must match the sub-object the transformation chain targets.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed5 schema fields changedv1.4.0
    • removedInput schema / properties / filter_dta_name
      Removed value: -{
      -  "description": "Internal dtaName for the filter field.",
      -  "type": "string"
      -}
    • addedInput schema / properties / filter_excluding
      Added value: +{
      +  "description": "If true, all values of filter_value are excluded instead of included. Default false. Applies to filter_value only; filter_selections carries a sign per entry.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / filter_field / description
      Previous value: -"Field name to filter on. Requires filter_dta_name and filter_value."New value: +"Filter field to set. Use the exact field name from bw_get_dtp; a name that does not exist is rejected. Requires filter_value or filter_selections."
    • addedInput schema / properties / filter_selections
      Added value: +{
      +  "description": "Full selection vocabulary for one filter field, equivalent to an ABAP RANGE table. REPLACE semantics like filter_value, and mutually exclusive with it. Each entry is validated against the operators the field itself publishes, so an unsupported operator is an error instead of a silently ignored setting.",
      +  "items": {
      +    "properties": {
      +      "high": {
      +        "description": "Upper bound. Only for operator \"Between\", where it is mandatory.",
      +        "type": "string"
      +      },
      +      "low": {
      +        "description": "Value, lower bound (Between) or pattern (ContainsPattern). Empty string = BW initial value.",
      +        "type": "string"
      +      },
      +      "operator": {
      +        "description": "Selection operator (default \"Equal\"). RANGE equivalents: EQ = Equal, NE = NotEqual, BT = Between, CP = ContainsPattern (use \"*\" as the wildcard), GT/GE/LT/LE = the comparison operators. The comparison operators are include-only on the fields seen so far; the field metadata decides.",
      +        "enum": [
      +          "Equal",
      +          "NotEqual",
      +          "Between",
      +          "ContainsPattern",
      +          "GreaterThan",
      +          "GreaterEqual",
      +          "LessThan",
      +          "LessEqual"
      +        ],
      +        "type": "string"
      +      },
      +      "sign": {
      +        "description": "I = include (default), E = exclude. Includes and excludes may be mixed on one field.",
      +        "enum": [
      +          "I",
      +          "E"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "low"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / filter_value / description
      Previous value: -"Filter value for the Equal selection (e.g. \"PL_001\")."New value: +"One or more values for an Equal selection, comma-separated (e.g. \"VAL1,VAL2,VAL3\"). REPLACE semantics: the list is the complete selection of that field, so pass all values in one call. An empty string selects the BW initial value (not the literal \"#\"). For ranges, patterns, exclusions or values containing a comma, use filter_selections. Look values up with bw_get_filter_values first — a wrong value activates cleanly and filters everything away."
  2. Changed2 schema fields changedv1.2.0
    • addedInput schema / properties / target_object_subtype
      Added value: +{
      +  "description": "InfoObject sub-object to load into. Only applies when target_type is \"IOBJ\". ATTR (default) = attributes/master data (IOBJA), TEXT = texts (IOBJT), HIER = hierarchies (IOBJH). Must match the sub-object the transformation chain targets.",
      +  "enum": [
      +    "ATTR",
      +    "TEXT",
      +    "HIER"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / target_type / description
      Previous value: -"Target object type (e.g. \"ADSO\"). Use \"IOBJ\" to load into an InfoObject's attributes (encoded server-side as IOBJA). InfoObject text/hierarchy targets (IOBJT/IOBJH) are not yet supported."New value: +"Target object type (e.g. \"ADSO\"). Use \"IOBJ\" to load into an InfoObject; the loaded sub-object (attributes / texts / hierarchies) is selected with target_object_subtype."
  3. Changed3 schema fields changedv0.9.1
    • addedInput schema / properties / source_system
      Added value: +{
      +  "description": "Source system name of the DataSource. Required when source_type is \"RSDS\".",
      +  "type": "string"
      +}
    • changedInput schema / properties / source_type / description
      Previous value: -"Source object type (e.g. \"ADSO\", \"TRCS\", \"RSDS\")."New value: +"Source object type (e.g. \"ADSO\", \"TRCS\", \"RSDS\"). Use \"RSDS\" for a DataSource source — source_system is then required."
    • changedInput schema / properties / target_type / description
      Previous value: -"Target object type (e.g. \"ADSO\")."New value: +"Target object type (e.g. \"ADSO\"). Use \"IOBJ\" to load into an InfoObject's attributes (encoded server-side as IOBJA). InfoObject text/hierarchy targets (IOBJT/IOBJH) are not yet supported."
  4. First observedv0.7.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden, and it does so well: it discloses automatic activation, server-generated naming, the persistent HTTP 500 when trfn_name_2 is omitted in two-step chains, and the internal RSDS compound-key construction. It could still be more transparent about failure modes, idempotency, or whether the operation is reversible, hence 4 rather than 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?

The description is dense and front-loaded, opening with the core purpose and then proceeding to the most consequential scenario (multi-step chains) before the filter and DataSource notes. It is slightly longer than necessary and contains minor redundancy between 'activate it' and 'activated automatically', but every major point earns its place.

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?

Given 14 parameters, no annotations, and no output schema, the description covers the biggest hazards and option semantics very well: chain topology, 500 error, DataSource compound keys, and filter replacement behavior. It does not describe return values or post-creation verification, which would be helpful but not required for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of the parameters with solid descriptions, so the baseline is 3, but the description adds significant higher-level meaning: how trfn_name and trfn_name_2 are selected based on chain depth, how source_name/target_name relate to chain endpoints, the consequence of omitting trfn_name_2, and the special handling of DataSource keys. This is substantial added value beyond 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?

The description opens with a specific and unambiguous action: 'Create a new DTP for an existing Transformation and activate it.' It clearly identifies the resource (DTP), the precedent requirement (existing Transformation), and the side effect (activation), which distinguishes it from run/update/get DTP siblings without needing to name them.

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?

The description provides strong situational guidance: it tells the agent to check the transformation chain first, names the lookup tools (bw_get_transformation, bw_xref), and explicitly describes how a two-step chain changes parameter usage. It does not explicitly state when not to use the tool or name sibling alternatives like bw_update_dtp, so it stops short of a 5.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dnic-dev/bw-modeling-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server