JournAI Flight Booking Service

Problem

Booking a flight can look like one search and one checkout, but the real flow spans multiple API steps: search flights, fetch offers, create an order, query ticket numbers, calculate refund fees, submit refunds or reroutes, and manage invoices. Several parameters are tightly coupled, such as priceId, flightInfoId, orderSource, ticketId, tripId, and voucherOrderInfo, and must be taken from upstream responses. Domestic and international orders also use different fields. Manually assembling these requests can easily produce business errors or unintended bookings and refunds.

How It Works

The skill calls the JournAI flight MCP tools through JSON-RPC, authenticates with Authorization: Bearer $HUOLI_API_KEY, and checks whether result.structuredContent.code is 0 before treating a response as successful. Core capabilities include:

• Flight search: query by date, city or airport, price, direct flights, transfers, cabin, and apply explicit sortBy and sortOrder when users mention time or price preferences.
• Booking flow: move from search_flights to get_flight_offers, then to uni_order_create, keeping priceId, flightInfoId, and orderSource traceable.
• Refund and reroute: execute refunds through uni_order_query → refund_query_fee → user confirmation → refund_submit, and reroutes through uni_order_query → reroute_query_flight_filter → reroute_confirm → user confirmation → reroute_submit.
• Invoice handling: use query_invoiceable, submit_invoice, query_invoices, and manage_invoice to query, submit, and manage reimbursement vouchers, checking canCancel, canUpdate, and canResend before mutations.

Write operations such as uni_order_create, uni_order_cancel, refund_submit, reroute_submit, submit_invoice, and manage_invoice require user confirmation before calling. When multiple choices exist, the user should choose rather than the model deciding automatically.

Boundaries

This is useful when a HUOLI_API_KEY is available and the assistant needs strict sequencing, parameter validation, and user confirmation for flight-related actions. Note that user identity is bound to the API key rather than passed as a parameter; domestic orders often rely on ticketIds, while international orders may require tripInfoList and contacts; empty search results should be handled by paging, increasing pageSize, or adjusting dates or airports; and monetary or ticket-state changes must preserve the confirmation step.