Five tools with complete input schemas and descriptions, but quality is uneven. All tools have verb-noun naming (check_, reserve_, confirm_, process_, manage_) and documented parameters with types. However, descriptions are generic (avg 60 chars, well below the 194-char baseline), lack WHEN/WHY context, and omit critical state-change warnings. Parameter descriptions are minimal (avg 35 chars vs 72-char baseline). No output schemas documented. Error handling and recovery guidance absent. Risk annotations present but not leveraged in descriptions.

• Expand tool descriptions to 100 - 200 chars. For reserve_flight: 'Reserve seats on a flight for passengers. Call check_availability first to verify seat count. Returns booking_number for use with confirm_booking. Fails if insufficient seats or invalid passenger data.'
• Document output schemas for all tools. E.g., check_availability returns {available_seats: int, total_seats: int, flight_id: int}. This enables LLMs to chain calls (reserve_flight → confirm_booking → process_payment).
• Add enum constraint to manage_reservation.action: {type: 'string', enum: ['view', 'cancel']}. Add description: 'Action to perform: view returns current reservation details; cancel requires reason parameter.'
• Enhance parameter descriptions with format/constraint hints. E.g., passengers: 'Array of passenger objects, each with required fields: first_name (string), last_name (string), email (string), date_of_birth (YYYY-MM-DD).'
• Add error recovery guidance to WRITE tools. E.g., process_payment: 'If payment fails, check error message for reason (insufficient funds, invalid card, etc.). Retry is safe, operation is idempotent by booking_number.'