Loading ToolBench
A unified interface for CLI, HTTP, and LLM integration via MCP protocol
MCP Bridge has 4 tools with basic descriptions and schemas, but significant quality gaps undermine production readiness. Tool naming starts with verbs (get_, register_, remove_) which is good, but descriptions are minimal (34-72 chars) and lack critical detail about when to use tools and what they return. Parameters have type information but lack depth in descriptions. Error handling guidance is absent. Most critically, the server exposes dangerous functionality (registering arbitrary HTTP tools, executing arbitrary CLI commands) with minimal safeguards and no permission checks. The path traversal defenses (get_safe_path) exist but are incomplete, normalization issues remain, and the security model is fundamentally flawed for an agent-facing server.
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 schema documentation for all tools. Tool descriptions do not specify what fields or structures are returned, forcing LLMs to infer response format. For example, get_cli_tool_help returns stdout as a string, but this is not documented anywhere.
Dangerous tool functionality without permission gates or least-privilege checks. register_cli_tool accepts any command string and register_http_tool accepts any URL/headers/data. No validation that the agent has authority to register tools or that the commands/URLs are safe. An agent could register malicious commands or exfiltrate data via HTTP tools.
Incomplete input validation and path traversal defense. get_safe_path() attempts normalization but the lstrip(os.sep).lstrip('/') pattern is fragile, it can be bypassed with encoded separators or repeated attempts. The function returns user_input unchanged rather than the sanitized path, undermining the defense.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Parameter descriptions are sparse and lack constraint information. register_http_tool has a 'method' parameter described as 'HTTP method (GET, POST), need to be uppercase.', but there is no enum constraint, no validation that it's actually uppercase, and no guidance on what happens if lowercase is passed.
No error recovery guidance. Tools return generic error messages like 'Error occurred while getting help: {e}' without telling the agent what to do next. If register_cli_tool fails due to an invalid command, the agent has no guidance on how to proceed.
Tool descriptions do not explain irreversibility or side effects. register_cli_tool and register_http_tool permanently register tools; remove_tool permanently deletes them. This has no documentation of the write/destructive nature, leaving agents unaware they are making irreversible state changes.
JSON string parameters (params, data, headers in register_http_tool) are error-prone. Agents must serialize JSON correctly; parse errors silently default to {} without clear feedback. If an LLM passes malformed JSON, the tool silently ignores it rather than rejecting with a clear error message.
No idempotency guarantees. If an agent retries register_cli_tool with the same command, it will register the tool twice (or overwrite the first). Tool registration should be idempotent, if the tool already exists with identical config, return success without duplicating state.
Parameter naming inconsistency. register_cli_tool uses 'command', but register_http_tool uses 'name'. When multiple tools operate on similar resources, distinct naming should make the difference obvious. Here, both tools register different resource types but the parameter naming is inconsistent.