Loading ToolBench
This server has significant gaps in tool definition quality. While tool names follow verb-first conventions (spawn_process, send_command, read_buffer, kill_session, get_history), parameter descriptions are present but lack critical constraint information. The schemas are partially visible but lack depth, no enums for constrained inputs, no explicit output schema documentation, no pagination guidance for history retrieval. Error handling returns plain strings rather than structured error guidance. The architecture maintains global session state in SESSIONS dict, which is reasonable for STDIO servers but introduces resource cleanup risks. Tools lack explicit risk annotations despite dealing with destructive operations (kill_session) and arbitrary command execution (send_command). Parameter descriptions are generic (e.g., 'The session ID to read from' lacks guidance on what happens when the session doesn't exist). No per-tool permission declarations, no rate limiting, no dry-run patterns for destructive operations.
Retrieves the full interaction history for a session.
Terminates the process and cleans up resources.
Reads remaining content from the buffer without sending a command. Useful for checking asynchronous logs or delayed output.
Sends a command to a specific session and reads the output.
Spawns a new interactive CLI process.
Output schemas not documented. Tools return unstructured strings (e.g., send_command returns raw process output as string). LLMs cannot know what fields to expect in the response, breaking downstream tool chaining and requiring manual parsing of free-form text.
No input validation or constraint documentation. send_command's 'wait_for' parameter is described as 'A regex pattern' but no validation confirms the regex is valid. 'timeout' parameter has no min/max bounds, LLMs could pass negative or absurdly large values (e.g., 999999.0 seconds). Parameter descriptions are minimal and lack actionable guidance.
Error handling returns plain strings instead of structured guidance. Errors like 'Error: Session ID not found.' do not tell the LLM what to do next (should it call spawn_process? list available sessions?). No recovery paths, no error classification (retryable vs fatal).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No tool annotations for risk levels despite explicit WRITE, DESTRUCTIVE, READ_ONLY designations in the spec. send_command and spawn_process are marked WRITE but lack destructiveHint or readOnlyHint annotations. This prevents clients from applying appropriate warnings or confirmations.
Global session state (SESSIONS dict) with no documented cleanup strategy. Sessions persist indefinitely in memory until kill_session is called. No TTL, no auto-cleanup on process exit, no garbage collection mechanism. Long-running agents could exhaust memory by creating sessions without terminating them.
get_history is registered as a @mcp.resource() but the spec indicates it should be a @mcp.tool(). Resources are for static content; tools are for operations. This mismatch may cause protocol violations or unexpected behavior in MCP clients.
No documentation of session lifecycle or resource limits. How many concurrent sessions can the server handle? What happens if an agent spawns 1000 processes? No guidance on expected scale or failure modes.
Parameter descriptions are under 50 characters for most tools, leaving ambiguity. E.g., 'The session ID to terminate.' does not explain what happens to buffered output, whether the process receives SIGTERM or SIGKILL, or if cleanup is immediate.