Loading ToolBench
The SSH MCP server defines 4 tools with explicit schemas and descriptions, placing it in the fair-to-good range. Tool names follow verb_noun conventions (ssh_connect, ssh_exec, ssh_status, ssh_disconnect) and are clear. All tools have descriptions between 34 - 87 characters, within the 10 - 1024 baseline. Input schemas are present and typed for all tools. However, several critical gaps prevent a higher score: (1) descriptions lack actionable context (e.g., 'Connect to an SSH server' does not explain prerequisites, when to use it, or what happens on repeated calls); (2) parameters lack guidance on constraints and error handling (e.g., 'timeout' has no minimum/maximum documented, 'command' has no validation hints); (3) no output schemas are documented, callers cannot know what fields to expect; (4) error handling is minimal, McpError messages are generic and do not guide recovery; (5) no parameter descriptions mention authentication methods or security concerns; (6) tool compositions assume prior connection state without explicit dependency documentation. The implementation shows competent TypeScript code with proper schema validation, but fails several core patterns that would make these tools production-ready for agents.
Connect to an SSH server and maintain the connection
Disconnect from the current SSH server
Execute command on the connected SSH server
Get the current SSH connection status
No output schemas documented. Callers (LLMs and clients) cannot infer response structure, field names, types, and required fields are unknown. ssh_connect returns a JSON text blob but the schema for that blob is undocumented, forcing callers to guess at field names.
Descriptions lack actionable context. 'Connect to an SSH server and maintain the connection' does not explain: (1) what happens if a connection already exists; (2) whether multiple sequential calls are idempotent; (3) what authentication methods are preferred; (4) when to use key vs password. LLMs cannot determine whether to call this tool or reuse an existing connection.
Parameters lack validation guidance and constraints. 'timeout' (30000 ms default) has no min/max documented, LLMs could pass 0, negative, or gigantic values. 'command' has no length limit or injection warnings. 'host' accepts any string with no format validation hint (IP vs hostname). Missing constraints invite invalid input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No error recovery guidance. ssh_exec throws a generic McpError with message 'Tool execution failed: <error>' if the command times out or fails. LLMs do not know whether to retry, ask the user, or abandon. The error should classify as retryable/user-fixable/fatal and suggest next steps.
Tool dependencies undocumented. ssh_exec requires an active SSH connection established by ssh_connect, but this dependency is not stated in the description. ssh_status is described generically without explaining when to call it before/after connect. Multi-step sequences should have explicit dependency hints.
No idempotency or retry semantics documented. ssh_connect disconnects any prior connection before reconnecting, but this is not stated. Agents need to know: Is this call safe to retry? Will it cause duplicate side effects? Without explicit idempotency markers, agents will be conservative and avoid retrying even on transient failures.
Secrets passed as parameters risk exposure. The 'password' and 'privateKey' parameters are documented as parameter strings, not server-side secret injection. If agent traces or logs are captured, credentials will appear in plaintext. The pattern requires injecting secrets via environment variables or vault, not parameters.
Parameter descriptions are minimal (10 - 20 chars). 'SSH host to connect to', 'SSH username', 'SSH password' are generic and do not explain format, constraints, or alternatives. A richer description like 'Hostname or IP address (e.g., example.com or 192.168.1.1)' would guide LLMs toward valid input.