Loading ToolBench
A Haskell-based MCP server for spawning and managing processes with interactive command execution, process control, and I/O operations
This MCP server has 12 tools with basic JSON Schema input definitions and descriptions present, but falls short of production quality in multiple critical dimensions. Tool names use prefixes (proc-*) but lack clear action verbs (e.g., 'proc-spawn' is ambiguous, spawn what? execute what?). Descriptions are present but minimal (average ~80 chars), lacking the 50-200 char sweet spot and failing to explain WHEN to use each tool vs. alternatives. Parameter descriptions are sparse or missing context about expected formats, ranges, and constraints. Critical security and operational gaps: no error recovery guidance, no idempotent/destructive annotations in schema, and dangerous irreversible operations (proc-spawn, proc-ssh, proc-cmd, proc-ps, proc-terminate) lack confirmation patterns or dry-run support. Output schemas are undocumented, the source code shows tool registration but no visible output shape definitions in the schemas provided. The server appears to be STDIO-based (no HTTP/SSE evidence in code), which is a hard cap at 50 for protocol readiness. Composition is weak: proc-spawn, proc-ssh, proc-telnet, proc-plink, proc-cmd, proc-ps all do similar things (spawn processes) but with no clear differentiation in naming or description. Per-tool assessment below.
Execute a Windows CMD command with arguments
Echo command that returns the input value as output
Send a message to the currently running process and wait for a response
Spawn a secure connection process using PuTTY's plink with login and password prompt handling
Execute a PowerShell command with arguments
Read data from the currently running process output
Spawn a process with the given command and arguments, wait for expected prompts, and return the output
Spawn an SSH process with automatic pseudo-terminal allocation (-tt flag) and password prompt handling
Tool names lack clear action verbs. 'proc-spawn', 'proc-ssh', 'proc-telnet', 'proc-plink', 'proc-cmd', 'proc-ps' all perform similar process spawning but names do not clearly differentiate intent. LLMs cannot infer which tool to select when 6 tools are semantically similar.
Descriptions are generic and under 100 characters for most tools (e.g., 'Spawn a process with the given command' is 46 chars, 'Spawn an SSH process' is 20 chars). Baseline for A-quality is 50-200 chars with WHEN context included. Current descriptions lack guidance on which tool to pick vs. similar ones.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | <=2025-11-25 | v2 |
Spawn a Telnet process using plink with login and password prompt handling
Terminate the currently running process
Spawn a process with Windows PTY allocation using winpty wrapper with interactive prompt handling
Write data to the input of the currently running process
Irreversible/destructive operations (proc-spawn, proc-ssh, proc-telnet, proc-plink, proc-cmd, proc-ps, proc-terminate) have NO confirmation or dry-run support. These tools risk unintended side effects, agents should be required to confirm before execution.
Output schemas are not visible in the source code provided. Tool definitions show input schemas but no documented return types. LLMs cannot plan downstream tool calls or extract data without knowing what fields to expect.
No error recovery guidance. Tools lack descriptions of failure modes, when to retry, and what the LLM should do on error (e.g., 'If SSH connection times out, try reducing timeout or checking host availability').
Parameter constraints and formats are undocumented. E.g., 'timeout' in proc-read is an integer but no min/max bounds, units (microseconds? milliseconds?), or valid ranges are specified. Unbounded numeric parameters let LLMs pass absurd values.
Composition problem: 6 tools (proc-spawn, proc-ssh, proc-telnet, proc-plink, proc-cmd, proc-ps) perform nearly identical spawning with different transports/wrappers. Unclear which to use in which context, agent wastes reasoning cycles. Consolidate or clearly differentiate.
Tool annotations (destructiveHint, readOnlyHint, idempotentHint) are declared in the Features summary but NOT visible in the tool schemas provided. The FEATURES claim 'toolAnnotations=false', confirm whether annotations are actually present in the implementation.
proc-message and proc-write accept generic 'message' and 'data' string parameters with no format constraints or size limits. How large can data be? Are there encoding requirements? Must be specified.