Loading ToolBench
MCP server for SSH remote server management with 46+ tools for command execution, file operations, directory operations, background task management, and archive handling.
This server has only 3 tools, of which only 1 (ssh_conn_connect) has a substantive schema. The other 2 tools have trivial or missing schemas. Descriptions vary: ssh_conn_connect has an exceptionally detailed and well-crafted description (506 chars), but the other two are generic and under-specified. Overall, the schema quality is severely limited by the absence of visible input/output type definitions for 2 of 3 tools, and the composition is questionable (list_tools should not be exposed as a tool). No error handling guidance, no parameter validation, no security scoping visible.
Retrieves a list of all available tools on this MCP server, along with their descriptions.
Establish an SSH connection using a pre-configured host. The host can be specified by its 'user@hostname' key or by its alias. Beyond the three fully-supported platforms (Linux, macOS, Windows), any other SSH target that responds to a basic shell command connects too, reported as os_type='flex' (e.g. FreeBSD/OPNsense/pfSense-style routers, or other unrecognized POSIX kernels). For 'linux' and 'flex' connections, a one-time capability probe checks the specific shell/coreutils features this server depends on (some embedded/BusyBox-based devices lack GNU extensions like `find -printf` or `tar --strip-components`) - the result is returned as 'capabilities' (raw probe results) and, if anything's missing, 'capability_warnings' (plain-English gaps). Tools that need a missing capability fail with a clear error naming what's missing, rather than a cryptic remote command failure - nothing is silently degraded.
Check if there is an active SSH connection.
list_tools is not a user-facing tool, it is introspection for the MCP server itself. Exposing it as a callable tool is a design antipattern. Users and agents do not invoke meta-tools; they rely on the host to enumerate available tools. This wastes a tool slot and violates single-responsibility principle.
ssh_conn_is_connected and ssh_conn_connect have empty or missing input schemas in the source. ssh_conn_is_connected has '{}' (empty object), and neither tool shows full JSON Schema definitions with types and constraints. Per the rubric, tools without visible input schemas must score schema=0.
No output schema documentation visible for any tool. The rubric requires documented return types: what fields does ssh_conn_connect return? What is the structure of capabilities and capability_warnings? LLMs cannot plan downstream calls or extract data without knowing the response shape.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | <=2025-11-25 | v2 |
ssh_conn_connect has only one parameter (host_name), but the description mentions capability probe results, os_type detection, and capability_warnings. The parameter description does not explain how to discover valid host names or what happens if the host is not pre-configured. No error guidance for invalid/unknown hosts.
No visible error handling or recovery guidance. If ssh_conn_connect fails (e.g., host not found, authentication fails, capabilities missing), the tool description does not say how the agent should respond. No categorization of errors as retryable, user-fixable, or fatal.
Tool descriptions for ssh_conn_is_connected and list_tools are under 50 characters and do not explain WHEN to use them or WHAT they return. Per the rubric, descriptions under 20 chars must score ≤20; these barely exceed that threshold and lack context.
No visible scope declarations or permission gates. The ssh_conn_connect tool initiates SSH connections but does not declare required permissions (e.g., 'manage:ssh-connections', 'read:host-config'). No audit trail visibility in the code snippet provided.
The server manages SSH credentials via a TOML config file (~/.mcp_ssh_hosts.toml), but no documentation visible on how secrets are injected or protected. Per the rubric, credentials must never appear as tool parameters; confirm server-side injection and log handling.