Loading ToolBench
A MCP server to run operations on a POSIX compatible system (Linux, BSD, macOS) machine over SSH
This server demonstrates solid foundational quality with proper tool naming, complete parameter schemas, and clear descriptions. However, it falls short of production grade due to missing output schema documentation, incomplete error handling guidance, and lack of tool annotations. All 5 tools are explicitly defined with verb-noun naming (run_, copy_, patch_) and have parameter descriptions. Parameter schemas include types and descriptions. Descriptions average ~150-180 chars, within the ideal 10-1024 range. The main gaps: (1) no documented return/output schemas; (2) no error recovery guidance or actionable error messages shown in code; (3) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels being labeled; (4) limited guidance on parameter constraints (e.g., timeout_seconds accepts 0 but behavior undefined).
Copy a file from the local machine to a remote POSIX compatible system (Linux, BSD, macOS) using rsync over SSH. Preserves file attributes and creates a backup if the destination file already exists.
Apply a patch or diff to a file on the remote machine using the patch command. The patch content is streamed via stdin over SSH. By default, patch will attempt to automatically detect the correct strip level (-p). Use unified diff format for best results.
Run a command on the local system and return the output. Use this sparingly; only when needed to troubleshoot why connecting to the remote system is failing.
Run a command on a remote POSIX compatible system (Linux, BSD, macOS) system and return the output. This tool does not permit commands to be run with sudo.
Run a command on a remote POSIX compatible system (Linux, BSD, macOS) system and return the output. This tool explicitly runs commands with sudo.
No documented output/return schemas for any tool. LLMs cannot plan downstream operations or extract required fields (remote_host, backup_path, etc.) without knowing what fields are returned.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk labels. Tools marked WRITE or DESTRUCTIVE need annotations to signal to clients and LLMs that these are not idempotent and require caution.
Error handling guidance absent. No evidence in source that tools return actionable error messages (e.g., 'Connection refused, check host and SSH key' vs raw exit codes). Agents need recovery hints, not stack traces.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
'options' parameter in run_ssh_command and run_ssh_sudo_command uses vague format ('key-value pairs separated by ='). SSH options like '-o ConnectTimeout=10' are valid, but no schema constraint, enum, or validation pattern provided. LLMs may pass invalid options.
timeout_seconds parameter allows 0 to disable timeout, but no guidance on behavior (hangs indefinitely? Retries?) or safe bounds. Unbounded timeouts can leave agents stuck. Should document range (e.g., 1 - 3600 seconds) or provide a maximum.
No confirmation or dry-run step for DESTRUCTIVE operations (run_ssh_sudo_command). Agents can invoke arbitrary sudo commands without a confirmation gate. Consider adding a 'dry_run' parameter or separate 'confirm_sudo_command' tool.
run_ssh_sudo_command lacks permission checking or audit trail guidance. No indication in code that sudo access is validated before execution or that calls are logged for compliance. Critical for a tool that runs arbitrary privileged commands.