Loading ToolBench
A robust MCP server for executing commands locally and remotely via SSH with enhanced session management and error handling
The server defines 5 tools with explicit schemas and descriptions visible in src/index.ts. All tools have names starting with action verbs (execute_, transfer_, terminal_*). Schemas are mostly complete with types and descriptions for parameters. However, descriptions are present but could be more LLM-optimized per the rubric (target 50-200 chars for optimal clarity). Output schemas are NOT documented, a critical gap. Error handling mentions validation and rate limiting but lacks recovery guidance. Security concerns exist around command injection despite validation claims. Average tool description length ~180 chars is reasonable but lacks dependency hints and when-to-use guidance.
Execute commands on remote hosts or locally. Returns a JSON object with 'command', 'exitCode', 'stdout', and 'stderr'. Commands are validated for dangerous patterns. Output is truncated if exceeding size limits. Rate limited per session.
Read file contents safely on remote or local hosts.
Search for a pattern in files safely on remote or local hosts.
List directory contents safely on remote or local hosts. Avoids shell quoting issues.
Transfer files between local machine and remote hosts via SFTP, or copy files locally. Supports upload, download, and local copy operations with size limits and validation.
No output schemas documented. Tools return results (exitCode, stdout, stderr for execute_command; file contents for terminal_cat) but LLMs have no formal schema to understand return structure, making downstream tool chaining difficult.
Terminal tool names (terminal_ls, terminal_grep, terminal_cat) are generic and lack clear action-verb distinction. 'terminal_' prefix is redundant given the server context. Should be list_directory, search_files, read_file for clarity.
Descriptions mention 'validated for dangerous patterns' and 'rate limited per session' but provide no error recovery guidance. When validation fails or rate limit hits, what should the LLM do? Descriptions lack actionable next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter 'session' defaults to 'default' and is described as persistent state, but the description does not explain idempotence implications or whether reusing a session causes different behavior on retry. LLMs need explicit idempotence documentation.
No pagination or result limit parameters on terminal_ls, terminal_grep, or terminal_cat. If a directory has 10,000 files or a grep matches 5,000 lines, the agent receives unbounded output that exhausts context window.
Terminal tools accept optional 'host' and 'username' for SSH, but do not explain credential injection or security model. Parameter descriptions do not clarify whether credentials are injected server-side or if the agent passes them (security risk).
execute_command has a 'command' parameter accepting free-form strings. Although the description mentions validation, no enum or pattern constraint is visible. LLMs are not guided toward safe command structures, they can attempt arbitrary commands.
transfer_file 'direction' parameter is an enum (upload|download|local), which is good. However, the description does not explain what 'local' means in context of a remote server tool, nor does it clarify whether 'local' refers to the agent's local machine or the server's local filesystem.