Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Both tools have action-verb names (get-alerts, get-forecast) and non-empty descriptions (18-27 chars), meeting minimum naming standards. Input schemas are present with type constraints (state: 2-char string; lat/lon: numbers with min/max bounds), but parameter descriptions are minimal (10-20 chars) and lack context about when to use each tool or what the output structure contains. No documented output schemas, error handling guidance, or recovery paths. Tools are read-only (safe), but descriptions do not explicitly state this. Baseline: avg tool description 194 chars; these are 18-27 chars (p10 baseline). Avg param description 72 chars; these are ~15 chars.

• Document output schemas for both tools. Example for get-alerts: 'Returns {features: [{properties: {event, areaDesc, severity, status, headline}}]}'. Example for get-forecast: 'Returns {periods: [{name, temperature, temperatureUnit, windSpeed, windDirection, shortForecast}]}'.
• Expand tool descriptions to 100-200 chars. Example: 'Get active weather alerts for a US state. Returns event type, area description, severity, and headline. Use this to check for warnings before planning outdoor activities.'
• Add context to parameter descriptions. For latitude/longitude: 'Latitude (-90 to 90) and longitude (-180 to 180) in decimal degrees. Example: 37.7749, -122.4194 for San Francisco.'
• Replace state parameter examples with an enum of valid 2-letter US state codes, or document that invalid codes return an empty result with guidance to retry with a valid code.
• Add error handling: if NWS API fails, return a structured error like '{error: "NWS service unavailable", retry: true, message: "Try again in 30 seconds"}' instead of null.