BRIJ Travel

Lock a flight offer

brij_create_flight_intent

Free over MCP (the x402 price quoted below applies to the HTTP API only; MCP calls are rate-limited instead). Creates the escrow for one offer. KEEP customer_support_code from the answer: it cannot be read again, and orders and refunds need it. Next: brij_book_flight.

Create an escrow-backed booking intent from a selected offer.

Paid x402 endpoint. Send a valid PAYMENT-SIGNATURE header to create the intent. Without payment, the API returns 402 Payment Required.

Optional request field referrer: an affiliate code (see POST /affiliates) — the resolved affiliate wallet is frozen on the intent and credited a share of the platform fee once the booking captures and the journey is flown without refund; unknown or self-referring codes are silently ignored.

Creates the local booking intent and initializes its Solana escrow. This does not fund the escrow, pay the airline, or issue a ticket.

Lowcost (trip.com: offers). These book through a browser-driven fulfiller, not an airline API, so a few rules differ. The escrow amount is the offer's own price (fare menus from POST /air/offer-details are bookable: an offer_id like "trip.com:##@s" locks fare n and the escrow prices at that fare). A fare offer_id is only bookable while its menu is fresh (~30 min) — a stale one returns 409 fare_menu_expired, re-open the fares and retry. If the most recent fare check (POST /air/offer-details) for the offer failed within the last ~30 min, intent creation returns 409 fare_check_failed — a failed fare check temporarily blocks booking that offer; retry POST /air/offer-details in a few minutes and book once it answers. If that supplier is not currently selling, intent creation returns 409 browser_booking_unavailable — book a fastbooking offer, or retry later. An unknown/expired browser-tier offer_id returns 404 offer_not_found. Send an offer_id back EXACTLY as received. A browser-tier id is derived from the flight, so it is the same string for every buyer; the trailing "@s" is what ties it to YOUR search, and therefore to the cabin, the party and the fare menu your price came from. Strip it and the offer resolves against whoever searched that flight most recently. Booking then requires the travel document at POST /air/book (see there).

Input Schema

Name	Required	Description
`offer_id`	Yes	The offer to book, sent back EXACTLY as received from POST /air/search or POST /air/offer-details — never reassembled by hand.
`refund_wallet`	No	Optional Solana wallet for refunds. Defaults to funding_wallet.
`funding_wallet`	Yes	Solana wallet expected to fund the escrow.

Output Schema

Name	Required	Description	Default
`intent`	No	Read-only projection of a booking intent. Omits customer_support_code and passenger PII; those fields are returned once at intent-creation and /book time.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing the payment model (free over MCP, x402/PAYMENT-SIGNATURE for HTTP, 402 without payment), escrow semantics, the unrecoverable customer_support_code, affiliate referral freezing, and specific failure modes (409 fare_menu_expired, 409 fare_check_failed, 409 browser_booking_unavailable, 404 offer_not_found). This is exactly the behavioral context annotations cannot carry.

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

Conciseness3/5

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

Critical warnings are front-loaded well (free-over-MCP, KEEP customer_support_code, Next step), and the failure-mode detail is justified by complexity. However, the core purpose is restated three times ('Creates the escrow for one offer', 'Create an escrow-backed booking intent from a selected offer', 'Creates the local booking intent'), and the lowcost block is dense and unordered, so not every sentence earns its place.

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?

An output schema exists, so return-value explanation is not required, yet the description still flags the must-keep customer_support_code. Combined with the payment requirements, escrow-vs-funding distinction, referrer behavior, and the full set of supplier-specific error paths, an agent has everything needed to invoke this tool correctly and recover from failure.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value: it documents the optional 'referrer' field, which does not appear in the input schema at all, and explains offer_id semantics ('send back EXACTLY as received', the trailing '@s<search>' tying it to the buyer's search). That is meaning beyond the schema, though funding/refund wallet semantics are left to the schema.

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 verb+resource: 'Creates the escrow for one offer' / 'Create an escrow-backed booking intent from a selected offer.' It distinguishes itself from the sibling it feeds into by naming the next step ('Next: brij_book_flight') and clarifying that it 'does not fund the escrow, pay the airline, or issue a ticket.' An agent can tell it apart from brij_book_flight and brij_get_flight_offer_details without opening any schema.

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?

Explicit routing: 'Next: brij_book_flight' after intent creation, and a clear negative boundary ('This does not fund the escrow, pay the airline, or issue a ticket') that separates it from the booking tool. It also gives conditional usage for the lowcost variant, including when to re-open fares, retry offer-details, or fall back to a fastbooking offer. Alternatives and preconditions are spelled out rather than implied.

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

All BRIJ Travel 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?