Loading ToolBench
MCP server that bridges Claude Code to air-gapped environments via SSH
bridge-mcp demonstrates strong naming conventions (all tools start with action verbs: mcp_list, mcp_search, mcp_describe, mcp_call) and comprehensive descriptions (140-280 chars each, within the 10-1024 char baseline). All 4 tools have properly typed input schemas with descriptions for each parameter. The meta-tool discovery pattern is well-designed, guiding users through a structured workflow (list → search → describe → call). However, output schemas are not explicitly documented in the source provided, and error handling guidance is minimal. The tool composition is sound, each tool has a single responsibility, and the discovery workflow chains tools logically. Risk annotations (READ_ONLY, DESTRUCTIVE) are present, supporting pattern:confirmation-request for destructive operations.
Invoke any enabled bridge tool by name. Discovery workflow: mcp_list_tool_groups → mcp_search_tools → mcp_describe_tool (fetch the schema + Reduction Strategy) → mcp_call_tool. The target tool's own annotations, destructive-op elicitation gate, and output-reduction params (jq_filter/columns/limit/output_format) all apply exactly as if called directly.
Return the full schema and reduction strategy for a single tool. Use after `mcp_search_tools` to fetch the one schema you need; avoids the ~100 K-token cost of loading every enabled schema up front.
List all tool groups (docker, k8s, cloud, serial, winrm, …) with their tool counts. Call this first to see the broad landscape, then `mcp_search_tools` to narrow in, then `mcp_describe_tool` to fetch the one schema you need.
Search the tool registry by keyword (case-insensitive substring on name and description). Returns compact entries (name + group + short description) without the full schema, so the AI can scan hundreds of tools without saturating context. Filter further with `group` or cap results with `limit`.
Output schemas not documented for any of the 4 tools. mcp_list_tool_groups should document the structure of groups (e.g., [{ name: string, count: number }]). mcp_search_tools should document compact entries (e.g., [{ name: string, group: string, description: string }]). mcp_describe_tool should document the schema + reduction strategy structure. mcp_call_tool should document the executed tool's output pass-through.
Error handling responses lack guidance for recovery. No evidence in descriptions of actionable error messages or error classification (retryable vs user-fixable vs fatal). For mcp_call_tool (DESTRUCTIVE), there is no documented confirmation workflow or dry-run option, despite risk annotation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 59 | - | v1 |
mcp_call_tool 'arguments' parameter is typed as object without schema constraints. While appropriate for a meta-tool (actual schema comes from mcp_describe_tool), the description does not explicitly state 'use mcp_describe_tool to fetch the required schema for this parameter' to guide LLM behavior.
No evidence of rate limiting, input validation, or sanitization controls in the source code provided. For a bridge tool that proxies commands to external systems, this is a security gap.
No audit logging or call tracing visible in the meta_tools.rs excerpt. For a tool that can execute destructive operations via mcp_call_tool, 'who called what with which parameters at what time and what happened' must be logged for compliance.