Loading ToolBench
SSH-based MCP Server for executing commands, uploading/downloading files, and managing SSH connections
The server provides 4 tools with basic structure and descriptions, but lacks depth in parameter documentation, output schemas, and error guidance. Tool naming is clear and verb-based (execute-command, upload, download, list-servers), which is good. However, descriptions are brief (10-40 chars for some), parameter descriptions exist but are minimal, and output schemas are not documented in the source. The tool-error.ts file shows good error categorization (ToolErrorCode enum with 15 error types and retriable flag), but error messages returned to LLMs are not visible in the provided code, it's unclear whether they include actionable recovery guidance. Security warnings about whitelists and allowed paths are present in mcp-server.ts, indicating awareness of security concerns. Overall, this is a functional but under-documented server that would benefit from richer descriptions and explicit output schema documentation.
Download file from connected server
Execute command on connected server and get output result
List all available SSH server configurations
Upload file to connected server
No documented output schemas. Tool definitions show input parameters but no corresponding response structure. LLMs cannot plan chained calls or extract required fields without knowing what each tool returns.
Minimal parameter descriptions. 'connectionName' is described as 'SSH connection name (optional, default is default)', this is self-referential and doesn't explain how to discover valid names or what the connection object contains. No guidance on how to choose among multiple connections.
Tool descriptions are terse (under 50 chars for upload/download). They lack context on when to use each tool, prerequisites, or side effects. E.g., 'Upload file to connected server' doesn't explain that this is SFTP-based, requires a configured SSH connection, or that allowed paths may be restricted.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
No error recovery guidance in visible tool responses. While tool-error.ts defines error codes and a retriable flag, the actual error messages returned to LLMs are not shown. Without actionable error guidance (e.g., 'SSH_CONNECTION_FAILED: Unable to connect to host. Verify the connection is configured and the server is reachable.'), LLMs cannot self-correct.
execute-command accepts 'timeout' as a number but provides no bounds or units clarity. Description says 'milliseconds (optional; overrides the connection's commandTimeoutMs or shellCommandTimeoutMs, which defaults to 30000ms)', but LLMs don't parse prose constraints reliably. Should define min/max in the schema and use clearer parameter naming (timeout_ms).
No idempotency guarantees. upload and download tools may be retried on transient failures (per error handling patterns), but the tools do not declare idempotency. For upload, a retry could result in duplicate files or overwrites; for download, it could overwrite local files. Agents need to know whether these operations are safe to retry.
list-servers shows a formatted string output (via formatServerList) but no structured JSON schema. The function returns a human-readable summary + raw JSON appended as text. For LLM consumption, the output should be structured JSON with typed fields (name, connected, host, port, username, status). The current string format makes it hard for agents to extract and use server info programmatically.
No validation or natural-identifier support for connectionName. Users say 'connect to prod-server-1', but if the actual configured name is 'production-server-1', the tool fails silently. No search_connections or fuzzy-match capability exists. Should accept both exact and approximate names, or provide a tool to discover valid names.