Server defines 7 tools with basic descriptions and partial schemas. All tools have names starting with action verbs (list_, get_, unlock_) and descriptions present. However, most parameter descriptions are minimal (1-5 words), input schemas lack detail, and output schemas are not documented. No error handling guidance, no parameter constraints (enums, ranges), and no documentation of return structures. Tool descriptions average ~40 chars, well below the 194-char baseline for production tools. Parameters lack type information in descriptions (e.g., 'The station number' doesn't specify integer range or valid values). No evidence of idempotency hints, permission gates, or recovery guidance.

• Document output schemas for all tools. For list_stations, specify: returns array of {station_number: int, name: string, available_bikes: int, available_stands: int, location: {lat: float, lon: float}}. For get_station, return single station object with same fields.
• Expand parameter descriptions to 50-100 chars with constraints. E.g., 'station_number: The numeric ID of the station (1-500, integer). Use list_stations to discover valid IDs.' instead of 'The station number'.
• Add pagination to list_stations, list_bikes, list_trips. Include limit (default 20, max 100), offset, and total_count in response. Document: 'Returns paginated results; call multiple times with offset to fetch all stations.'
• Add error recovery guidance to tool descriptions. E.g., unlock_bike: 'Unlocks a bike for use. Returns error if bike not found (try list_bikes first), already unlocked, or user lacks permission. Errors are retryable.'
• Add idempotency and confirmation hints to unlock_bike. Document: 'This operation is idempotent, calling twice with same bike_number is safe. Consider confirming with user before unlocking to prevent accidental bike reservations.'