Loading ToolBench
MCP Server for remote SSH management of Linux servers. Enables LLM agents to execute commands, read/write files, manage packages, check service status, and perform system administration on remote servers via SSH.
MCP SSH Server provides 9 tools with reasonable naming conventions and acceptable descriptions. All tools follow verb_noun patterns (execute_*, read_*, write_*, list_*, check_*, install_*, get_). Input schemas are present for all tools with proper JSON Schema structure including types and descriptions. However, several critical issues limit the score: (1) tool descriptions are somewhat generic and lack clear guidance on when to use each tool vs alternatives; (2) parameter descriptions include example values (e.g., 'node2', 'prod-web-01', 'nginx.conf') which LLMs tend to reuse literally; (3) output schemas are not formally documented in the schema definitions; (4) error handling patterns are not visible in the provided code samples; (5) some parameters lack clear constraints (e.g., timeout is unbounded, 'command' accepts free-form strings without injection protection guidance); (6) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared despite tools having clear READ vs WRITE semantics.
Check status of a systemd service on a remote server.
Execute a shell command on a remote server. Use for system monitoring, file operations, service management, and general system administration tasks.
Execute a command on multiple servers in parallel. Ideal for bulk operations, monitoring across infrastructure, and coordinated deployments.
Get hostname, OS, CPU, memory, disk summary from a remote server.
Install a package (apt/yum/dnf/auto) on a remote server.
List directory contents on a remote server.
Example values embedded in parameter descriptions (e.g., 'node2', 'prod-web-01', 'nginx.conf', 'nginx', 'apache2'). LLMs tend to reuse example values literally rather than adapting to actual context, causing failed or incorrect calls.
Output schemas not formally documented. Tool definitions show input schemas but no documented return types or response field definitions. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
List SSH servers visible to this token (optional tag filter).
Read a text file from a remote server.
Write or append to a file on a remote server (overwrite or append).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences. execute_command, execute_on_multiple, write_file, and install_package are destructive/have side effects; read_file, list_directory, check_service_status, list_servers, get_system_info are read-only. Annotations would help LLMs reason about safety and retry behavior.
Generic, short descriptions for several tools. 'List SSH servers visible to this token (optional tag filter)' and 'Get hostname, OS, CPU, memory, disk summary from a remote server' lack guidance on when to call them or how they relate to other tools. Should explain WHAT the tool does, WHEN to use it, and any prerequisites.
Parameter 'timeout' is unbounded integer (default 300) with no min/max constraints. LLMs could pass absurd values (0, -1, 999999). Should specify range (e.g., 1-3600 seconds).
Parameter 'command' is free-form string with no injection validation guidance. Code in src/mcp_tools.py shows validate_command() check, but this validation logic is not documented in the parameter description. LLMs have no way to know what commands are blocked without trial-and-error.
Credentials/secrets in SSH connections are handled server-side (via config/tokens), which is correct. However, documentation does not explicitly state that API keys or secrets should NEVER be passed as parameters. Should add security guidance in descriptions.
Error handling patterns not visible in schema definitions. Code shows require_permission, require_server_access checks, but no explicit guidance on what errors LLMs should expect or how to recover. Tool definitions should document common error cases and recovery strategies.
Wildcard pattern matching for servers in execute_on_multiple (e.g., 'prod-web-*', 'test-*') lacks documentation. Parameter description mentions 'wildcard patterns' but does not specify glob syntax, whether case-sensitive, or what happens if no servers match. LLMs need explicit guidance.