Loading ToolBench
MCP server that safely collects read-only diagnostics from your servers over SSH. Bring your own LLM; the model does the reasoning.
rootpilot-ssh-diagnose demonstrates strong tool naming and parameter documentation, with clear descriptions for each tool's purpose and safe (read-only) operations. All 7 tools are explicitly registered with descriptions and input schemas visible in src/index.ts. However, output schemas are not formally documented, responses are rendered as text via renderItems() without a machine-readable schema contract. Parameter descriptions are solid (host, keys, container all have clear purpose text), but several tools lack detail about what data they return or which fields downstream tools should expect. Error handling is present but minimal, most errors are thrown as generic strings without recovery guidance or categorization. No tool annotations (readOnlyHint, etc.) despite all tools being read-only operations.
Run up to 8 whitelisted commands on a host and return their (redacted, truncated) output. Use get_whitelist to see valid keys. Keys outside the whitelist are rejected.
Shortcut: run the base group (docker_ps, df, df_inode, free, uptime, dmesg_oom, docker_daemon) — a cheap first look at a host.
Shortcut: for one container, run docker_logs, docker_inspect (redacted), container_state and docker_stats.
Guide the model through evidence-first root-cause diagnosis of a host.
Return every command this server can run: key, purpose, shell template, and whether it needs a container argument. This is the complete set — nothing outside it can be executed.
A light routine sweep of a host to surface anything worth attention.
Output schemas are not formally documented. Tools return text (via renderItems()) without a machine-readable schema describing fields, structure, or expected format. LLMs cannot plan downstream operations or extract structured data reliably.
Tool annotations (readOnlyHint, idempotentHint, destructiveHint) are missing despite all tools being read-only, safe operations. This deprives LLMs of critical metadata for planning and prevents capability-based filtering.
Error handling does not categorize errors as retryable vs. fatal or provide recovery guidance. Errors like 'unknown host' or 'invalid key' are thrown as plain strings without suggesting next steps (e.g., 'Use list_hosts to see configured hosts').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
List the hosts defined in your hosts.json, with an optional reachability probe (TCP + SSH banner). Returns names to use with the other tools.
diagnose-host and health-check lack clarity on their purpose and differ from collect-based tools. Descriptions mention 'guide' and 'routine sweep' but do not explain what specific commands they run, how they differ from collect_base, or what the LLM should do with the output.
Response field naming not documented. collect() returns renderItems() output (text markdown) rather than structured JSON. LLMs cannot extract per-command exit codes, durations, or error details for programmatic reasoning.