bw-modeling-mcp

bw_write_process_chain

Create or modify SAP BW/4HANA process chains by adding, removing, or connecting steps, DTP loads, ABAP programs, error links, and decision variants.

Instructions

Create or change a process chain: steps, edges, DTP and program steps, error links, decision variants. The operation enum lists every operation with what it requires; bw_describe(tool: "bw_write_process_chain", 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_process_chain"
  }
}

Input Schema

Name	Required	Description
`to`	No	Target step. Same reference forms as "from". [add_edge, remove_edge]
`dtp`	No	DTP variant name to append (e.g. [append_dtp]
`dtps`	No	Optional. [add_error_links]
`from`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [add_edge, remove_edge]
`mode`	No	"load": add a switch to load mode (PLSWITCHL). [add_plswitch]
`name`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition.
`step`	No	Step to remove. [remove_step]
`after`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [append_dtp, add_program, add_plswitch]
`edges`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [create, update]
`local`	No	Call location. [add_program]
`steps`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [create, update]
`around`	No	mode "bracket" only: the step to enclose (usually the DTP that loads the aDSO). [add_plswitch]
`before`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [append_dtp, add_program, add_plswitch]
`status`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [add_edge, remove_edge]
`adsoact`	No	g. [append_dtp]
`formula`	No	Branch condition formula (BW decision formula syntax), e.g. [create_decision_variant]
`new_dtp`	No	DTP variant name to set instead (e.g. [swap_dtp]
`old_dtp`	No	DTP variant name currently in the chain (e.g. [swap_dtp]
`package`	No	Target package. [create_decision_variant]
`program`	No	ABAP program / report to execute (e.g. [add_program]
`variant`	No	Optional ABAP report (SE38) selection variant name (e.g. [add_program]
`activate`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [10 of 11 operations]
`infoarea`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [create, update]
`edge_mode`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [append_dtp, add_program, add_plswitch]
`operation`	Yes	Operation — one of: create: Create a Process Chain (RSPC) via the BW/4HANA Cockpit REST API. Requires name, infoarea, description, steps, edges. \| update: Replace the step model (nodes and edges) of an existing Process Chain (RSPC) via the BW/4HANA Cockpit REST API. Requires name, steps, edges. \| append_dtp: Add one DTP load step (optionally followed by its own DSO activation step) to an existing Process Chain (RSPC), via the BW/4HANA Cockpit REST API. Requires name, dtp. \| swap_dtp: Swap one DTP load variant for another in an existing Process Chain (RSPC), via the BW/4HANA Cockpit REST API. Requires name, old_dtp, new_dtp. \| add_program: Add an "Execute ABAP Program" step (RSPC process type ABAP, "Programm ausführen") to an existing Process Chain (RSPC), via the BW/4HANA Cockpit REST API. Requires name, program. \| add_plswitch: Add planning mode switch steps for planning-enabled aDSOs to an existing Process Chain (RSPC), via the BW/4HANA Cockpit REST API: PLSWITCHL switches the aDSOs… Requires name, mode, datastores. \| add_edge: Add one dependency (edge) between two existing steps of a Process Chain (RSPC), via the BW/4HANA Cockpit REST API. Requires name, from, to. \| remove_edge: Remove the dependency (edge) between two existing steps of a Process Chain (RSPC), via the BW/4HANA Cockpit REST API. Requires name, from, to. \| remove_step: Remove one step (node) from a Process Chain (RSPC), via the BW/4HANA Cockpit REST API. Requires name, step. \| add_error_links: Add on-error (negative) links to an existing Process Chain (RSPC) by mirroring the existing on-success (positive) out-edges of its DTP load steps, via the BW/4… Requires name. \| create_decision_variant: Create a DECISION process variant (a standalone TLOGO object) for use as a branch/decision step in a Process Chain, via the BW/4HANA Cockpit REST API. Requires name, description, formula.
`reconnect`	No	true (default): bridge the gap so each predecessor of the removed step links to each of its successors. [remove_step]
`datastores`	No	Planning-enabled aDSOs the step switches (e.g. [add_plswitch]
`else_label`	No	Label of the ELSE/second branch. [create_decision_variant]
`sub_status`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [add_edge, remove_edge]
`then_label`	No	Label of the THEN/first branch. [create_decision_variant]
`description`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [5 of 11 operations]
`predecessor`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [append_dtp, add_program, add_plswitch]
`synchronous`	No	Call mode. [add_program]
`else_event_no`	No	EVENTNO of the ELSE branch. [create_decision_variant]
`then_event_no`	No	EVENTNO of the THEN branch (referenced by chain branch edges via sub_status). [create_decision_variant]
`trigger_event`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [create, update]
`program_package`	No	Optional package of the report (cosmetic value-help enrichment; the server re-derives it when omitted). [add_program]
`transport_request`	No	Defined per operation — bw_describe(tool: "bw_write_process_chain", operation: "…") gives each definition. [10 of 11 operations]
`program_description`	No	Optional report description (cosmetic). [add_program]
`refresh_description`	No	If true (default), pull the new variant's step description from its metadata. [swap_dtp]
`variant_description`	No	Optional variant description (cosmetic). [add_program]

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Nov 12, 2026

TDQS

A3.6/5.0

Behavior2/5

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

No annotations exist, so the description carries the full burden and does not meet it. It never states that these are destructive mutations (update replaces the step model), whether changes are transportable or require activation, whether operations are idempotent or reversible, or what happens on partial failure. The only behavioral hint is buried in the schema enum text, not the description.

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 sentences with zero filler, and the capability statement is front-loaded ahead of the discovery instruction. Nothing redundant is included given how much the schema already documents.

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

Completeness3/5

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

For a mutation tool with 41 parameters, eleven operations, no annotations and no output schema, the description is thin on side effects, activation/transport consequences, and return behavior. The pointer to bw_describe compensates for the parameter gap but not the behavioral one.

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 the baseline would be 3, but the description adds meaning the schema cannot: with 41 parameters and 11 operations, most fields are marked "Defined per operation" and the description explains how to resolve that ambiguity via bw_describe. That materially reduces the risk of guessing at parameter shapes.

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?

"Create or change a process chain" is a specific verb+resource, and the enumeration (steps, edges, DTP and program steps, error links, decision variants) tells the agent exactly what surface this tool covers. It does not differentiate itself from nearby writers such as bw_write_dtp or bw_write_planning, so an agent must infer that all these mutation types funnel through this one tool.

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 second sentence gives real procedural guidance: the operation enum carries per-operation requirements, and bw_describe with this tool name plus a specific operation yields the full parameter definition. That is a usable workflow for a multi-operation tool. It stops short of when-not-to-use or prerequisites (activation, transport, locking).

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