Loading ToolBench
High-efficiency WebSocket relay server for MCP protocol routing between multiple client connections and MCP servers, with message aggregation and JSON-RPC transformation capabilities
This server defines only 2 tools with severely limited documentation and schema clarity. Both tools lack meaningful descriptions (under 20 chars threshold), parameter descriptions are minimal or absent, and output schemas are completely undocumented. The tool names are verb-starting but ambiguous ('tools/list' and 'tools/call' are generic and do not convey specific actions). Parameter schemas exist but lack type definitions in critical cases. No error handling guidance, no pagination for list results, no output structure documentation. This is a minimal proof-of-concept implementation that would not pass production code review.
Invokes a specific tool on one or more connected MCP servers and aggregates responses from all servers
Retrieves a list of all available tools for a specified agent
Tool descriptions are extremely brief and lack actionable context. 'Retrieves a list of all available tools for a specified agent' (64 chars) and 'Invokes a specific tool on one or more connected MCP servers and aggregates responses from all servers' (103 chars) do not explain WHEN to use these tools, what the agent should expect, or how they differ from similar operations. Descriptions should be 50-200 chars with clear intent and prerequisites.
Parameter 'arguments' in tools/call has type 'object' with no constraints, field documentation, or validation rules. The description 'Arguments to pass to the tool' does not explain format, required fields, allowed keys, or example structure. This forces the LLM to guess what shape of arguments each tool expects.
No output schemas are documented for either tool. tools/list should document what fields each tool object contains (name, description, input_schema, risk_level, etc.). tools/call should document the response structure (success/error, tool results, aggregation format). Without documented output, the LLM cannot plan downstream operations or extract required fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No pagination support for tools/list. If an agent has many connected servers with many tools each, the response could become arbitrarily large. The tool should accept 'limit' and 'offset' parameters and return a total count, following the paginated-result pattern.
Tool names 'tools/list' and 'tools/call' are generic and ambiguous. 'tools/list' could mean list all tools, list tools for an agent, or list tool categories. 'tools/call' provides no indication it aggregates from multiple servers. Names like 'list_agent_tools' and 'invoke_tool_on_servers' would be more descriptive and help LLMs disambiguate intent.
No error handling guidance. What happens if an agent_id is invalid? If a tool_name does not exist? If a server fails? If aggregation returns partial results from some servers but not others? Tools should return actionable error messages that tell the LLM what to try next, not stack traces.
Parameter 'agent_id' in tools/list has no type constraint in the visible schema (assumed string by description only). Parameter descriptions lack format guidance: is it a UUID, a name, or a numeric ID? What if the agent_id is invalid?
No documentation of how tools/call handles failures. Does it return partial results if some servers fail? Does it retry? Does it timeout? Does it aggregate errors or return one summary error? The 'aggregates responses from all servers' description is vague.
tools/call is marked as WRITE risk but has no dry-run, confirmation, or preview mode. If an LLM calls an irreversible tool (e.g., delete operation) via tools/call, it could execute without user review. Implement a confirmation pattern for destructive operations.