Weather MCP Server providing weather alerts and forecasts using the National Weather Service (NWS) API
Two tools with clear action verbs and basic parameter schemas, but descriptions are minimal and lack depth. Tool output schemas are not documented. No error recovery guidance. Parameters have type constraints but descriptions are sparse (below ideal 50-200 char range). No input validation guidance or dependency hints for chaining. Tool definitions ARE explicitly visible in source code, so no capping applied.
Get weather alerts for a state
Get weather forecast for a location
Tool descriptions are too brief (both ~30 chars). Descriptions must include WHAT the tool does, WHEN to use it instead of alternatives, and basic prerequisites. Current descriptions lack context for LLM selection and chaining.
Output schemas not documented. LLMs cannot infer what fields to expect in responses or plan downstream chaining. No return type documentation visible.
No error recovery guidance. Functions return generic failure messages ('Failed to retrieve alerts data') without actionable next steps. LLM cannot determine if error is retryable or user-fixable.
Parameter descriptions lack operational detail. 'Two-letter state code (e.g. CA, NY)' includes an example value that LLMs may reuse literally in future calls. Use enum constraints instead of examples.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
No idempotency or retry guidance documented. Forecast tool may call external NWS API, agents need to know if repeated calls with same coordinates are safe and produce consistent results.
get-forecast returns verbose text blocks that require LLM parsing. Should return structured forecast periods with typed fields (temperature as number, unit as enum, etc.) for programmatic chaining.