Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Both tools have action-verb names (get-*) and non-empty descriptions (18-40 chars), meeting minimum bars. However, descriptions are below the 50-200 char LLM-optimized range. Parameter descriptions exist but lack detail on constraints, formats, and error recovery. Output schemas are not documented, LLMs cannot predict response structure. No error handling guidance. Zod schemas are present but not comprehensive.

• Expand tool descriptions to 80-150 chars. Example: 'get-alerts: Fetch active weather alerts for a US state (2-letter code). Returns event type, severity, area, and headline. Use when user asks about warnings or severe weather. US locations only.'
• Document output schema for each tool. Example: 'Returns {content: [{type: "text", text: string}]}. For get-alerts, text contains formatted alerts with event, area, severity, status, headline fields separated by ---.'
• Add error recovery guidance. Replace 'Failed to retrieve alerts data from NWS' with 'NWS API unavailable (HTTP {status}). Retry in 30s or check https://status.weather.gov. If coordinates invalid, verify latitude [-90,90] and longitude [-180,180].'
• Enhance parameter descriptions with constraints and context. Example for state: 'Two-letter US state code (e.g., CA, NY, TX). Must be uppercase. Used to query NWS alerts API for that state only.'
• Add result limits and pagination. Cap get-alerts to 20 most severe alerts; return total count and offer limit/offset parameters for full list retrieval.