Loading ToolBench
Security-first MCP server for remote command execution with validation, manifest-based access control, and toolkit deployment
ShellGuard is a STDIO-only server with 8 tools. All tools have descriptions and visible input schemas in server/server.go, but quality is inconsistent. Tool naming is generally clear (validate, execute, disconnect, provision), but parameter descriptions lack depth and missing constraints. Several tools expose security-sensitive parameters (password, passphrase, identity_file) that should not be tool inputs. Error handling is minimal, no recovery guidance, no actionable error messages shown. Output schemas are not documented. The design conflates multiple concerns (connection management, validation, execution) into a single tool set. Average tool quality is fair but not production-grade.
Connect to a remote server via SSH, WinRM, or local shell
Disconnect from one or all remote servers
Download a file from a remote server to local disk
Execute a validated shell command or pipeline on a connected remote server
Deploy diagnostic tools (rg, jq, yq) to remote server
Pause execution for a specified duration in seconds
Get the status of connected servers including transport type and shell
Security-sensitive parameters exposed as tool inputs: 'connect' tool accepts password, passphrase, and identity_file as direct parameters. These should never appear in agent traces or logs. Use server-side secret injection via environment variables or a secure vault instead.
No output schema documentation. Tools do not document what fields they return. For example, 'status' tool description does not specify the shape of the response (are servers returned as objects with host/transport/shell fields? What are valid transport types?). LLMs cannot plan downstream calls without knowing the response structure.
Parameter descriptions lack actionable constraints. 'identity_file' says 'Path to SSH identity file' but does not specify if it must exist, relative vs absolute, or file permissions required. 'port' has no min/max bounds, LLM could pass 99999. Parameter descriptions should include format, range, and valid values inline.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Validate a shell command or pipeline against security policies
Enum constraint missing for 'transport' parameter in 'connect' tool. Description says 'Transport type: ssh (default), local, or winrm' but does not use an enum schema. Free-form strings invite hallucinated transport types. LLM cannot validate options without formal constraint.
Minimal error handling documentation. No tools document what errors are possible, whether they are retryable, or how to recover. For example, 'execute' tool (IRREVERSIBLE) has no dry-run or confirmation step. Agents will execute destructive commands without safeguards.
'connect' tool mixes multiple concerns: opening SSH/WinRM connections, spawning local shells under PTY, and key/password management. This violates single-responsibility principle. Consider splitting into 'connect_ssh', 'connect_winrm', 'connect_local' so each tool has one clear job.
'status' tool returns server information including 'transport type and shell' but description does not explain the response structure. What fields are included? Are they present for all servers or only some? Without output schema, LLM cannot extract or plan on the returned data.
'provision' tool deploys diagnostic tools (rg, jq, yq) but does not document what happens if deployment partially fails (e.g., rg succeeds but jq fails). No per-item success/failure or compensation guidance. Agent cannot distinguish successful partial deployment from total failure.
'execute' tool accepts 'command' parameter without validation constraints. No description of shell language support (bash? sh? PowerShell?), no length limits, no guidance on dangerous commands. Agent could pass invalid syntax or unsafe payloads without warning.