Three tools with significant quality gaps. query_weather and query_database have verbose, example-heavy descriptions (500+ chars) that violate token efficiency and risk LLM literal reuse of examples. translate_ppt lacks any visible schema or parameter descriptions in source. All three tools lack error handling guidance, output schema documentation, and proper parameter constraints. No tool annotations (readOnlyHint/destructiveHint). Naming is acceptable (verb_noun pattern), but descriptions are poorly structured for LLM consumption.

• Rewrite query_weather description to ~100 chars: 'Get current weather for a city (temperature, humidity, wind speed). Accepts English city names.' Remove all example cities; use enum or pattern constraint for valid inputs instead.
• Rewrite query_database description to ~120 chars: 'Execute SELECT queries on sales database (regions, cities, products, quantities, prices). Returns formatted table. SELECT only, no INSERT/UPDATE/DELETE.' Remove SQL examples; document schema in a separate resource or discovery tool.
• Add parameter descriptions to translate_ppt: olang='Source language code (ISO 639-1: en, zh, ja, etc.)', tlang='Target language code (ISO 639-1)', file_path='Absolute or relative path to .pptx file'.
• Document output schemas: query_weather returns {city, country, temp_c, humidity_percent, wind_speed_ms, description}; query_database returns {columns: [...], rows: [[...]], row_count: int}; translate_ppt returns {output_file_path, status, translated_slides_count}.
• Add error handling guidance to all tools: 'If city not found, try a different spelling or use search_cities(). If SQL fails, check syntax and table/column names. If file not found, verify path and permissions.'