Loading ToolBench
MCP server for managing SSH sessions and host inventory. Provides tools to query active SSH session state, terminal output, command history, and saved SSH hosts.
Five tools with clear verb-noun naming (terminal_*, hosts_*) and comprehensive descriptions (150-250 chars each). All tools have input schemas with type declarations. However, critical gaps: (1) No output schemas documented, LLMs cannot plan downstream calls or extract fields; (2) Parameters lack type constraints (e.g., 'lines' and 'limit' are integers but have no min/max bounds); (3) No error handling guidance, descriptions say 'will report an error' but don't explain recovery paths; (4) No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only; (5) Missing parameter descriptions for 'lines' and 'limit' defaults are mentioned but not formally specified. Descriptions are well-written and LLM-optimized, but schema completeness and output documentation are weak.
Returns complete details for a specific SSH host by its ID including identity file path, tags, notes, creation date, and a ready-to-use ssh-watch connect command. Use when the user asks for full details about a host or wants the exact command to connect. First call hosts_list to find the host ID, then call this tool with that ID.
Primary tool to query the SSH host inventory. Use whenever the user asks about their servers, saved hosts, connections, or wants to know which hosts are available. Returns all saved hosts with ID, label, user, host address, port, tags, and notes. Use the optional 'tag' filter to narrow results by environment (e.g. 'prod', 'staging'). The 'id' field returned here is what you pass to hosts_get for full details. Do NOT run shellport CLI commands — use this tool instead.
Returns the structured command history with timestamps from the active SSH session — commands the user actually typed, in order. Use for questions like 'what was my last command?', 'what have I run?', or 'show my history'. If history is empty (the watcher may not have captured structured commands yet), fall back to terminal_get_output to infer commands from the raw terminal output. Always call terminal_get_session first to confirm a session is active.
Returns the raw terminal screen content from the active SSH session — exactly what the user currently sees on their remote terminal. This captures everything: commands the user ran, output of those commands, file contents they viewed (e.g. via cat or less), error messages, directory listings, git status output, and more. Use this to understand the user's remote working context or to answer questions about what they saw, ran, or encountered remotely. Always call terminal_get_session first to confirm a session is active. Use a higher 'lines' value (150–300) when the user asks about file contents, logs, or lengthy command output. Do NOT read session.json directly — use this tool instead.
No output schemas documented. LLMs cannot infer what fields to expect (e.g., does terminal_get_session return 'uptime' as seconds or ISO duration? Is 'host' a string or object?). This forces agents to guess and wastes tokens on clarification.
Numeric parameters lack min/max bounds. 'lines' (max 300) and 'limit' (max 100) have upper bounds mentioned in descriptions but not in schema constraints. LLMs may pass invalid values; validation must happen server-side with clear error messages.
No error handling guidance. Descriptions state 'will report an error' but don't explain what to do next. E.g., if terminal_get_session fails (no active session), should the agent call hosts_list to connect first? Recovery paths are implicit.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Call this FIRST when the user mentions their session, server, remote machine, or any remote work. Answers: is there an active SSH session? Which server is the user connected to? How long have they been connected? What directory are they currently in? What was the last command they ran? Returns connection status (active/inactive), host, user, port, uptime, current directory, last command, and output/history buffer stats. If no session is active, this tool will report an error — do not try to read session.json directly.
No tool annotations despite all tools being read-only. Adding readOnlyHint=true to all five tools would signal to agents that these are safe to call without side effects, enabling more aggressive caching and retry strategies.
Parameter 'tag' in hosts_list lacks type constraint. Description says 'case-insensitive' but doesn't specify format (alphanumeric only? spaces allowed? max length?). Agents may pass invalid tag values.