The server provides 19 well-organized read-only tools for Hong Kong climate and weather data. All tools have descriptions and most have proper parameter schemas with types and constraints. However, the descriptions are often quite generic (averaging ~50-70 chars for tool descriptions, well below the optimal 50-200 char range for LLM clarity), and parameter descriptions lack critical guidance on valid ranges, formats, and dependencies. Output schemas are not documented, LLMs cannot see what fields to expect from API responses. Error handling is minimal; no recovery guidance or actionable error messages are evident in the code. Tool names follow the verb_noun pattern correctly (get_*), but several parameter descriptions are perfunctory. The 'options' object in tide and other tools uses an unstructured approach rather than flattened parameters, making schema clarity harder. Security posture is good (read-only, no credentials exposed), but descriptions for multi-language support (lang parameter) could better explain when each language is available. Composition is excellent, single-responsibility tools that chain well via station/year/date patterns.

• Expand tool descriptions to 100-150 characters each, adding explicit WHEN to use (e.g., 'Call this to get past/future lunar calendar dates for scheduling Chinese festivals.' for get_gregorian_lunar_calendar). Include what data is returned so LLMs know whether to call this or a sibling tool.
• Document output schemas for every tool. Add a Returns section to the tool docstring (visible in MCP schema) that lists expected fields and their types. Example for get_moon_times: 'Returns dict with keys: fields (list of column names), data (list of [datetime, rise_time, transit_time, set_time] tuples)'.
• Add explicit parameter constraints in descriptions. Replace 'Optional year (varies by station)' with 'Year (1961-present for HKO; check get_temperature_station_metadata for other stations). If omitted, defaults to current year.'
• Flatten nested 'options' object. Change get_hourly_tides signature to accept month, day, hour, lang as top-level optional parameters instead of a single options dict. This matches the schema clarity of other tools.
• Implement error handling wrapper. When API calls fail (e.g., invalid station, out-of-range year), catch the error and return a structured response like {'error': 'Invalid station code: XYZ', 'valid_codes': ['CCH', 'WGL', ...], 'recovery': 'Call get_tide_station_codes() to list valid codes.'}.
• Add a discovery/metadata tool if not already present. Tools like get_temperature_station_metadata(), get_radiation_station_list_with_year_ranges() would let agents self-discover valid parameters before calling the main tools, reducing failed calls.