An AI-powered travel assistant built with LangChain and LangGraph that handles flight bookings, hotel reservations, car rentals, and travel recommendations. Features a hierarchical agent architecture with a primary assistant delegating to specialized sub-assistants.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server exhibits significant quality gaps across naming, descriptions, parameter documentation, and output schemas. While 16 tools are defined with basic descriptions and some parameter info, most descriptions lack depth and actionability. Parameter schemas are inconsistently documented, some parameters have type info but lack descriptions, and many critical output schemas are not visible in the source code. No error handling guidance is present. The tool definitions appear functional but fall well short of production-grade quality. Average per-tool score: 42/100.
Output schemas undocumented across all tools. No visible schema definitions for return types, field names, or structure. LLMs cannot plan downstream tool calls or extract required data (e.g., what fields does search_flights return? Is there pagination?). Critical for tool chaining.
Parameter descriptions missing or incomplete. Many parameters (e.g., location, name, details) lack actionable guidance on format, constraints, or examples. 'location' appears in 3+ tools but is never described beyond 'The location'.
Document output schemas for every tool. Specify what fields are returned, their types, and what IDs/references they include for chaining (e.g., search_flights should return flight_id, departure_airport, arrival_airport, scheduled_departure, etc.). Example: { flight_id: int, flight_no: string, departure_airport: string, arrival_airport: string, scheduled_departure: string (ISO 8601), available_seats: int, price: float }
Add parameter descriptions for all optional parameters. For each of location, name, start_date, end_date, describe: expected format (ISO 8601 for dates), examples, and constraints. E.g., 'location (optional): City or airport name, e.g. "New York" or "JFK". If omitted, searches all locations.'
Implement pagination for search tools. Add offset/limit or cursor parameters and return total_count. E.g., search_flights should return { flights: [...], total_count: 42, has_next: true, next_cursor: "abc123" }. Document the default limit (currently 20) and max limit.
Add error response documentation. For each tool, document possible errors: 'Not found' (404), 'Invalid input' (400), 'Permission denied' (403), etc. Provide recovery guidance. E.g., 'If rental_id not found, call search_car_rentals to find the correct ID.'
Replace destructive operations with confirmation step. Before cancel_ticket, cancel_car_rental, etc., implement a dry_run parameter or separate confirm_cancel_ticket tool. Return: { can_cancel: bool, reason?: string, tickets_affected: int }. Only proceed after explicit confirmation.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error handling or recovery guidance. No documentation of what errors each tool can produce (e.g., 'rental_id not found', 'date conflict'), what they mean, or how the agent should respond. Code shows basic error messages in tools/car_tools.py but no schema for error responses.
Destructive operations lack confirmation or dry-run support. Tools like cancel_ticket (DESTRUCTIVE risk), cancel_car_rental, cancel_hotel, and cancel_excursion can delete data without explicit user confirmation. No dry-run option visible. Agents can cause irreversible data loss.
Search tools lack pagination. search_flights has a 'limit' parameter (default 20) but no offset, cursor, or next_token field mentioned. Large result sets could overflow context. search_car_rentals, search_hotels, search_trip_recommendations have no pagination visible.
Parameter constraints not formally specified. Optional parameters marked 'optional' with comment 'Default: None' but no format, range, or enum constraints visible in schema. E.g., date parameters (start_date, end_date) lack format (ISO 8601?), and price_tier is commented out, leaving ambiguity.
fetch_user_flight_information requires config.configurable.passenger_id but passes config as a typed 'object' parameter. The schema describes it as 'RunnableConfig object', too vague. How should an LLM or client construct this? This breaks composability.
Tool descriptions are generic and lack 'WHEN' guidance. E.g., 'Update car rental' does not say when to use it, when search_car_rentals should be called first, or what update_car_rental does that modify_car_rental does not. LLMs cannot disambiguate similar tools.
No permission/scope documentation. Tools that modify state (book_*, update_*, cancel_*) do not declare what permissions they require (e.g., 'write:bookings'). No audit trail or logging of who called what. Non-compliant with pattern:scope-declaration and pattern:audit-trail.
Naming ambiguity: 'update_excursion' vs 'book_excursion' is clear, but 'update_car_rental' vs 'update_ticket_to_new_flight' is inconsistent in verb. One uses 'update', the other uses 'update_to_new'. Similar operations (change dates vs change flight) should follow the same naming pattern.
Standardize parameter naming and descriptions across similar tools. Use update_* consistently (not update_to_new_*). Ensure all search tools have the same optional parameters: location, name, and date_range or date_from/date_to (not mixed start_date/end_date for cars and flights).
Document the config parameter for fetch_user_flight_information and update_ticket_to_new_flight. Specify the exact structure: config = { configurable: { passenger_id: string } }. Or better: accept passenger_id as a direct parameter instead of hidden in config.
Add 'WHEN to use this tool' guidance to descriptions. E.g., update_car_rental: 'Use this to change the dates of an existing car rental after booking. Call search_car_rentals first to get the rental_id.'
Declare scope/permissions for each tool. Tools that modify state should include: 'Requires scope: write:bookings'. Tools that read only should include: 'Read-only; no auth required.' Example: book_car_rental -> 'Requires scope: write:bookings. Creates a new booking.'
Add per-item error reporting for batch operations. If a single search result has a data quality issue, report it separately rather than failing the entire search. E.g., search_flights -> { flights: [...], warnings: [{ flight_id: 5, issue: 'price missing' }] }