Server defines 7 tools with complete input schemas and descriptions. Naming follows verb_noun pattern (bus_arrival, station_crowding, etc.). Descriptions are present (avg ~120 chars) but lack actionable context, they state WHAT but not WHEN to use or prerequisites. Parameters are typed with enums where appropriate (trainLine), but several tools accept no parameters and lack output schema documentation. Error handling returns API errors but does not guide recovery. No tool annotations (readOnlyHint, idempotentHint). Output is raw JSON from LTA API, not shaped for agent consumption.

• Add output schema documentation for each tool. Example for bus_arrival: 'Returns {Services: [{ServiceNo, NextBus: {EstimatedArrival, Load, Feature}, ...}], odata.metadata}'. Describe which fields agents should extract.
• Enhance descriptions with WHEN and WHY context. Example: 'Get real-time bus arrival for a specific stop. Use this to help users find the next bus. Requires a valid 5-digit bus stop code (e.g., 17009); call search_bus_stops() if you only have a location name.'
• Add tool annotations. Mark all 7 tools with readOnlyHint: true since they only read data. This signals to agents that retries are safe.
• Improve error messages with recovery guidance. Instead of 'LTA API error: Invalid BusStopCode', return 'Invalid bus stop code. Valid codes are 5 digits (e.g., 17009). Try search_bus_stops() with a location name or area.'
• Document result limits and pagination. For carpark_availability and traffic_incidents, specify 'Returns up to 100 results; call with offset/limit parameters for pagination' (if API supports it) or 'Returns all available carparks; results may be large, consider filtering by location.'
• Add parameter descriptions for tools with no parameters. For train_alerts, add 'No parameters required. Returns all active service alerts across all train lines.' This clarifies that the tool is a discovery endpoint.