Both tools have minimal descriptions (under 100 chars) and identical single-parameter schemas with no type constraints. Naming is acceptable (verb_noun pattern), but parameter descriptions are trivial ('Name of the city'). No output schema documentation, no error guidance, no pagination support despite potentially returning multiple results. Tools return unstructured strings rather than structured JSON. No input validation, no enum constraints, no format specifications. Error handling is present but returns bare strings without recovery guidance.

• Add structured JSON output schemas. Return objects with typed fields (city, temperature, humidity, description, forecast_day, etc.) instead of formatted strings. Document the schema in tool descriptions.
• Enhance parameter descriptions: 'city_name (string): Name of an Argentine city. Case-insensitive. E.g., Buenos Aires, Córdoba, Mendoza. Partial matches not supported.'
• Expand tool descriptions to 150-250 chars. Explain when to use each: 'get_weather returns current conditions; get_forecast returns 5-day outlook. Call get_weather for immediate conditions, get_forecast for planning.'
• Replace bare error strings with structured error objects: {"error": "city_not_found", "message": "City 'InvalidCity' not found", "available_cities": ["Buenos Aires", "Córdoba"], "retry": false}
• Add city_name enum or validation. Query the SMN API once at startup to cache valid Argentine city names, then validate input against that list before making requests.