Loading ToolBench
This MCP server has significant definition quality issues. It exposes 6 tools with minimal descriptions and schemas that lack important constraints. The 'call' tool accepts arbitrary tool names and JSON parameters but provides no guidance on valid inputs, error handling, or output structure. The 'echo' tool is defined in a test file rather than the main server. Most tools have generic, under-20-character descriptions that do not meet production standards. No tool has documented output schemas, no error recovery guidance is provided, and parameter descriptions are absent or trivial. The server appears to be a meta-tool for invoking other MCP servers rather than a standalone tool implementation, which inverts the typical pattern: instead of building focused, well-documented tools, it provides a thin CLI wrapper that passes through to other servers. This design makes it impossible to provide LLM-optimized descriptions because the actual tools are external.
Call a tool with parameters.
Echo back the message.
List available prompts.
List available resources.
List available tools.
Print the version.
The 'call' tool has dangerously vague parameter descriptions. 'params' is described only as 'JSON string of parameters' with no guidance on which parameters are valid, what types are expected, or how errors are reported. An LLM will hallucinate arbitrary parameters and fail silently.
No output schema documentation for any tool. The 'call' tool returns 'structured_content' or a list of content items, but the structure is not documented. LLMs cannot plan downstream actions without knowing what fields to extract.
Tool descriptions are under 20 characters, which violates the minimum clarity standard. 'List available tools' (23 chars) is acceptable, but 'Echo back the message' (20 chars) and others do not explain the context or use case.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
The 'call' tool inverts the tool design pattern. Instead of implementing focused, single-responsibility tools, it exposes a meta-tool that passes through arbitrary tool invocations to an external MCP server. This makes it impossible to provide LLM-specific descriptions or error guidance for the actual operations.
No error handling guidance. The 'call' tool can fail for many reasons (invalid tool name, malformed JSON, missing required parameters, timeout), but provides no actionable recovery instructions for the LLM. A raw error leaves the agent stuck.
The 'echo' tool is defined in tests/echo_server.py, not in the main server implementation. This suggests the server may not be self-contained or that the tool was inadvertently exposed. If 'echo' is meant only for testing, it should not be listed as a production tool.
The 'call' tool's 'tool_name' parameter has no enum constraint or validation hint. An LLM will guess arbitrary tool names. A description like 'The name of a tool exposed by the connected MCP server (call tools() first to list available options)' would guide discovery.
'params' and 'params_file' are mutually exclusive, but this is only enforced at runtime via a UsageError. The schema and description do not declare this relationship, leaving the LLM to guess. Both parameters lack type hints (should be 'object' and 'string' respectively in the schema).