Loading ToolBench
MCP proxy server with multi-client support that aggregates tools, prompts, and resources from multiple backend MCP servers
The server defines 6 tools with basic input schemas and descriptions, but several critical quality gaps significantly limit production readiness. Tool names follow verb_noun conventions (add, multiply, get_weather, convert_temperature, convert_length, echo), which is good for intent clarity. However, descriptions are minimal (8-49 characters), falling well below the production baseline of 194 chars. Parameter descriptions are sparse or missing entirely. For example, convert_temperature and convert_length accept 'from_unit' and 'to_unit' parameters but lack enum constraints or format documentation, inviting hallucinated values. Output schemas are not documented anywhere in the source. Error handling is absent, tools will fail silently or with generic exceptions rather than providing actionable recovery guidance. The tools themselves are test fixtures (calculator.py, get_weather.py) rather than production-grade implementations, which limits confidence in actual error handling and resilience.
Add two numbers
Convert length between meters, kilometers, miles, and feet.
Convert temperature between Celsius, Fahrenheit, and Kelvin.
Echoes back input text
Get weather for location via HTTP call.
Multiply two numbers
Tool descriptions are below the 194-char production baseline (median 34-49 chars observed). Descriptions like 'Add two numbers' and 'Echoes back input text' lack context about when to use the tool, what it returns, and any prerequisites. LLMs cannot reliably select tools with such minimal guidance.
Conversion tools (convert_temperature, convert_length) accept 'from_unit' and 'to_unit' parameters as free-form strings with no enum constraints or documentation of valid values. LLMs will hallucinate invalid units like 'celsius_temp' or 'kilometer_distance' instead of the canonical 'Celsius', 'Fahrenheit', 'Kelvin', etc.
No output schemas are documented. The source code does not show what fields each tool returns, their types, or structure. This forces LLMs to guess the response format, breaks tool chaining, and prevents validation of downstream tool calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
No error handling or recovery guidance is present. Tools are test fixtures without documented error cases, timeout handling, validation messages, or actionable recovery steps. An LLM calling these tools with invalid input receives no guidance on self-correction.
Parameter descriptions are minimal or absent. 'location', 'from_unit', and 'to_unit' parameters lack format guidance, constraints, or examples. The description for 'input1' in echo is non-standard naming and vague. LLMs cannot infer parameter semantics from names alone.