Three weather tools with complete input schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools have descriptions (10-50 chars), but descriptions are minimal and lack context on when to use each tool vs. alternatives. Parameters like 'npub' and 'dpop_token' are documented but their relationship and mutual dependency is unclear. No output schema is documented in the source code. Error handling and recovery guidance are absent. The tools follow a consistent naming pattern (verb_noun) but lack the depth expected for production use.

• Document output schema for each tool. Example for 'current': 'Returns {temperature: float (°F), windspeed: float (mph), weathercode: int, ...}'. Include all fields the LLM might need.
• Expand tool descriptions to 80-150 characters. Example: 'Get current weather conditions (temperature, wind, precipitation) for a location. Use this for real-time conditions; use forecast() for multi-day outlook.'
• Clarify 'npub' and 'dpop_token' relationship. If both are required, remove defaults and mark required=true. If one is optional, document the fallback behavior.
• Add min/max constraints to numeric parameters in schema. For 'days', set minimum=1, maximum=16. For latitude/longitude, set minimum=-90/180, maximum=90/180.
• Add error handling examples in docstrings: 'If coordinates are out of range, returns error with valid bounds. If API timeout, retry with exponential backoff.'