Four tools with complete input schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention (scrape_, compare_, forecast_). Descriptions are present (60-120 chars) but lack actionable context for LLM selection, they state WHAT but not WHEN or WHY. Parameters have types and ranges (days 1-90, horizonDays 1-30) but lack dependency documentation (e.g., relationship between trainDays and horizonDays). No output schemas documented. Error handling and recovery guidance absent. No tool annotations (readOnlyHint/destructiveHint). Security: scrape_city performs WRITE operations (MySQL upsert) but no permission gates or audit trail visible in code.

• Document output schema for each tool. Example for compare_cities: {type: 'object', properties: {cities: [{name, n_points, mean_pm25, min_pm25, max_pm25}], best_city, worst_city}}. This enables LLMs to chain results into downstream calls.
• Expand descriptions to 100-150 chars with WHEN/WHY. Example: 'Compare air quality across multiple cities over N days. Use this to identify the cleanest and most polluted cities before deciding where to forecast. Returns KPIs (mean PM2.5, min/max) and rankings.'
• Add tool annotations to input schema. Mark scrape_city with destructiveHint: true; mark compare_cities and forecast_* with readOnlyHint: true. This signals to LLMs which tools have side effects.
• Document parameter dependencies. Example: 'trainDays must be >= 7 and <= 120. horizonDays must be >= 1 and <= 30. For best results, trainDays should be 3-4x horizonDays.' This prevents invalid combinations.
• Add error recovery guidance to descriptions. Example for scrape_city: 'If the city is not found, try search_cities() first. If the API times out, retry after 30 seconds. If MySQL write fails, check database connectivity.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry