Two tools with basic schemas and descriptions, but significant gaps in error handling, output documentation, and parameter constraints. Tool names follow verb_noun convention (get-alerts, get-forecast), which is good. Descriptions are present but minimal (10-40 chars baseline; these are 30-40 chars). Input schemas use Zod with type constraints (latitude/longitude bounds, state length), but output schemas are not documented, LLMs cannot predict response structure. Error handling returns text blobs without actionable recovery guidance. No tool annotations (readOnlyHint, idempotentHint). Missing pagination for alerts (could return hundreds). No rate limiting or timeout documentation.

• Expand tool descriptions to 80-150 chars. Include: what the tool does, when to use it (e.g., 'Call this to check active weather warnings for a US state'), what it returns (e.g., 'Returns event type, severity, headline, and affected area'), and any limitations (e.g., 'Only supports US states; returns empty list if no active alerts').
• Document output schemas explicitly. Define the structure of the response object, including field names, types, and meanings. E.g., for get-alerts: {features: [{event: string, areaDesc: string, severity: string, status: string, headline: string}], total: number}.
• Add pagination to get-alerts: accept optional 'limit' (default 20, max 100) and 'offset' (default 0) parameters. Return total count and next_offset in response so agents can iterate through large alert lists.
• Improve error messages with recovery guidance. Instead of 'Failed to retrieve alerts data', return 'Failed to retrieve alerts for CA (HTTP 500). This may be a temporary API outage. Retry in 30 seconds, or try a different state.' Include the invalid value and constraint violated.
• Add tool annotations via MCP SDK. Mark both tools with readOnlyHint=true and idempotentHint=true so agents know they are safe to retry and do not modify state.