bw-modeling-mcp

bw_remove_process_chain_edge

Removes the dependency edge between two existing steps of a BW/4HANA process chain in place, optionally by condition, to re-route or repair a mis-wired chain.

Instructions

Remove the dependency (edge) between two existing steps of a Process Chain (RSPC), via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, drops the matching edge(s), and PUTs it back. By default every edge between the two steps is removed, which is what an "always continue" dependency needs (it is stored as an on-success plus an on-error edge); pass status to remove just one of them. Use this together with bw_add_process_chain_edge to re-route a mis-wired chain. Removing an edge can leave a step unreachable from the start — the chain will not activate until every step has a path from the trigger. Reports a skip when no matching edge exists. 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>",
      "from": "<from>",
      "to": "<to>"
    },
    "name": "bw_remove_process_chain_edge"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	Target step. Same reference forms as "from".
`from`	Yes	Source step. 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"; "TRIGGER" or a collector type ("AND"/"OR"); or "#<index>" using the step numbers printed by bw_get_process_chain.
`name`	Yes	Process chain technical name (e.g. "CHAIN_NAME"). Case-insensitive.
`status`	No	Remove only edges with this condition. Omit to remove every edge between the two steps.
`activate`	No	If true, activate the chain immediately after the edit. Default false.
`sub_status`	No	Remove only edges with this branch condition (a DECISION branch EVENTNO, e.g. "01"). Omit to ignore the branch condition.
`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 / from / description

Previous value: -"Source step. 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\"; \"TRIGGER\" or a collector type (\"AND\"/\"OR\"); or \"#<index>\" using the step numbers printed by bw_get_process_chain."New value: +"Source step. 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\"; \"TRIGGER\" or a collector type (\"AND\"/\"OR\"); or \"#<index>\" using the step numbers printed by bw_get_process_chain."

Addedv1.4.0Aug 21, 2026

TDQS

A4.6/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 richly: it discloses the read-modify-PUT in-place edit model, the default of removing all edges (and why 'always continue' needs that), the skip result when no edge matches, and the 412 stale-ETag failure mode. It also warns that removal can leave a step unreachable, blocking activation.

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?

Front-loaded with the core action and default behavior, followed by prerequisites and failure modes. It is dense and somewhat long, but nearly every sentence carries distinct operational value, so little could be cut without losing information.

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 mutation tool with no annotations and no output schema, the description covers behavior, defaults, side effects, failure modes (412, skip), and the transport_request nuance. Nothing material is missing for correct invocation.

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 baseline is 3, but the description adds genuine meaning beyond the schema: the default behavior of omitting status, the on-success plus on-error edge pairing, and the interaction with activation and transportability. It does not add syntax detail for from/to references, which the schema already covers.

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 the dependency (edge) between two existing steps of a Process Chain') and immediately distinguishes itself from bw_remove_process_chain_step and bw_add_process_chain_edge. An agent can select it without opening the schema.

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?

Explicitly routes the agent: pair with bw_add_process_chain_edge to re-route a mis-wired chain, and use the status filter to remove a single edge instead of all. It lacks an explicit 'when not to use' clause versus siblings like bw_update_process_chain or bw_remove_process_chain_step, so it falls just 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.

Deploy Server