Two tools with basic descriptions and minimal parameter documentation. GetAlerts and GetForecast have short, action-oriented names and descriptions (18-30 chars), but lack critical details: no output schema documentation, no parameter constraints (e.g., valid state codes, lat/lon ranges), no error handling guidance, and no indication of what fields are returned. Parameter descriptions are present but minimal (10-20 chars). No tool annotations (readOnlyHint, etc.) despite both being read-only. Schemas are inferred from method signatures rather than explicitly documented. This is typical community-grade work, functional but not production-ready.

• Document output schema as structured JSON. GetAlerts should return {alerts: [{event, area, severity, description, instruction}]} or similar. GetForecast should return {periods: [{name, temperature, windSpeed, windDirection, detailedForecast}]}. This enables LLM field extraction and chaining.
• Add enum constraint for 'state' parameter in GetAlerts. List all 50 US state codes (AL, AK, AZ, ..., WY) so LLM picks valid values. Alternatively, accept state names and resolve internally.
• Add numeric range constraints for GetForecast: latitude -90 to 90, longitude -180 to 180. Include in parameter description: 'Latitude of the location (-90 to 90).'
• Expand parameter descriptions to 50-100 chars. E.g., 'The two-letter US state code (e.g., CA, NY, TX) for which to retrieve active weather alerts.' This matches baseline and guides LLM input.
• Add readOnlyHint: true to both tool schemas to signal safety. Include error recovery hints: 'If state not found, try search_states() or provide a two-letter code.' This guides agent retry logic.