Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and error handling. Tool names follow verb_noun convention (getWeather, getWeatherForecast), which is good. However, descriptions lack actionable context for LLM selection. Parameter descriptions exist but are generic. No output schema documented. No error handling guidance. No tool annotations. Schemas are present but incomplete, missing validation rules, ranges, and format constraints. The 'location' parameter accepts optional free-form strings without guidance on valid formats (city name vs coordinates vs zip code). The 'options' object is nested but lacks clear dependency documentation.

• Document complete output schema for both tools. Specify all returned fields (obsTime, temperature, humidity, conditions, wind*, pressure, visibility, cloud, dewPoint, updateTime), their types (string, number, object), and units. Example: {obsTime: string (ISO 8601), temperature: number (°C or °F based on units param), conditions: string, ...}
• Add validation constraints to location parameter. Specify accepted formats: 'City name (e.g., Beijing), zip code (5-6 digits), or coordinates (lat,lon format: 39.9,-116.4). If ambiguous, city name is preferred.'
• Add error handling guidance to tool descriptions. Example: 'If location is not found, returns error with available alternatives. If API key is missing, returns 401 Unauthorized, configure QWEATHER_API_KEY environment variable.'
• Constrain days parameter in getWeatherForecast to enum [3, 7] instead of free-form number. Update description: 'Number of days to forecast: 3 or 7 (default: 3).'
• Add tool annotations (readOnlyHint) to both tools since they only read weather data and do not modify state. This helps agents understand retry safety.