Loading ToolBench
A general-purpose MCP server with tools for fetching websites and echoing messages
This server exhibits significant quality issues across naming, descriptions, and schema documentation. Of 4 tools present, most lack proper schema definitions visible in the code, descriptions are minimal or missing, and parameter documentation is sparse. Tools are defined across multiple files using different patterns (lowlevel Server API, FastMCP decorator), making the implementation inconsistent. The 'fetch' tool is the most complete with a proper description and input schema. The 'add' and 'echo_tool' tools defined in test_apps/main.py use FastMCP decorators but lack explicit parameter descriptions beyond type hints. The 'echo' tool in app/sample_sse_simplified.py is incomplete (file cuts off). Overall, this reads as early-stage experimental code rather than production-ready tooling.
Add two numbers
Echo a message
Echo a message as a tool
Fetches a website and returns its content
Tool 'echo' has no visible definition in provided source code (app/sample_sse_simplified.py cuts off mid-definition). Cannot verify schema, description, or parameter documentation.
Tools 'add' and 'echo_tool' defined via FastMCP decorators lack explicit parameter descriptions. The @mcp.tool() decorator over 'add(a: int, b: int)' provides type hints but no human-readable descriptions of what 'a' and 'b' represent (e.g., first operand, second operand).
Tool 'add' description is only 19 characters ('Add two numbers'), falling below the rubric minimum of 20 for a meaningful description. No guidance on what context to use this tool in, no mention of numeric range, overflow behavior, or return type.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Tool 'echo_tool' has minimal description ('Echo a message as a tool', 27 chars) with no explanation of when to use it vs. 'echo' resource, what formatting is applied, or return type. LLM cannot distinguish between similar echo tools.
Input schema for 'add' tool shows raw JSON from inferred signature ('a': {'type':'integer'}, 'b': {'type':'integer'}) but LACKS required field declarations and parameter descriptions. Current schema is bare type info only.
Tool naming lacks consistency and clarity. 'echo' and 'echo_tool' are near-duplicate names that confuse LLM selection, unclear which to use for different tasks.
No error handling guidance visible. The 'fetch' tool's implementation calls 'response.raise_for_status()' but the tool definition provides no description of what errors are possible (HTTP 404, 403, timeout) or what the LLM should do next (retry, ask user, etc.).
Tool 'fetch' accepts a bare 'url' parameter with only string type constraint, no format validation (e.g., 'must be a valid HTTP/HTTPS URL'), no length limit, no example. LLM could pass malformed URLs, non-web protocols, or internal IP addresses without validation.
Output schemas not documented for any tool. 'fetch' returns 'list[types.TextContent | types.ImageContent | types.EmbeddedResource]' but tool definition does not document this schema structure. LLM cannot plan downstream tool calls or extract required fields. LLMs need to know what fields to expect.'