An MCP server that provides weather forecast and alert data from the National Weather Service (NWS) API
Server provides 2 weather tools with basic input schemas and descriptions. Both tools follow verb_noun naming convention (get_alerts, get_forecast) which is good. However, definitions lack critical details: no output schemas documented, no error handling guidance, parameter descriptions are minimal, no bounds on numeric inputs, and no enum constraints. Descriptions are present but terse (13-15 chars for parameters). Tools are READ_ONLY which is correct, but the server lacks structured output documentation that LLMs need for downstream reasoning.
Get weather alerts for a US state.
Get weather forecast for a location.
No output schema documented for either tool. Tools return free-form strings that LLMs must parse unstructured.
Parameter descriptions are minimal (13-15 chars). 'Two-letter US state code (e.g. CA, NY)' and 'Latitude of the location' lack format, range, or constraint details.
No bounds on numeric parameters. latitude/longitude accept float with no min/max validation. Should be -90.0 to 90.0 for latitude, -180.0 to 180.0 for longitude.
No error handling guidance. Functions return 'Unable to fetch alerts...' or 'No active alerts...' as plain strings. No indication whether to retry, what caused the failure, or how to recover.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
get_forecast hardcodes limiting results to 5 periods ('[:5]'). This limit is not documented in the tool description, violating LLM expectations about result scope.
Tool descriptions lack WHEN guidance. Users/LLMs don't know when to call get_alerts vs get_forecast, or what use cases each covers.