Two tools with basic schemas and minimal descriptions. Both tools have input schemas with proper types and required fields, but descriptions are generic (under 100 chars) and lack context about when to use them, what they return, or error conditions. No output schemas documented. Parameters lack detail about valid ranges, formats, or dependencies. No error handling guidance. Tool names follow verb_noun pattern (positive), but descriptions do not explain prerequisites, return structure, or failure modes. Missing pagination guidance for get_alerts (could return many results). No idempotency or side-effect documentation.

• Expand tool descriptions to 100-200 chars. Include: what the tool does, when to use it (vs. alternatives), what it returns, and any prerequisites. Example: 'Get active weather alerts for a US state. Returns a list of alert events with severity, area, and instructions. Use this to check for warnings before planning outdoor activities. Requires a valid 2-letter state code (CA, NY, etc.).'
• Document output schemas. Define the structure returned by each tool (e.g., get_alerts returns {alerts: [{event, area, severity, description, instructions}], count, timestamp}). This enables LLMs to extract and chain data reliably.
• Add validation rules to parameter descriptions. For get_alerts: 'state: Two-letter uppercase US state code (e.g., CA, NY, TX).' For get_forecast: 'latitude: Number between -90 and 90. longitude: Number between -180 and 180.'
• Add error handling guidance. When NWS API fails, return structured errors: {error: 'API_UNAVAILABLE', message: 'Weather service temporarily unavailable. Retry in 30 seconds.', retryable: true}. This tells LLMs whether to retry or escalate.
• Add pagination to get_alerts. Accept optional 'limit' (default 10, max 50) and 'offset' parameters. Return {alerts: [...], total_count, has_more}. Cap results to prevent context window exhaustion.