Loading ToolBench
MCP server for fetching weather data from OpenWeatherMap One Call API. Provides current weather and forecast information for any location via coordinates or location names.
Server defines 2 tools with complete input schemas and clear descriptions. Tool naming follows verb_noun convention (get_current_weather, get_forecast). Both tools have parameter descriptions and proper type constraints (latitude/longitude with min/max, units as enum). However, output schemas are not documented in the code, no specification of what fields are returned. Error handling is basic and does not provide recovery guidance to LLMs. Parameter descriptions are good but could be optimized further (e.g., mention that location is geocoded via OpenWeatherMap API). The server is STDIO-only, which caps protocol readiness significantly, but tool definitions themselves are solid for a weather domain.
Get current weather data for a specific location. You can use either coordinates (latitude/longitude) OR a location name/address. If you have a place name like 'Baden bei Wien' or 'New York', use the location parameter instead of coordinates.
Get weather forecast (hourly 48h + daily 8d) for a specific location. You can use either coordinates (latitude/longitude) OR a location name/address. Perfect for asking 'What will the weather be tomorrow?' or 'How will the weather be next week?'
Output schema not documented. No specification of what fields are returned by get_current_weather or get_forecast. LLMs cannot predict downstream tool calls or extract expected data without knowing the response structure.
Error handling lacks recovery guidance. When geocoding fails or coordinates are invalid, errors are raised but do not guide the LLM toward corrective action (e.g., 'Try provide explicit coordinates' or 'Try a more specific location name').
Result truncation and pagination not addressed. No mention of maximum result limits, pagination support, or what happens when result sets are very large. Weather API responses could be verbose; tool should document what is stripped and what is included.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Parameter dependencies not explicitly documented. The description mentions 'use location parameter instead of coordinates' but does not formally state that latitude/longitude are mutually exclusive with location, or what happens if both are provided.
API key (openweather_api_key) is correctly handled server-side via settings, but the code is partially truncated. Verify no secrets are exposed in error responses or logs.