A simple MCP weather server that provides weather alerts and forecasts using the National Weather Service API
This server has 4 tools across TypeScript and Python implementations. All tools have basic descriptions (10-50 chars) and input schemas with type definitions. However, descriptions are minimal and lack LLM-optimized guidance on WHEN to use each tool or WHAT to do with results. Parameter descriptions exist but are terse. No output schemas documented. No error handling guidance. Naming is clear (get_alerts, get_forecast) but descriptions don't explain dependencies or prerequisites. This is typical community-grade work, functional but not production-ready.
Get weather alerts for a state
Get weather forecast for a location
Get weather alerts for a US state.
Get weather forecast for a location.
Descriptions are under 50 characters and lack LLM-optimized guidance. 'Get weather alerts for a state' does not explain WHEN to call this vs get_forecast, what the output contains, or how to use results downstream.
Output schemas are not documented. LLMs cannot plan downstream operations or extract fields without knowing what get_alerts or get_forecast returns. No structured response definition visible in source.
Python implementation (get_alerts, get_forecast) lacks minLength/maxLength constraints on state parameter. TypeScript version has minLength=2, maxLength=2 but Python does not. Inconsistent validation across implementations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No error handling guidance. If NWS API fails or state code is invalid, LLM receives no recovery hint. Error responses should guide the agent: 'Invalid state code. Use two-letter US state abbreviations (CA, NY, TX, etc.)'
Naming inconsistency: TypeScript uses kebab-case (get-alerts, get-forecast) while Python uses snake_case (get_alerts, get_forecast). This creates confusion for LLMs and clients. Standardize on one convention.