Loading ToolBench
A Rust-based process manager that runs and intercepts sync processes with MCP server and CLI interface
The Runcept MCP server defines 15 tools with consistent naming conventions starting with action verbs (activate_, deactivate_, get_, start_, stop_, restart_, list_, add_, remove_, update_, init_, kill_, etc.). All tools have descriptions present, though many are generic and don't consistently follow LLM-optimized length guidelines (target 10 - 1024 chars, ideally 50 - 200). Input schemas are visible for all tools with proper JSON Schema types and descriptions for parameters. However, output schemas are NOT documented, responses are described only in prose format within the format_daemon_response function, not formally in tool definitions. Error handling exists but is minimal: errors are formatted as strings without recovery guidance, categorization, or actionable next steps. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear distinctions between read-only and write/destructive operations. No pagination support documented for list tools that could return large result sets. Security concerns: process names and configuration paths are exposed as parameters without validation hints; no explicit permission gates mentioned.
Activate a Runcept environment by providing the path to a .runcept.toml configuration file or directory containing it. Sets this as the active environment for subsequent operations.
Add a new process to the current environment configuration. Allows dynamic process registration without editing the .runcept.toml file.
Deactivate the currently active Runcept environment. After deactivation, no environment will be active until you activate a new one.
Get the current status of the Runcept daemon, including whether it's running, uptime, version, total processes managed, and active environments.
Get the current status of the active environment, including active environment name, project path, and all processes with their current status.
Retrieve logs for a specific process in the active environment. Returns recent log lines with timestamps and severity levels.
Output schemas not formally documented. Tool responses are formatted as plain text strings by format_daemon_response() but no JSON Schema is provided to LLMs describing return structure (fields, types, nested objects). LLMs cannot plan downstream tool calls or extract typed data without documented output schemas.
No tool annotations (destructiveHint, readOnlyHint, idempotentHint) despite clear semantic differences. kill_all_processes, start_process, stop_process, restart_process, add_process, remove_process, update_process, init_project are destructive/write operations. get_*, list_*, status tools are read-only. Without annotations, LLMs cannot distinguish safe from risky tools and may plan incorrectly.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Initialize a new Runcept environment in a specified directory or the current working directory. Creates a .runcept.toml configuration file with default settings.
Forcefully terminate all running processes across all active environments. Use with caution - this performs hard kills without graceful shutdown.
List all processes across all active environments with their current status, PID, uptime, and environment association.
List all processes in the active environment with their current status, PID, uptime, and other details.
Remove a process from the current environment configuration. The process will no longer be available for execution in this environment.
Restart a process in the active environment. Stops the process gracefully and then starts it again.
Start a process in the active environment. The process must be defined in the current environment's .runcept.toml configuration file.
Stop a running process in the active environment. Sends a graceful shutdown signal to the process.
Update the configuration of an existing process in the current environment. Allows changing process properties like command, working directory, or health check settings.
Error responses are unstructured strings without recovery guidance. send_daemon_request() returns McpError wrapping plain text (e.g. 'Failed to connect to daemon: ...' or 'Error: ...'). No categorization (retryable vs user-fixable vs fatal), no suggestion of next steps, no invalid-value echo for self-correction.
No pagination support documented for list tools. list_processes, list_all_processes, and get_process_logs (with 'lines' param) could return large result sets but lack limit/offset/cursor parameters or total_count responses. Large unstructured responses waste tokens and risk context window exhaustion.
Process name and configuration path parameters lack validation constraints or format guidance. 'name' and 'path' parameters accept arbitrary strings; no hints about allowed characters, length limits, or path traversal prevention. LLMs and users can pass invalid or malicious values.
No confirmation or dry-run for destructive operations. kill_all_processes forcefully terminates all processes without confirmation. No dry-run option for init_project with force=true (overwrites config). Agents can trigger catastrophic failures.
Parameter dependencies undocumented. add_process has conditional logic (health_check_url + health_check_interval are related; depends_on is an array). The relationship between health_check_url and health_check_interval is not explicitly documented as a dependency.
Response field names not guaranteed to match parameter names for chaining. get_environment_status returns processes with 'name', 'status', 'environment', 'pid', 'uptime'. These could be passed to start_process (expects 'name') but other fields (e.g. 'environment' override in add_process) are not explicitly documented as chainable.