Loading ToolBench
MCP server that bridges Claude Code to air-gapped environments via SSH
bridge-mcp provides 4 meta-tools with well-structured schemas and clear discovery patterns. All tools have explicit input schemas with proper JSON Schema definitions, type declarations, and required field markers. Descriptions are present and generally action-oriented, ranging from 150-300 characters, which aligns with baselines (p10=34, p90=392). Tool naming follows verb_noun convention (list, search, describe, call) and conveys intent clearly. However, parameter descriptions lack the granularity expected for production-grade tools, most parameters have minimal description text (1-2 sentences) and do not include format constraints, validation rules, or examples of valid inputs. Output schemas are entirely undocumented: no return type specifications, field definitions, or examples are visible in the source. Error handling guidance is absent, tools do not indicate what errors are recoverable, how to interpret responses, or what to do on failure. The meta-tool pattern is clever for registry discovery but introduces an abstraction layer that masks the underlying 100+ tools; parameter reduction strategies (jq_filter, columns, limit, output_format) are mentioned but their behavior is not formally specified.
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 completely undocumented. No return type specifications visible for any tool. LLMs cannot infer what fields to expect from list_tool_groups, search_tools, describe_tool, or call_tool responses, forcing them to reason about structure without formal documentation.
Parameter descriptions lack actionable detail. 'query' parameter in mcp_search_tools states 'Case-insensitive substring matched against tool name and description' but omits examples of queries, character limits, special character handling, or what to expect when no results match.
Output reduction parameters (jq_filter, columns, limit, output_format) are mentioned in mcp_call_tool description but not formally specified in the input schema. These appear to be passed as part of the 'arguments' object to the target tool, but their valid values, format, and constraints are not documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
No error handling guidance. Tools do not indicate what errors are possible, whether they are retryable, or what the LLM should do on failure. E.g., mcp_search_tools returns 'compact entries' but does not specify what happens when query matches nothing, or if the tool registry is temporarily unavailable.
mcp_call_tool description mentions 'Reduction Strategy' but does not define or document what this means or how to interpret it from mcp_describe_tool output. This breaks the discovery workflow (list → search → describe → call) because the agent cannot understand the 'Reduction Strategy' returned by describe.
No pagination guidance for mcp_list_tool_groups. If the registry grows to hundreds of groups, the response could become unwieldy. No indication of whether results are paginated, cursored, or comprehensive.
mcp_call_tool is marked DESTRUCTIVE but no confirmation/dry-run pattern is evident. The description mentions 'destructive-op elicitation gate' but does not explain how that gate is triggered, what it returns, or how the agent should respond to it.