Loading ToolBench
A multi-server MCP client that connects to Calculator and Weather services via stdio transport
This server defines 5 tools with reasonable descriptions and parameter schemas. All tools have explicit descriptions (10-20 words each), clear input schemas with typed parameters, and parameter descriptions. However, there are notable gaps: (1) no output schemas documented, (2) no error handling guidance, (3) parameter constraints missing (e.g., operation enum, unit enum), (4) no pagination support for forecast results, (5) descriptions are generic and lack WHEN/WHY context. Tools follow verb_noun naming (basic_calc, scientific_calc, etc.), which is positive. The tools are READ_ONLY and compose clearly (calculator and weather are separate concerns), but the parameter descriptions lack constraint details that would help LLMs avoid invalid inputs. For example, 'operation' parameter accepts free-form strings instead of an enum ['add', 'subtract', 'multiply', 'divide']. This is a mid-tier server, better than minimal definitions but missing production patterns for error recovery, output documentation, and constraint enforcement.
Perform basic mathematical operations.
Convert between different units.
Get a weather forecast for the next few days.
Get the current weather for a location.
Perform scientific mathematical calculations.
No output schemas documented. Tool descriptions and source code show return types are strings, but LLMs cannot predict structure or plan downstream processing without formal output schema documentation.
Parameters missing enum constraints. 'operation' in basic_calc accepts free-form strings ('add', 'subtract', etc.) without an enum definition. LLMs cannot select valid options from documentation alone and may hallucinate invalid operations like 'modulo' or 'power'.
No error handling guidance in descriptions. Tools return plain text errors (e.g., 'Error: Division by zero', 'Unknown operation: ...'). Descriptions do not explain what errors are possible, when to retry, or what the LLM should do next. Pattern: recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Descriptions lack WHEN/WHY context. Descriptions are 1 - 2 sentences describing what the tool does, but do not answer: when should the LLM call this instead of a similar tool? What are prerequisites? Example: 'Perform basic mathematical operations' vs 'Use this for simple arithmetic (add, subtract, multiply, divide). Call scientific_calc for sqrt, sin, cos, log, exp instead.'
get_forecast does not document pagination or result limits. If many days are requested or forecast data grows, results could exceed context limits. No mention of max items returned or how to fetch subsequent pages.
Parameter descriptions lack format/constraint details. 'unit' parameter in get_weather accepts 'celsius' or 'fahrenheit' but description does not specify this is case-sensitive or list valid values. 'location' accepts any string without guidance on expected format (city name, city+state, coordinates?).
Mock data and hallucination risk. Weather tools use hardcoded mock data (new york, london, tokyo, sydney) and random forecast generation. Descriptions do not warn LLMs that results are mocked, which risks the LLM treating fictional data as real to the user.