bw-modeling-mcp

bw_remove_process_chain_step

Removes one step from a Process Chain and, by default, bridges the gap so each predecessor links to its successors, keeping the strand connected; use it to roll back a misplaced step.

Instructions

Remove one step (node) from a Process Chain (RSPC), via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, drops the node together with every edge touching it and its inline process variant, and PUTs it back. By default the gap is bridged — every predecessor of the removed step takes over every successor, keeping the condition of the edge that ran into the removed step — so the strand stays connected. Pass reconnect=false to leave the successors disconnected. Use this to roll back a step that was inserted in the wrong place. The TRIGGER (Start) step cannot be removed. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.

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": {
      "name": "<name>",
      "step": "<step>"
    },
    "name": "bw_remove_process_chain_step"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Process chain technical name (e.g. "CHAIN_NAME"). Case-insensitive.
`step`	Yes	Step to remove. Node reference forms: a DTP or process-variant name; an aDSO held by an ADSOACT/ADSOREM node; the program of an ABAP step, or "PROGRAM/VARIANT"; a planning mode switch as "PLSWITCHL/ADSO_NAME" or "PLSWITCHP/ADSO_NAME"; a collector type ("AND"/"OR"); or "#<index>" using the step numbers printed by bw_get_process_chain. An ambiguous name is rejected with the candidates listed — use "#<index>" then.
`activate`	No	If true, activate the chain immediately after the edit. Default false.
`reconnect`	No	true (default): bridge the gap so each predecessor of the removed step links to each of its successors. false: drop the edges without bridging, which leaves the successors as a strand nothing leads to (the chain then will not activate until they are re-wired with bw_add_process_chain_edge).
`transport_request`	No	Optional transport request to record the change into. Only relevant when the chain is in a transportable package (not $TMP). If the chain is transportable and exactly one request is available, it is chosen automatically; pass this to disambiguate when several are available. Ignored for $TMP (local) chains.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.9.0Oct 30, 2026

changedInput schema / properties / step / description

Previous value: -"Step to remove. Node reference forms: a DTP or process-variant name; an aDSO held by an ADSOACT/ADSOREM node; the program of an ABAP step, or \"PROGRAM/VARIANT\"; a collector type (\"AND\"/\"OR\"); or \"#<index>\" using the step numbers printed by bw_get_process_chain. An ambiguous name is rejected with the candidates listed — use \"#<index>\" then."New value: +"Step to remove. Node reference forms: a DTP or process-variant name; an aDSO held by an ADSOACT/ADSOREM node; the program of an ABAP step, or \"PROGRAM/VARIANT\"; a planning mode switch as \"PLSWITCHL/ADSO_NAME\" or \"PLSWITCHP/ADSO_NAME\"; a collector type (\"AND\"/\"OR\"); or \"#<index>\" using the step numbers printed by bw_get_process_chain. An ambiguous name is rejected with the candidates listed — use \"#<index>\" then."

Addedv1.4.0Aug 21, 2026

TDQS

A4.5/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 burden and does so: it discloses the read-modify-PUT in-place pattern, default gap-bridging semantics including edge-condition inheritance, the reconnect=false consequence (strand that blocks activation), the trigger immutability rule, and the 412 stale-ETag failure mode. That is exactly the behavioral context an agent needs before mutating a chain.

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?

Front-loaded with the core action, then side effects, then default behavior, then the escape hatch and constraints. Every sentence adds distinct information (bridging default, trigger restriction, 412 ETag) with no repetition or filler.

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 destructive, in-place mutation with no annotations and no output schema, the description covers what is destroyed, what is preserved (conditions), the default vs. opt-out behavior, the activation prerequisite implication, and the primary error condition. Nothing an agent needs in order to call it safely is missing.

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 name, step forms, activate, reconnect and transport_request in detail. The description only restates reconnect=false behavior, which the schema also spells out, and adds no parameter meaning beyond the structured data. 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 and resource (remove one step/node from a Process Chain/RSPC) and immediately scopes the side effects: the node, all touching edges and its inline process variant are dropped. This clearly separates it from bw_remove_process_chain_edge, which manipulates edges alone.

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 a concrete use case (rolling back a step inserted in the wrong place), states a hard constraint (the TRIGGER/Start step cannot be removed), and points to the sibling needed to repair a non-bridged chain (bw_add_process_chain_edge). It stops short of an explicit 'use bw_remove_process_chain_edge instead when you only want to drop an edge' comparison.

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

Deploy Server