A robust Weather MCP Server in TypeScript that provides current weather data, forecasts, and historical weather records using the OpenWeatherMap API
Server defines 4 tools with basic structure. All tools have descriptions (good), and input schemas are partially defined with parameter names and basic types. However, schemas lack formal type constraints, parameter descriptions are minimal or absent, output schemas are completely undocumented, and error handling provides no guidance. Tool names follow verb_noun convention (get_*) which is positive. The implementation shows dependency injection and logging infrastructure, but tool quality does not meet production baselines. Average tool score is 54, fair but with significant gaps in schema completeness and parameter documentation expected at higher tiers.
Get cache statistics including weather cache count, forecast cache count, and Redis stats
Get current weather data for a specified city
Get weather forecast for a specified city and number of days
Get historical weather data for a specified city
Output schemas completely undocumented. No tool provides structured documentation of what fields are returned, data types, or how downstream tools should parse responses. This forces LLMs to guess field names and structure, increasing errors in tool chaining.
Parameter descriptions are minimal or missing entirely. 'city' parameter in get_current_weather has one-line description with no guidance on format (city name vs code), length limits, or error cases. Same for 'days' in get_weather_forecast, no indication whether it accepts floats, what 'default: 3, max: 5' means in schema terms, or error behavior if user passes 10.
No enum constraints on categorical parameters. 'city' accepts free-form strings with no validation or discovery mechanism. No tool helps agents discover available cities, valid city name formats, or common misspellings. LLMs will hallucinate city names.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
No pagination or result limiting documented. If get_weather_history returns 10 records by default with limit=10 max, the response could exceed context window for some use cases. Tool description does not state if results are truncated, ordered, or paged.
No error recovery guidance. CallToolRequestSchema handler throws generic errors with no actionable guidance. If city is not found, user sees 'Tool xyz not found' or stack trace rather than 'City not found. Try get_cache_statistics to see available cities.' or suggestions for nearby matches.
No tool annotations (readOnlyHint, idempotentHint). While all tools are read-only (correct risk classification in metadata), the MCP tool definitions do not carry readOnlyHint annotations that would let clients optimize request routing and caching.
Inconsistent parameter naming and type strictness. 'days' in get_weather_forecast has description 'Number of days to forecast (default: 3, max: 5)' but schema does not enforce max via JSON Schema maxValue constraint. Similarly, 'limit' in get_weather_history should enforce min/max bounds in schema, not prose.