Loading ToolBench
WorkRail is a specialized workflow orchestration MCP server with 21 tools spanning workflow management (v1 and v2 APIs), file operations, shell execution, and agent spawning. Strengths: comprehensive, verbose descriptions for workflow tools; explicit parameter types; structured schemas for most tools. Weaknesses: inconsistent description quality across tools (some trivial, some verbose); missing descriptions for internal tools (ReportIssue, SignalCoordinator); three tools inferred rather than directly visible; minimal error handling guidance; no tool annotations (readOnlyHint/destructiveHint); output schemas documented only in descriptions, not as formal schemas. Naming is generally clear (verb_noun pattern) but some tools are overly specific to the WorkRail execution model rather than general agent patterns.
Execute a shell command in the workspace.
Mark the current workflow step as complete with output notes and artifacts.
Perform an exact string replacement in a file. The file must have been read in this session via the Read tool. By default, old_string must appear exactly once; use replace_all=true to replace all occurrences. Do NOT include line-number prefixes (e.g. "1\t") from Read output in old_string or new_string.
Find files matching a glob pattern in the workspace.
Search for text patterns in files using ripgrep.
Read the contents of a file at the given absolute path. Content is returned in cat -n format: each line is prefixed with its 1-indexed line number and a tab character (e.g. "1\tline one\n2\tline two"). Use offset (0-indexed start line) and limit (max lines) to read a slice of a large file.
Report an issue or problem encountered during workflow execution.
Three tools (ReportIssue, SignalCoordinator, and three v1 workflow tools: discover_workflows, validate_workflow, get_workflow_schema) have no visible input schemas in source code.
Two tools (ReportIssue, SignalCoordinator) have no descriptions in source code.
Bash tool is marked IRREVERSIBLE (dangerous) but has only a one-sentence description and no error handling, recovery guidance, or security warnings. Agents have no guidance on when/why to call it or how to handle failures. Critical for an irreversible tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
Signal the workflow coordinator about session state or events.
Spawn a child workflow session for parallel or nested task execution.
Write content to a file at the given absolute path. Creates parent directories if needed. For existing files: the file must have been read in this session and must not have changed on disk since then. For new files (path does not exist): no prior read is required.
Executes one workflow step at a time by returning the next eligible step and an updated execution state. Inputs: - workflowId: string - state: { kind: "init" } | { kind: "running", completed: string[], loopStack: LoopFrame[], pendingStep?: StepInstanceId } | { kind: "complete" } - event (optional): { kind: "step_completed", stepInstanceId: StepInstanceId } - context (optional): variables used to evaluate conditions and to drive loops (for/forEach/while/until) Common usage: 1) First call: { "workflowId": "...", "state": { "kind": "init" } } 2) After completing the returned step: { "workflowId": "...", "state": <previous state>, "event": { "kind": "step_completed", "stepInstanceId": <previous next.stepInstanceId> } } Important: - Always reuse the "state" returned by the last advance_workflow call. - When completing a step, the event.stepInstanceId must match the previous next.stepInstanceId exactly.
Create a checkpoint at the current workflow step without advancing. Returns a resumeToken that can be used with resume_session to return to this point later.
Continue workflow execution with the next step. Pass the continueToken from start_workflow or the previous continue_workflow call, along with output from the current step.
Your primary tool for any complex or multi-step request. Call this FIRST to see if a reliable, pre-defined workflow exists, as this is the preferred method over improvisation. Your process: 1. Call this tool to get a list of available workflows. 2. Analyze the returned descriptions to find a match for the user's goal. 3. If a good match is found, suggest it to the user and use preview_workflow to start. 4. If NO match is found, inform the user and then attempt to solve the task using your general abilities.
Retrieves the complete workflow JSON schema for reference and development purposes. Use this tool when you need to understand the structure, required fields, and validation rules for workflows. This tool provides: - Complete JSON schema definition with all properties and constraints - Field descriptions and validation rules - Examples of valid patterns and formats - Schema version and metadata information
Inspect a workflow structure before starting it (WorkRail v2, feature-flagged). Use this to understand what steps the workflow will guide you through. The workflow is a step-by-step plan the user (or workflow author) created for this type of task. Returns: - metadata mode: Just name and description - preview mode: Full step-by-step breakdown (default) Pass workspacePath when available so project-scoped workflow variants are resolved against the correct workspace. Remember: inspecting is read-only. Call start_workflow when ready to begin.
Lists available workflows using WorkRail v2 (feature-flagged). Returns workflow metadata plus pinned snapshot hashes for deterministic execution. Use this to discover workflows before attempting multi-step tasks. When a workflow exists for the user's request, following it means following the user's structured instructions. Pass workspacePath when available so project-scoped workflow variants are resolved against the correct workspace instead of the server's fallback directory.
Retrieves workflow information with configurable detail level. Supports progressive disclosure to prevent "workflow spoiling" while providing necessary context for workflow selection and initiation. Parameters: - workflowId: The unique identifier of the workflow to retrieve - mode (optional): 'metadata' for overview only, 'preview' (default) for first step
Find and resume a previous workflow session. Matches sessions by query text, exact IDs, or git context. Returns the current step and a resumeToken to continue with continue_workflow.
Start a workflow execution session (WorkRail v2, feature-flagged). Returns a continueToken to use with continue_workflow for step-by-step execution.
Validates workflow JSON content directly without external tools. Use this tool when you need to verify that a workflow JSON file is syntactically correct and follows the proper schema. This tool provides comprehensive validation including: - JSON syntax validation with detailed error messages - Workflow schema compliance checking - User-friendly error reporting with actionable suggestions - Support for all workflow features (steps, conditions, validation criteria, etc.)
No tool uses destructiveHint, readOnlyHint, or idempotentHint annotations despite the spec supporting them and many tools being destructive or requiring idempotence. These help LLMs reason about safety and retry logic.
Output schemas are documented only in prose descriptions, not as formal JSON Schema in tool definitions. LLMs cannot parse prose schemas to plan downstream tool calls or extract fields reliably.
Bash, Glob, Grep tools lack error handling guidance. Bash description does not explain return format (stdout/stderr/exit code separately, or combined?) or timeout behavior. Glob/Grep do not document what happens on no matches, max result limits, or performance constraints.
Generic tool names (Read, Write, Bash) reduce clarity compared to verb_noun convention (read_file, write_file, execute_command). LLMs rely on names to infer intent before reading descriptions.
Many parameters lack constraints: filePath (Read/Write/Edit) has no minLength/maxLength/pattern; offset/limit lack min/max; Bash command parameter has no length limit or injection validation guidance. Without constraints, LLMs may pass absurd values.
No pagination guidance for Glob/Grep tools that return file lists. If result set is large, response could exhaust context window. No mention of max result limits or next_cursor patterns.
Grep description mentions ripgrep can 'hang' in scripts but doesn't document timeout, max file size, or retry guidance. WorkRail developers note ripgrep hangs (watch-rg-hangs.sh script exists) but this isn't communicated to agents.