Server has solid naming conventions (all tools start with action verbs like search_, get_, book_, cancel_, estimate_, update_, add_) and comprehensive parameter schemas using Zod with type definitions and descriptions. Tool descriptions are present and reasonably detailed (100-200 chars), clearly explaining what each tool does. However, there are critical gaps: (1) Output schemas are NOT documented, responses are wrapped in generic JSON.stringify() with no structured schema definition, forcing LLMs to parse unstructured text; (2) Tool descriptions lack guidance on when to use one tool vs another (e.g., search_rides vs estimate_fare distinction unclear); (3) No pagination support for search_rides despite potentially large result sets; (4) Parameter constraints could be more explicit (e.g., coordinates should document valid ranges); (5) Error handling returns JSON-wrapped error messages but lacks recovery guidance or error classification (retryable vs fatal); (6) No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk levels (WRITE, REVERSIBLE, READ_ONLY); (7) Security: passenger phone numbers are exposed in parameters and responses, sensitive data handling not documented.

• Document output schemas explicitly. For each tool, define the response structure (e.g., search_rides returns {rides: [{ride_id, driver_name, eta_minutes, fare_range, vehicle_type}], total_count, next_cursor}). Do not rely on JSON.stringify(), publish structured schemas.
• Add tool annotations. In server.ts, register tools with {readOnly: true} for GET operations and {destructive: true} for DELETE/CANCEL operations. Example: server.tool(..., {}, {...}, {readOnly: true}).
• Enhance error handling. Catch specific error types and return structured errors: {error: true, code: 'INVALID_RIDE_ID', message: '...', retryable: false, nextSteps: 'Call search_rides to find available rides.'}
• Add pagination to search_rides. Accept limit (1-50, default 20) and offset parameters. Return {rides: [...], total_count: 150, next_offset: 20}.
• Mask sensitive data in responses. For book_ride, return driver_phone masked (e.g., '+234***5678') and passenger_phone masked in ride_status. Document PII handling in tool descriptions.
• Clarify tool intent overlap. update_ride description: 'Change destination of an ACTIVE ride (already booked). If no ride is active yet, use search_rides or book_ride instead.'
• Document coordinate constraints. Add to all latitude/longitude parameters: 'Latitude: -90 to 90. Longitude: -180 to 180. Scope: Sub-Saharan Africa.'
• Add confirmation for book_ride and cancel_ride. Add optional dry_run: boolean (default false) parameter. When true, return confirmation details without executing. Or create separate confirm_booking(ride_id) and confirm_cancellation(ride_id) tools.