Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output structure. Both tools have verb-noun naming (get-alerts, get-forecast) which is correct. Descriptions exist but are minimal (18-27 chars, below the 50-200 char LLM-optimized baseline). Input schemas use Zod with type constraints (latitude/longitude bounds, state length), but lack detailed parameter descriptions beyond the constraint hints. No output schema documentation. Error handling returns text responses but lacks actionable recovery guidance. No tool annotations (readOnlyHint, idempotentHint). Tool composition is reasonable, each does one thing, but responses are unstructured text rather than typed objects.

• Expand tool descriptions to 80-150 chars. Example: 'get-alerts: Retrieve active weather alerts for a US state. Returns event type, affected area, severity level, and headline. Use when user asks about weather warnings or hazards.'
• Document output schema explicitly. Add to tool registration or README: 'Returns {content: [{type: "text", text: string}]}. Text contains formatted alert/forecast data. Consider returning structured JSON with typed fields (alerts: {event, area, severity, status, headline}[]) for better LLM parsing.'
• Add parameter descriptions explaining constraints and error cases. Example: 'state: Two-letter US state code (CA, NY, TX). Invalid codes return error; try search_states() if unsure.'
• Enhance error messages with recovery hints. Example: 'Failed to retrieve forecast for coordinates. NWS API only covers US locations. Verify latitude/longitude are within US bounds (-125 to -66 longitude, 24 to 50 latitude).'
• Add readOnlyHint annotation to both tools in server.tool() registration to signal idempotency and safe retry behavior to agents.