Loading ToolBench
MCP server providing weather data fetching capabilities via Model Context Protocol, with caching support for weather and geocoding data
Single tool 'fetchWeather' has minimal definition quality. Tool name lacks action verb prefix (should be 'get_weather' or 'fetch_weather_data'). Description is present but generic (23 chars, below 34-char p10 baseline). Input schema exists but contains only one parameter with minimal description ('The city name' is 12 chars, well below 72-char average). No output schema documented. No error handling guidance. No parameter constraints (e.g., city name format, length limits). Tool does not follow verb_noun naming convention clearly. Missing documentation of what the tool returns, when to use it, or prerequisites.
Fetch weather data for a specified city
Tool name 'fetchWeather' uses camelCase instead of snake_case verb_noun convention. Should be 'get_weather' or 'fetch_weather_data' to match LLM expectations and production baselines.
Tool description is only 23 characters ('Fetch weather data for a specified city'). Baseline is 194 chars (p10=34). Too short to guide LLM selection or explain when to use this tool vs alternatives.
Input parameter 'city' has description 'The city name' (12 chars). Baseline is 72 chars. Missing format constraints (e.g., 'City name as string, 2-100 characters, e.g. New York or Paris'). No guidance on accepted formats (full name vs abbreviation).
No output schema documented. LLM cannot know what fields to expect (temperature, humidity, forecast, units, etc.). Prevents downstream tool chaining and forces LLM to guess response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | <=2025-11-25 | v2 |
No error handling guidance. If city not found or API fails, LLM has no recovery path. Should document: 'If city not found, try search_cities() first' or similar.