Loading ToolBench
MCP server providing weather information from Open-Meteo and web search capabilities via DuckDuckGo, integrated with FastAPI and OpenAI for conversational weather assistance
This server provides 4 tools with basic definitions and schemas. Tool names follow the get_* verb pattern appropriately. However, descriptions are terse (ranging 34-98 characters), parameter descriptions are minimal or missing, and there is no documented output schema structure. Error handling guidance is absent, tools raise ValueError but provide no recovery guidance. The tools themselves are well-scoped (one action each), but the definitions lack the depth needed for reliable LLM integration. Code shows proper Pydantic BaseModel definitions (WeatherData, WeatherForecast, ForecastData, SearchResult) but these structures are not surfaced in the tool registration, LLMs cannot see what fields to expect.
Get current weather information for a city using Open-Meteo API.
Get weather forecast for a city using Open-Meteo API.
Fetch and extract text content from a web page.
Search the web using DuckDuckGo.
Output schemas not documented for any tool. Code defines Pydantic models (WeatherData, WeatherForecast, SearchResult) but these are not attached to @mcp.tool() decorators. LLMs cannot see the expected response structure and must infer fields, risking wrong downstream tool calls.
Parameter descriptions are minimal or absent. 'city' in get_weather has description 'City name to fetch weather for' (39 chars), which is bare. No guidance on format (is 'New York' valid? 'NYC'? 'US-NY-New York'?). 'days' in get_weather_forecast lacks any description of the valid range or unit. Parameters should state format, constraints, and examples.
No error handling or recovery guidance. Code raises ValueError('Could not find coordinates for city: {city}') with no suggestion for what the agent should try next. Should return structured errors that tell LLM: 'City not found. Try a larger city name or include country (e.g., "London, UK").'
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Tool descriptions are below optimal length. 'Get current weather information for a city using Open-Meteo API.' (62 chars) and 'Get weather forecast for a city using Open-Meteo API.' (56 chars) lack guidance on WHEN to use this vs other tools, what the LLM gets back, and any prerequisites. Baseline is 194 chars; target 50-200 for LLM optimization.
No pagination or result limits documented. web_search accepts max_results (1-10, default 5) but description does not explain why the limit exists or how to fetch more. get_web_content defaults max_length to 2000 chars but no description of what happens if content exceeds this or how to retrieve more.
No input validation or constraint documentation for string parameters. 'city' and 'query' accept any string with no stated format or length limits. Should document: 'city: 2 - 100 characters, ASCII letters and spaces only' and 'query: 1 - 200 characters'.