Two tools with clear verb-noun naming (get-alerts, get-forecast) and documented input schemas using Zod. Descriptions are present but minimal (10-40 chars). Parameters have type constraints (length, min/max) and descriptions. Output is unstructured text rather than typed objects. No error recovery guidance, no pagination support, no output schema documentation. Schemas are visible and properly constrained, but descriptions lack context on WHEN to use each tool or what the LLM should do with results.

• Expand tool descriptions to 80-150 chars. Example: 'Get active weather alerts for a US state. Returns event type, severity (minor/moderate/severe), affected area, and headline. Use this to check for warnings before planning outdoor activities.'
• Return structured JSON objects instead of formatted text. get-alerts should return {alerts: [{event: string, severity: enum, areaDesc: string, headline: string}], count: number}. get-forecast should return {location: {lat, lon}, periods: [{name, temperature, windSpeed, shortForecast}]}.
• Add error recovery hints. When NWS API fails, return: 'Failed to retrieve alerts for CA. The NWS API may be temporarily unavailable. Try again in a few seconds, or check a different state.' For invalid coordinates, return: 'Coordinates (lat, lon) are outside the US. NWS only covers US locations.'
• Document output schemas in tool descriptions or as a separate schema field. Example: 'Returns {alerts: Array<{event, severity, areaDesc, headline}>, count: number}.'
• Add limit parameter to get-alerts (default 20, max 100) and return pagination info: {alerts: [...], count: 150, limit: 20, offset: 0, hasMore: true}. This prevents token bloat and enables multi-page retrieval.