Loading ToolBench
An MCP server that provides weather information and greeting tools, combining weather forecasting with greeting and inspirational quote functionality.
WeatherHello has 6 tools with reasonable naming and descriptions, but several quality gaps reduce the score. All tools have descriptions and input schemas are present, but parameter descriptions lack specificity about formats, ranges, and constraints. Output schemas are partially documented (get_today_weather has a rich docstring describing return fields, but others lack equivalent detail). Error handling exists (LocationNotFoundError, WeatherAPIError) but error responses do not guide LLM recovery. The tools follow single-responsibility principle well and chain together logically, but lack actionable error messages and input validation guidance.
Return *(latitude, longitude)* for a place *name* using Nominatim. The result is cached (LRU) to avoid repeated HTTP requests for the same location.
Return the **current air temperature** in Celsius for *location*.
Return today's weather *summary* for **location**. Keys in the returned dict: * location – echo of the input string * latitude, longitude – float coordinates * date – ISO‑8601 string (YYYY‑MM‑DD) * current_temperature – °C * current_wind_speed – km/h * temperature_max – °C (forecast max today) * temperature_min – °C (forecast min today) * precipitation_sum – mm (total rain/snow forecast for today)
Return a friendly greeting for *name*.
Return a random inspirational quote. Attempts to retrieve a fresh quote from *Quotable*. Falls back to a random entry from an internal list on network errors.
Return **True** if forecast precipitation today ≥ *threshold_mm* (mm). The default *threshold_mm* of **0.1 mm** treats even light drizzle as "rain". Increase it (e.g. *1.0*) to ignore negligible amounts.
Tool _geocode uses underscore prefix, conventionally indicating private/internal use, but is exposed as a callable tool. This breaks the Agentic Tool Pattern expectation that tool names are public, discoverable verbs. Either remove from tool registry or rename to geocode.
Parameter descriptions lack format constraints and ranges. Example: 'location' parameter in get_today_weather, get_current_temperature, will_it_rain does not specify expected format (e.g., 'city name', 'city, country', or 'address'). Will the tool accept 'Paris', 'Paris, France', or 'Eiffel Tower'? LLMs cannot infer and may pass invalid formats.
threshold_mm parameter in will_it_rain lacks numeric constraints. Description says 'default: 0.1' but does not state valid range (e.g., 0.0 - 500.0 mm). An LLM could pass 999999 or negative values, causing invalid requests or API errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Error handling exists (LocationNotFoundError, WeatherAPIError) but error responses do not guide recovery. When LocationNotFoundError is raised, the LLM receives a Python exception; it does not get actionable guidance like 'Location not found. Try a different city name or add country: e.g., "Paris, France".' This violates recovery-guide pattern.
Output schemas for random_quote, get_current_temperature, and will_it_rain are not documented. get_today_weather has a detailed docstring, but others are sparse. LLMs need to know return types and field names to plan downstream operations.
No idempotency guarantees documented. Calling get_today_weather('Paris') twice in quick succession will generate two HTTP requests to Nominatim and Open-Meteo. For weather tools this is acceptable, but the tool definitions do not declare idempotency. If agents retry on transient failures, users may be charged or rate-limited.