Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output structure. Both tools have descriptions (10-20 chars baseline met), and input schemas are present with Zod validation. However, parameter descriptions lack detail on constraints, error handling is minimal, and output schemas are not formally documented. No tool annotations (readOnlyHint, idempotentHint). Error responses are generic text without recovery guidance. Naming is clear (verb_noun pattern: get-alerts, get-forecast) but descriptions are terse. No pagination, no structured output documentation.

• Expand tool descriptions to 80-150 characters. Example: 'get-alerts: Retrieve active weather alerts for a US state (2-letter code). Returns event type, severity, area, and headline. Use when user asks about weather warnings or hazards.'
• Document output schema explicitly. Define return structure: {alerts: [{event, severity, area, headline, status}]} for get-alerts; {forecast: [{period, temperature, windSpeed, shortForecast}]} for get-forecast. Include in tool docstring or separate schema file.
• Add constraint details to parameter descriptions. Example: 'state: Two-letter US state code (e.g., CA, NY). Must be uppercase. Only US locations supported.' Include valid range or enum if applicable.
• Implement actionable error messages with recovery hints. Example: 'Failed to retrieve alerts for CA. Verify state code is valid (2 uppercase letters). If error persists, try a different state or check NWS API status.'
• Add tool annotations to schema. Mark both tools with readOnlyHint=true and idempotentHint=true in the tool registration to signal safety properties to LLMs and enable confident retries.