Two tools with basic verb-noun naming (get_forecast, get_alerts). Both have short descriptions (34-40 chars, below the 50-200 char baseline for LLM-optimized descriptions). get_forecast has a complete input schema with typed float parameters and descriptions; get_alerts has a string parameter with description. However, neither tool documents output schema, critical for LLM planning. No error handling guidance, no pagination support despite potential for large result sets, no structured output format specified. get_alerts implementation is incomplete (pass statement). No tool annotations (readOnlyHint, etc.) despite both being READ_ONLY. Descriptions lack context on when to use each tool or what data structure is returned.

• Add output schema documentation to both tools. For get_forecast, specify: returns object with 'forecast_text' (string) and 'periods' (array of {name, temperature, temperatureUnit, shortForecast, windSpeed, windDirection}). For get_alerts, specify return structure (array of alert objects with id, title, severity, etc.).
• Expand descriptions to 80-150 characters. Example: 'Get the 3-day weather forecast for a location (latitude/longitude). Returns temperature, conditions, and wind for each period. Call this before get_alerts to check current conditions.'
• Implement get_alerts function. Currently returns None. Add logic to call NWS alerts API endpoint and return structured alert data with title, severity, and effective time.
• Add error handling with recovery guidance. Replace 'Error: Unable to get forecast data (Status: 200)' with 'Failed to fetch forecast for coordinates {lat},{lon}. Verify coordinates are valid (±90 lat, ±180 lon) and try again, or use search_location() to find valid coordinates.'
• Add readOnlyHint=true annotation to both tools in FastMCP decorator to signal they are safe for caching and aggressive retry.

Inferred effective spec: <=2025-11-25.

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API