Loading ToolBench
MCP Bridge: A unified interface for CLI, HTTP, and LLM integration.
This MCP server exposes 4 tools with significant definition and security gaps. Tool names follow verb_noun patterns (get_cli_tool_help, register_cli_tool, register_http_tool, remove_tool), which is a strength. However, descriptions are thin (most under 100 chars), critical parameter descriptions are missing or vague, input schemas lack proper JSON Schema formalization, and no output schemas are documented. Most critically, register_http_tool and remove_tool expose dangerous operations (HTTP arbitrary requests, destructive deletions) without permission gates, confirmation steps, or proper error handling. The server accepts JSON-serialized strings for complex parameters (params, data, headers in register_http_tool) rather than structured objects, forcing LLMs to construct raw JSON, which is error-prone and violates the principle of matching the chat data model. Security checks like get_safe_path exist but are applied inconsistently, command injection risks remain in get_cli_tool_help and register_cli_tool where subprocess calls receive unsanitized user input.
Get help information for a CLI tool.
Register a new command line tool with the MCP Bridge.
Register a new HTTP tool with the MCP Bridge.
Remove a registered tool from the MCP Bridge.
Missing output schemas for all tools, LLMs have no documented expectation of response structure, forcing them to parse free-form text or infer field names
register_http_tool accepts arbitrary URLs without SSRF/whitelist validation, enabling requests to internal services (localhost, 169.254.169.254 metadata endpoints, private IPs), severe trust boundary violation
register_http_tool forces LLM to construct JSON-serialized strings for params, data, headers instead of accepting structured objects, violates chat data model, increases parse errors and token waste
remove_tool lacks confirmation step, dry-run, or audit trail for a destructive operation, agents can accidentally delete tools without recovery path
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
get_cli_tool_help and register_cli_tool use subprocess with unsanitized command input, vulnerable to shell metacharacter injection; get_safe_path() checks path traversal only, not command injection
Parameter descriptions are tautological or missing context, 'tool_usage' says 'The usage information for the tool' but doesn't explain format (plain text? man page excerpt? structured?)
register_http_tool does not document HTTP method validation, does it accept only GET/POST, or all methods (PUT/DELETE/PATCH)? No enum constraint visible
No permission gates or scope declarations on any tool, register_http_tool and remove_tool should require explicit authorization, not be callable by any connected agent
Error messages are generic or missing, exceptions in get_cli_tool_help return e.stderr or catch-all strings, but don't guide LLM on recovery (e.g., 'Command not found. Did you mean: xyz?')