Single tool 'open_weather_api' has a basic description but critical gaps in parameter documentation and output schema definition. The input schema references LocationQuerySchema (external file not shown), making it impossible to verify parameter types and constraints. No output schema is documented. The tool description is generic (34 chars) and lacks context on when to use it, what it returns, or error handling. No error recovery guidance. Naming is acceptable but description quality is well below the 194-char baseline for production tools.

• Define and document LocationQuerySchema inline or in registerWeatherTools.ts. Include type (string), min/max length, format (e.g. 'city name, country code or coordinates'), and examples of valid inputs.
• Expand tool description to 100-200 chars: 'Fetch current weather for a location. Accepts city names (e.g. "London"), coordinates ("40.7128,-74.0060"), or zip codes. Returns temperature, humidity, wind speed, and conditions. Call this when the user asks about weather.'
• Document the output schema as a JSON object with typed fields: { temperature: number (Celsius), humidity: number (0-100), wind_speed: number (m/s), condition: string, location: string, timestamp: ISO8601 }.
• Add error handling: catch API failures (invalid location, rate limit, network timeout) and return structured errors with recovery hints. E.g. 'Location "Xyz" not found. Try a major city name or coordinates.'
• Add parameter constraints: locationQuery should be required, 1-200 chars, and accept city names, coordinates, or zip codes. Document this in the parameter description.