Loading ToolBench
MCP server for creating SSH connections and executing safe commands on remote servers with security validation
Two tools with basic schemas and descriptions, but significant gaps in parameter descriptions, output documentation, error handling, and security. Tool naming follows verb_noun convention (good), but parameters expose credentials as direct parameters (critical security flaw per pattern:secret-injection). Descriptions are present but generic and lack action guidance. No output schemas documented. Error handling returns unstructured text without recovery guidance. Input schemas exist for both tools with type definitions, but parameter descriptions are minimal (1-2 words). Missing: idempotency guarantees, pagination, batch operations, actionable error messages, and permission gating for destructive operations.
Create a new ssh connection to a server
Run a safe command on the server through an ssh connection, if the command is unsafe it will not be run
CRITICAL: Credentials (password) exposed as tool parameter. Must never appear in tool params, use server-side secret injection via environment variables or vault. Agent traces log every parameter; secrets in params leak into logs and prompt history.
Parameter descriptions are too generic (1-2 words: 'Host of the server', 'Port of the server'). LLMs cannot infer parameter meaning from these minimal descriptions. Add format constraints, ranges, examples of valid values, and dependency hints.
No output schema documented for either tool. LLMs cannot plan downstream operations or extract structured data without knowing the response shape. Document what fields are returned, their types, and whether responses are paginated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Error responses are unstructured text ('SSH connection to {host} failed: {err.message}', 'Command execution rejected...') without recovery guidance. LLMs need actionable errors: category (retryable/user-fixable/fatal), what went wrong, and what to try next.
run-safe-command accepts arbitrary commands and relies on an external Ollama LLM (llama2) for safety validation. No permission gating, no audit trail of executed commands, no rate limiting. A compromised agent or malicious prompt can bypass 'safe' classification and execute destructive commands.
No idempotency guarantees. If new-ssh-connection is retried after a transient error, it will create duplicate connections. If run-safe-command is retried, the same command executes twice. Agents retry on ambiguous failures, non-idempotent tools risk duplicate side effects.
No input validation. 'port' is a number with no range (0-65535). 'command' is a free string with no format constraints. LLMs can pass invalid ports or malformed commands without any early validation or actionable error feedback.
Tool descriptions lack context for selection. 'Create a new ssh connection' and 'Run a safe command' do not explain WHEN to use each tool, what prerequisites exist, or what happens on failure. LLMs cannot distinguish between similar tools without explicit action guidance.
No audit trail or logging of tool invocations. There is client-side logging to a file, but no structured audit log of: who called what tool, with which parameters, at what time, and what happened. This violates compliance and debugging requirements.
Tool descriptions are only 47-99 characters. Rubric baseline for tool descriptions is 194 chars (p10=34, p90=392). These descriptions are at the low end, insufficient for LLM-driven selection and action planning.