Loading ToolBench
A secure MCP server with command execution, encryption, and authentication
This MCP server has critical definition quality issues. It exposes two tools with identical names (execute_command), making them indistinguishable to LLMs. Tool descriptions are minimal and generic. Input schemas are present but lack parameter descriptions. The server implements command execution without proper safety isolation, both tools accept arbitrary commands via string splitting, creating injection vulnerabilities. No output schema documentation exists. Error handling is present but does not guide recovery. Security concerns are severe: one tool requires an auth_token parameter (credentials in tool parameters, violating secret-injection pattern), and command validation is trivial (allowlist/blocklist on first word only, easily bypassed). The server is not a valid MCP implementation, it appears to be a custom socket-based system, not MCP-protocol compliant.
Endpoint for Claude to execute commands
Execute a command with validation, encryption, and authentication
Duplicate tool names: Both tools are named 'execute_command', making them indistinguishable to LLMs. The second tool differs only in parameters (adds auth_token), but LLM tool selection cannot disambiguate them.
Credentials exposed as tool parameters: The auth_token parameter in execute_command (server.py) is a secret that must never appear in tool parameters. Agent traces and logs will capture this token, leaking it into observable history.
Input parameter descriptions are missing. The 'command' parameter in both tools lacks a description explaining format, constraints, or examples. Parameter type is 'string' but no guidance on what commands are valid or how they should be formatted.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 19 | - | v1 |
No output schema documentation. Neither tool documents what fields the response contains or their types. Callers must infer structure from code (status, output, error keys are visible in code but not declared in tool schema).
Command validation is trivial and bypassable. Validation checks only the first word of the command (base_cmd = command.split()[0]). This is easily bypassed via shell metacharacters, path traversal, or multi-part commands. No input sanitization against command injection.
Tool descriptions lack context. 'Endpoint for Claude to execute commands' and 'Execute a command with validation, encryption, and authentication' are generic and do not explain WHAT the tool is for, WHEN to use it, or what the LLM should expect. Descriptions are under 80 characters (below the 194 char average for production tools).
Error responses do not guide recovery. When a command is blocked, the response is {'status': 'error', 'output': 'Command not allowed'}. This gives the LLM no hint about what commands ARE allowed, no alternative, and no actionable next step.
No confirmation step for destructive operations. execute_command executes arbitrary commands immediately without any dry-run, preview, or confirmation. An LLM could accidentally delete files or modify system state without explicit user consent.