A simple MCP server that provides weather alerts and forecasts using the National Weather Service API
Two tools with basic verb-noun naming (get_alerts, get_forecast). Both have descriptions and input schemas with typed parameters. However, descriptions are minimal (10-20 chars), parameter descriptions lack detail on constraints/formats, and output schemas are undocumented. No error handling guidance, no pagination support despite potentially large result sets, and no tool annotations. Schemas are present but sparse, latitude/longitude lack range constraints, state parameter lacks enum of valid codes.
Get weather alerts for a US state
Get weather forecast for a location.
Parameter descriptions are minimal or missing. 'state' parameter lacks explanation of valid format (two-letter code), and latitude/longitude lack range constraints (-90 to 90, -180 to 180). LLMs cannot infer valid input ranges.
Tool descriptions are under 20 characters and lack context. 'Get weather alerts for a US state' and 'Get weather forecast for a location.' do not explain WHEN to use each tool, what data is returned, or dependencies. Baseline is 194 chars for production tools.
Output schemas are undocumented. Both tools return plain strings with no structured schema definition. LLMs cannot plan downstream operations or extract specific fields. Baseline: 100% of A+ tools document return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
No error handling guidance. Errors are caught silently and return generic strings ('Unable to fetch alerts'). LLMs receive no actionable recovery path, should specify 'Invalid state code. Use two-letter US state abbreviation (CA, NY, TX, etc.)' or 'Location not found. Try nearby coordinates.'
No pagination or result limits. get_forecast hardcodes 5 periods, but get_alerts could return hundreds of active alerts. No limit parameter, no pagination cursor, no total count. Large result sets will exhaust context windows.