BRIJ

travel_book_flight

Pay the escrow and request booking with passenger details. Booking is ASYNCHRONOUS: a successful response means the request was accepted, not that the ticket is issued. After this call, poll travel_get_booking_intent until intent.status is 'booked' (ticketed) or 'refunded' (booking failed and escrow was auto-refunded). Pass passengers as an array with LEAD FIRST — the lead receives all emails and refund requests authenticate against the lead's family name. The count MUST equal the offer's passenger_count (= adults searched); duplicate travellers (same name + birth date) are refused with 400 duplicate_passenger. Round-trip offers cover both directions with a single /air/book and a single escrow. The airline rejects malformed passenger fields (title not lowercase, gender not m/f, phone not E.164, …) with a 400; fix the field per the response and retry. Three 409 codes are checked BEFORE x402 settlement (refusal is free, no USDC spent): intent_expired (booking window closed — start a fresh travel_search_flights → travel_create_booking_intent flow), offer_expired (the offer left the airline's inventory — same fix, re-search), offer_repriced (live airline price no longer matches the intent; detail carries expected_ticket_amount and current_ticket_amount — quote the delta to the user and, if they accept, re-run travel_create_booking_intent so the escrow is sized to the new price). If a prior /book succeeded for this intent, retrying returns 409 booking_already_requested — do not retry; poll travel_get_booking_intent instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`intent_id`	Yes	Booking intent ID returned by travel_create_booking_intent.
`passengers`	Yes	Passenger list, 1 to 9 entries, LEAD PASSENGER FIRST. Must contain EXACTLY as many entries as the offer's passenger_count (= adults searched); a mismatch is rejected. The lead passenger (index 0) receives all booking emails, and refund requests authenticate against the LEAD's family name. Duplicate travellers (same given_name + family_name + born_on) are refused with 400 duplicate_passenger. All refunds are all-or-nothing per booking; there is no per-passenger cancellation.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so the description carries the full burden. Discloses asynchronous nature, escrow payment, free refusal before x402 settlement, auto-refund on failure, duplicate passenger rejection, malformed field 400s, and the three pre-settlement 409 codes. Rich behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and async behavior, then groups passenger requirements and error codes. Length is justified by the tool's complexity, though the passenger paragraph largely restates schema content, preventing a top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations but an output schema, the description supplies the missing behavioral context: async resolution, polling sibling, escrow semantics, and full error taxonomy. Complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and already documents intent_id and all passenger constraints (lead first, count, duplicates, all-or-nothing refunds). The description repeats these passenger semantics without adding new parameter-level meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action: pay escrow and request booking with passenger details. Distinguishes from sibling travel_create_booking_intent by indicating this is the booking request step and names travel_get_booking_intent for polling. Very clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides detailed when/when-not guidance: after intent creation, poll travel_get_booking_intent after this call, and explicit remediation for 409 codes (re-search, re-create intent, do not retry already-requested). Names alternatives travel_search_flights and travel_create_booking_intent for expired intents.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All BRIJ tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?