TravelKit Flight Assistant

Problem

Flight service workflows often split search, pricing, order creation, payment, order lookup, refund/change, invoices, and itinerary downloads across multiple APIs or tools. Direct integration can create three failure modes: collecting passenger details before price verification, exposing internal fields or raw error payloads to users, and mixing read-only actions with write actions without clear confirmation. TravelKit Flight Assistant organizes the flow as an intent-based routing workflow.

How It Works

It routes each user intent to the minimum needed reference and tools: flight_search for flight search, flight_pricing for known flight numbers, and flight_verify_solution for real-time price verification. Only after successful verification and user confirmation does it proceed to flight_create_order or flight_pay_order. Later stages cover flight_order_list, flight_get_order_invoice_application, flight_cancel_order, flight_refund_request, flight_change_request, and flight_download_itinerary.

Key constraints include collecting route, dates, passenger counts, cabin, and preferences at search time; deferring ID, passport, phone, and email until after price verification; displaying total price as fare + tax; and requiring explicit confirmation before write actions such as creation, payment, cancellation, refund, or change requests.

Boundaries

It is useful for orchestrating flight business workflows, not as a raw API manual. If baggage, refund/change policy, deadlines, fees, or status data are not returned, state that they were not returned instead of inventing values. Missing or invalid TRAVELKIT_API_KEY should be treated as a platform credential issue, without outputting local MCP configuration snippets.