Loading ToolBench
MCP server providing weather forecast and comparison tools using Open-Meteo API
Two well-named tools with clear, detailed descriptions (194 - 250 chars each, within baseline 34 - 392). Input schemas are complete with types and descriptions. Output schemas are documented in descriptions. Error handling is structured (validation vs transient, retryable flag). Main gaps: no tool annotations (readOnlyHint/destructiveHint), no pagination support, and output schema not formally declared in JSON Schema format. Naming follows verb_noun pattern (get_weather_forecast, compare_weather). Parameter descriptions are specific ('Number of days ahead (1 to 7, default 3)'). Error responses guide recovery ('city not found: {city}', 'weather service unreachable'). Composition is sound, tools are single-purpose and chainable (compare_weather calls get_weather_forecast internally).
Return a machine-readable comparison record for two named cities using Open-Meteo data: each city's resolved location and tomorrow's numeric maximum in Celsius, plus a verdict field naming the warmer city or reporting a tie. Produces the full comparison in one structured result rather than requiring two separate lookups. Use get_weather_forecast instead for a single city.
Return a machine-readable forecast record for a named city from the Open-Meteo API. Output is structured JSON: one object per day with an ISO date, max_c and min_c as numeric Celsius values, plus a resolved location string. Unknown cities return a structured validation error, not prose. Use this whenever forecast data is needed in a structured form that can be validated, compared or stored. 'days' is how many days ahead (1 to 7, default 3).
Output schemas not formally declared in JSON Schema format. Descriptions document structure (e.g., 'one object per day with ISO date, max_c, min_c') but no explicit JSON Schema definition for return types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only and idempotent but this is not declared in the tool definition.
No pagination or result limits documented. Tools return unbounded results (all days in forecast). If API returns 7 days by default, this is acceptable, but no explicit cap or pagination guidance is stated.
Error handling lacks actionable recovery guidance. Errors return structured category/retryable/message but do not suggest next steps (e.g., 'Try a different city name' or 'Retry in 30 seconds').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Parameter 'days' lacks explicit min/max constraints in schema. Description states '1 to 7' but JSON Schema has no minimum/maximum fields, forcing LLM to parse text constraint.