Skip to main content
Glama
Sign In
bw-modeling-mcp

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_restart_process_chain_step

Restart a failed or canceled process chain step as a new instance after fixing the cause, so the run continues without restarting the entire chain.

Instructions

Repeat a failed or canceled step of a process chain run, as the process chain monitor does with "Repeat": the step runs again as a new instance within the same run (step number n-2, n-3, …), and the chain continues from there along its success links. Use it after the cause of the failure is removed (a lock released, data corrected), instead of starting the whole chain again. Without process_id the single failed or canceled step of the run is repeated; with several, name one. Steps that finished, are running or never ran are refused. The result names the new instance; follow the run with bw_get_process_chain_run_detail.

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": {
      "chain_id": "<chain_id>",
      "log_id": "<log_id>"
    },
    "name": "bw_restart_process_chain_step"
  }
}

Input Schema

NameRequiredDescriptionDefault
log_idYesLog ID of the run, from bw_list_process_chain_runs or bw_list_process_chain_last_status.
chain_idYesProcess chain technical name (e.g. "CHAIN_NAME").
process_idNoStep number as bw_get_process_chain_run_detail shows it (e.g. "8-1"). Optional when the run has exactly one failed or canceled step.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.10.0

TDQS

A4.5/5.0
Behavior4/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 well: it discloses that a new step instance is created inside the same run (numbering n-2, n-3), that execution resumes along success links, what the result contains, and the refusal conditions. It does not cover permission/auth requirements, whether a step can be repeated more than once, or any rate/side-effect warnings for this mutation.

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-loads the action and the monitor analogy, then eligibility, then the follow-up tool. Every sentence adds a constraint or behavior; nothing is redundant padding despite the length.

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 3-parameter mutation tool with no output schema, the description covers purpose, preconditions, failure modes, and what the result names, plus a pointer to bw_get_process_chain_run_detail for verification. An agent has everything needed to call it correctly and to know when the call will be refused.

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 coverage is 100% and the schema already documents all three parameters, including that process_id is optional when the run has exactly one failed or canceled step. The description restates that rule ('with several, name one') rather than adding new meaning, so the baseline of 3 applies; it does not explain the step-number format 'n-2' beyond what the schema example shows.

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 precise verb and resource: repeat a failed or canceled step of a process chain run, and anchors it to the familiar monitor 'Repeat' action. It distinguishes itself from bw_start_process_chain ('instead of starting the whole chain again') and from bw_get_process_chain_run_detail (the follow-up tool), so an agent can pick it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when: after the cause of the failure is removed (lock released, data corrected). Gives an explicit when-not/alternative: do not restart the whole chain. Also states the eligibility condition (only failed or canceled steps; finished/running/never-ran steps are refused) and the process_id disambiguation rule.

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