Strong tool definitions with comprehensive descriptions and well-structured schemas. All 8 tools have clear action verbs and detailed parameter documentation. Descriptions average ~180 chars, within the 10-1024 baseline. All parameters include type definitions and descriptions. Output schemas are documented in descriptions. Error handling is present but could be more explicit about recovery paths. Tool composition is clean, each tool has a single responsibility. Main gaps: no explicit enum constraints for some parameters (e.g., lot_type in get_carpark_availability), and error responses lack actionable recovery guidance in some cases.

• Convert lot_type in get_carpark_availability to an enum: {"type": "string", "enum": ["C", "Y", "H"], "description": "Lot type: C=car (default), Y=motorcycle, H=heavy vehicle"}
• Expand get_train_alerts description to include: what fields are in the response (line name, disruption type, severity, affected stations), typical use case (checking if a line is affected before commuting), and whether it returns historical or real-time data only.
• Add explicit format guidance to find_route from_place/to_place: 'Accepts place name (e.g., "Marina Bay Sands") or coordinates as "latitude,longitude" (e.g., "1.2816,103.8636").'
• Document mutual exclusivity in search_bus_stops and get_carpark_availability: 'If both query and latitude/longitude are provided, geographic search takes precedence and text search is ignored.'
• Enhance error descriptions in tool docstrings with recovery paths: e.g., 'If bus stop not found, call search_bus_stops() first to locate the stop code.' This guides LLM retry logic.