Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. get_alerts has a single string parameter with minimal description; get_forecast has two numeric parameters with NO descriptions at all (null values visible in source). Neither tool documents return structure or error handling. Descriptions are present but generic (10-50 chars), below the 194-char baseline for production tools. No enum constraints, no pagination support, no error recovery guidance. Tool names follow verb_noun pattern (positive), but parameter quality is poor.

• Add descriptions to get_forecast latitude and longitude parameters. Example: 'latitude: Decimal latitude of the location (-90 to 90)' and 'longitude: Decimal longitude of the location (-180 to 180)'. Include valid range constraints.
• Document output schema for both tools. Define structured response objects with typed fields (e.g., Alert with event, areaDesc, severity, description, instruction; Forecast with name, temperature, windSpeed, detailedForecast). Return JSON objects, not free-text strings.
• Add pagination to get_alerts: include limit (default 20, max 100) and offset parameters. Return total_count and next_offset in response. Cap results to prevent context window exhaustion.
• Expand error handling. Validate state codes against a known list (all 50 US states + territories). Return 'Invalid state code: XY. Valid codes: AL, AK, AZ, ...' on failure. Catch HTTP errors from weather.gov API and translate to actionable messages.
• Replace example values in descriptions with enum constraints. Change get_alerts description from 'e.g. CA, NY' to a formal enum of valid state codes in the schema. Use JSON Schema pattern or enum array for state parameter.