Single tool 'query_weather' has a complete input schema with proper types and descriptions, meeting baseline requirements. However, the tool description is overly long (>1024 chars), violates the pattern guideline, and mixes implementation details (data sources, fallback logic) with user-facing intent. No output schema is documented, LLMs cannot predict the response structure. The tool performs a single, well-defined action (query weather), but lacks error handling guidance and does not declare whether it is read-only in the schema itself (only in metadata). Parameter descriptions are adequate but could be more concise.

• Refactor tool description to ~100-150 characters: 'Get current weather and forecast for any city worldwide. Supports Chinese and English city names. Returns temperature, conditions, humidity, wind, and multi-day forecast.' Move implementation details (Open-Meteo, wttr.in fallback) to internal comments.
• Document the output schema explicitly. Add a comment or docstring showing the response structure: { 'city': str, 'update_time': str, 'current': { 'weather': str, 'temperature': str, ... }, 'forecast': [ { 'date': str, 'weather': str, ... } ], 'data_source': str }.
• Add error handling guidance to the description: 'If the city is not found, try using the English name or a larger city nearby. Returns null if no match is found.'
• Add 'minimum': 1 and 'maximum': 7 to the 'days' parameter schema to enforce the constraint stated in the description.
• Consider renaming to 'get_weather_forecast' to be more explicit about the action (get) and primary output (forecast), following verb_noun convention.