Loading ToolBench
Tower-native MCP gateway for aggregating backends with auth, resilience, and observability
mcp-proxy exposes 6 admin tools for proxy introspection and backend management. Tools have basic descriptions and two (proxy/add_backend, proxy/call_tool) show partial input schemas. However, critical gaps exist: 4 of 6 tools lack visible input schema definitions in the source code excerpt, parameter descriptions are missing or incomplete, and output schemas are not documented. Tool names are verb-prefixed and reasonably clear, but descriptions average ~40-50 characters, below the 194-char baseline for production tools. The proxy/call_tool tool is particularly concerning, it accepts arbitrary tool names and arguments without validation guidance, creating a potential security/usability issue. Error handling is not evident in the provided code. The code shows professional structure (async/await, proper Rust patterns) but the tool definitions themselves need hardening for production LLM agent use.
Dynamically add an HTTP backend to the proxy
Invoke any backend tool by its fully-qualified name. Use proxy/search_tools to discover available tools, then call them through this tool.
Dump the current proxy configuration
Get cached health check results for all backends
List all proxy backends with health status
Get the number of active MCP sessions
Four read-only tools (list_backends, session_count, config, health_check) have NO visible input schema definitions. Per HARD SCORING RULES, schema score must be 0 for tools with no visible schema. These tools should declare NoParams or empty schema explicitly in the registration code.
proxy/call_tool accepts arbitrary 'name' (tool name) and 'arguments' (object) parameters with minimal validation guidance. Description says 'Use proxy/search_tools to discover available tools' but no search_tools tool is registered. This violates the constrained-input pattern and creates a usability trap, LLMs cannot know valid tool names or argument structures without discovery.
Tool descriptions are too short (35-50 chars) and lack guidance on WHEN to use each tool or what they return. Baseline for production tools is 194 chars. Example: 'Dump the current proxy configuration' does not explain format, whether it includes secrets, or what an LLM should do with the output.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 10 | - | v1 |
No output schemas are documented for any tool. The code shows BackendInfo, BackendsResult, and SessionResult structs are serialized to JSON, but the tool definitions do not declare these schemas in their registration. LLMs cannot know what fields to expect, this forces manual parsing and breaks downstream tool chaining.
proxy/add_backend returns no guidance on success/failure. The code calls `proxy.add_backend()` but does not document what the tool returns on success, what errors are possible, or how to recover from AddBackendError. Per pattern:recovery-guide, error responses must tell the LLM what to do next.
proxy/config description says 'Dump the current proxy configuration' but does not warn whether TOML includes sensitive values (API keys, auth tokens, secrets). Per pattern:secret-injection, responses must not include tokens or internal secrets. If the config does include secrets, the tool should scrub them before returning.