Two tools with basic verb-noun naming (get_air_pollution, get_coordinates). Both have short descriptions (60-80 chars, below the 194-char baseline). Input schemas present with type strings and descriptions, but parameters lack format constraints, ranges, or validation guidance. No output schemas documented. Error handling is minimal, generic 500 errors with no recovery guidance. No tool annotations (readOnlyHint, etc.). Missing pagination, rate-limit guidance, and API key exposure in client-side code (script.js) is a critical security flaw.

• Move API_KEY from script.js to server-side environment variable (process.env.API_KEY). Remove hardcoded key from client code immediately.
• Document output schemas for both tools. For get_air_pollution, specify fields like {aqi: number, components: {co, no, no2, o3, so2, pm2_5, pm10, nh3}}. For get_coordinates, specify {lat: number, lon: number, name: string}.
• Expand descriptions to 100 - 150 chars. Example: 'Fetches air quality index (AQI) and pollutant concentrations (CO, NO₂, PM2.5, etc.) for a location. Returns AQI level (1 - 5) and component values in μg/m³. Use after get_coordinates to analyze air quality.'
• Add parameter constraints: lat/lon as number type with min/max -90/90 and ±180; city/country as strings with minLength 1, maxLength 100. Add format hints in descriptions: 'Latitude as decimal degrees (-90 to 90)'.
• Replace generic error responses with actionable messages. E.g., 'Location not found. Try a different city name or check spelling.' For API errors, return 'OpenWeatherMap API error: [reason]. Retry in 60 seconds or check your API key.'