MCP server providing weather alerts, forecasts, and climate news analysis with advanced analytics capabilities
The server has three tools with visible schemas and descriptions, but significant quality gaps limit its usefulness. Tool naming is inconsistent (analyze_climate_news contains multiple concerns and doesn't follow verb_noun conventions well). Descriptions exist but are generic and lack context about when to use each tool or what format is returned. Parameter descriptions are minimal or absent. Output schemas are completely undocumented, callers cannot predict response structure. Error handling provides no recovery guidance. The analyze_climate_news tool exposes API keys in the source code (critical security issue). Overall, the server demonstrates basic MCP integration but falls well short of production quality.
Analyze news articles about climate policies based on a text prompt with advanced analytics.
Get weather alerts for a US state.
Get weather forecast for a location.
CRITICAL: API key hardcoded in source code. EXA_API_KEY = 'f1ee87a5-5db0-4884-a3d1-4d3915cb7471' is exposed in server.py. This credential will be leaked in git history, logs, and any published artifact.
No output schemas documented. Tools return unstructured text strings. LLMs cannot predict response structure, extract fields for chaining, or validate results. E.g., get_alerts returns free-form text with '---' delimiters instead of a structured list of alert objects with fields like event, severity, description.
Tool name 'analyze_climate_news' violates single-responsibility principle. The tool queries news (via Exa API), performs sentiment analysis, extracts entities, generates charts, and detects dates, at least five distinct concerns. Should be split into separate composable tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Inadequate parameter descriptions. 'state' for get_alerts says 'US state code or name' but doesn't clarify whether 'CA' and 'California' are both valid, or what happens if an invalid state is passed. No enum or format constraint. 'latitude' and 'longitude' lack bounds (valid ranges: -90 to 90 and -180 to 180).
No error handling or recovery guidance. When API calls fail (make_nws_request returns None), generic messages like 'Unable to fetch alerts' are returned. LLMs cannot determine if the error is retryable, user-fixable, or fatal. No actionable next steps provided.
analyze_climate_news parameter 'start_year' defaults to 2025 (future date). This is confusing and may cause zero results. Default should be current year or a recent historical year.
No pagination support for result lists. get_alerts and analyze_climate_news can return many items but offer no limit, offset, or cursor parameters. Large result sets will exhaust token budgets and degrade LLM reasoning.
Responses return raw unstructured text concatenated with '---' separators instead of structured JSON objects. This forces LLMs to parse ad-hoc text formats, which is error-prone and wastes tokens. Example: forecast returns free-form strings like 'Monday: Temperature: 72°F Wind: 10 mph NE Forecast: Sunny' instead of {name: 'Monday', temperature: 72, temperatureUnit: 'F', windSpeed: '10 mph', windDirection: 'NE', detailedForecast: 'Sunny'}.