Loading ToolBench
Synchronous utilities for Model Context Protocol (MCP) integration
This server has three tools with significant quality gaps. Tool schemas are present but parameter descriptions are entirely missing across all tools. Tool descriptions exist but are minimal (8-19 chars) and provide almost no guidance to LLMs about when to use each tool or what they return. The naming is clear and verb-based (get_weather, get_forecast, get_weather_prompt), but the lack of parameter documentation and weak tool descriptions severely hampers LLM reasoning about tool selection and proper usage. No error handling guidance is visible in the tool definitions. The example is framework code, not production-grade tool design.
Weather forecast prompt
Weather prompt
Parameter descriptions completely missing across all tools. The 'city' parameter in get_weather and get_weather_prompt has no description explaining what format it expects, whether it's a city name or code, or examples. Per the rubric (pattern:tool-description), every parameter must have a description so LLMs understand what value to pass.
Tool descriptions are too brief and lack context. 'Weather forecast prompt' (19 chars) and 'Weather prompt' (14 chars) do not explain when to use get_forecast vs get_weather_prompt, what they return, or their purpose.
get_forecast has no input schema visible in the tool definition (empty properties and required arrays). Per hard scoring rule, if a tool has no input schema, schema score MUST be 0. This tool appears to take no parameters, which is unusual, is this intentional? The lack of schema prevents validation and LLM understanding of valid inputs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
No error handling guidance in tool definitions. If a city is not found, invalid, or missing, the tools provide no recovery hints. Per pattern:recovery-guide, error responses should tell the LLM what to do next (e.g., 'City not found. Try with a different city name or use get_weather without a city parameter').
Tool composition concern: get_weather and get_weather_prompt are very similar, both take a 'city' parameter and return weather-related information, but one is a tool and one is a prompt. The distinction is unclear to an LLM. Per pattern:tool, each tool should have a single, clear responsibility. Consider documenting why both exist and when to use each.
No output schema documentation. The tools are inferred to return strings ('sunny' for get_weather) or GetPromptResult objects, but the tool definitions do not document what fields or structure the LLM should expect. Per pattern:tool, output schemas must be documented so LLMs can plan downstream calls.