Two tools with basic verb-noun naming (get_alerts, get_forecast) but significant quality gaps. Both have minimal descriptions (under 100 chars) lacking context on when to use them or what they return. Input schemas present but incomplete: get_alerts lacks validation rules for state codes; get_forecast has no bounds on latitude/longitude. No output schemas documented. get_forecast implementation is incomplete (commented-out logic, hardcoded ['nice day'] response). No error handling guidance, no pagination support, no structured output documentation. Tools are READ_ONLY but lack explicit idempotent hints. Overall definition quality is below community baseline (median ~45-55).

• Add enum constraint to get_alerts 'state' parameter with all 50 US state codes (AL, AK, AZ, ..., WY). Document: 'Two-letter US state code (e.g., CA, NY, TX). Must be one of: [list]'.
• Add bounds to get_forecast latitude/longitude: latitude -90 to 90, longitude -180 to 180. Document: 'Latitude of the location (-90 to 90 degrees)' and 'Longitude of the location (-180 to 180 degrees)'.
• Expand tool descriptions to 150-250 chars. Example for get_alerts: 'Retrieve active weather alerts for a US state. Returns event type, severity, affected area, and instructions. Use this to check for warnings before planning outdoor activities or travel.'
• Document output schemas explicitly. For get_alerts, specify: returns string with formatted alerts (Event, Area, Severity, Description, Instructions fields). For get_forecast, specify: returns array of forecast periods with name, temperature, wind, and detailed forecast.
• Implement proper error handling with recovery guidance. Replace silent None returns with specific errors: 'Invalid state code: got "XX". Must be a valid 2-letter US state code (e.g., CA, NY).' or 'NWS API unavailable (timeout after 30s). Try again in 1 minute.'