MCP server for querying historical weather information from the Visual Crossing weather API
Single tool with significant definition gaps. Tool name 'visual_crossing_history' lacks action verb prefix (should be 'get_historical_weather' or 'search_weather_history'). Description is 287 chars (within range) but lacks clarity on WHEN to use it vs alternatives, prerequisites, or return structure. Input schema present with 4 parameters, all with descriptions, but parameters lack type constraints (enums for unit_of_measure, format specs for dates). No output schema documented, LLM cannot predict response structure. No error handling guidance; bare empty dict {} on failure tells agent nothing. No pagination despite potentially large result sets. Violates pattern:tool (verb naming), pattern:tool-description (incomplete context), pattern:constrained-input (unit_of_measure should be enum), pattern:response-shaper (output undocumented).
Search for historical weather information from the Visual Crossing weather API Take the location, start and end dates, and a unit of measure (metric or us) Return a dict with the date * temperature * max temperature * min temperature * preciptitation * solar radiation * humidity * cloud cover * snow depth * weather type * weather conditions * heat index * wind chill
Tool name lacks action verb. 'visual_crossing_history' is a noun phrase; should start with verb like 'get_', 'search_', or 'fetch_' (e.g., 'get_historical_weather'). LLMs infer intent from verb, current name is ambiguous.
Output schema completely undocumented. Code returns dict with nested date keys and weather fields (temperature, max_temperature, etc.), but tool description does not specify this structure. LLM cannot plan downstream operations or extract fields reliably.
Parameter 'unit_of_measure' accepts free-form string; should be enum ['metric', 'us']. Current implementation invites hallucinated values like 'celsius' or 'fahrenheit'.
Date parameters (start_date, end_date) lack format specification. No indication of required format (ISO 8601, YYYY-MM-DD, etc.). LLM will guess and likely pass invalid formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Error handling returns empty dict {} on API failure (status != 200). No guidance to LLM: is this retryable? Should user be asked? What went wrong? Violates pattern:recovery-guide.