Single tool 'get_weather' has critical definition gaps. Tool name is acceptable (verb_noun pattern), but description is minimal (34 chars, below 50-char baseline for clarity). Input schema exists but lacks parameter description, 'city' has no guidance on format, valid values, or examples. Output is unstructured JSON string with no documented schema. No error handling guidance. Tool returns None on exception without actionable recovery hints. Violates 6+ core patterns: tool-description, constrained-input, response-shaper, recovery-guide, error-classification, and audit-trail.

• Expand tool description to 100-150 chars: 'Get current weather for a Chinese city by name. Returns temperature, weather condition, wind speed, and humidity. Requires AMAP_API_KEY environment variable. Call this to answer weather queries for mainland China cities.'
• Add parameter description for 'city': 'Chinese city name (e.g., Beijing, Shanghai, 北京). Accepts both English and Chinese characters. City must exist in mainland China.'
• Document output schema in docstring: 'Returns JSON object with fields: temperature (°C), weather (string), wind_speed (km/h), humidity (%), update_time (ISO 8601).'
• Replace bare None return with structured error: 'return {"error": "Failed to fetch weather", "city": city, "recovery": "Verify city name is valid and AMAP_API_KEY is set. Retry with a different city name."}' and return as JSON string.
• Add input validation: check that city is non-empty and under 50 chars; return clear error if invalid before calling external API.