FlyBest AI Travel — Luxury Hotels with Perks

Create hotel payment link

sabre_hotel_card_link

Creates a one-time payment page for one rate. Inputs: the rate_key and rooms from sabre_hotel_rates_coded, the guest's name as on their ID, e-mail and phone, and the expected_total and currency copied from that rate row. The page shows the price, deposit and cancellation terms; the guest accepts them and enters their card there, and the booking is made when they submit and the hotel confirms. Card details are entered only on that page; this tool takes none. loyalty_id is the guest's own number with the hotel's loyalty programme, not an advisor's number; it is filed on the booking. Points, elite nights and your status benefits apply as usual, on top of the partner benefits. A stay with children: the link can only be made for the adults, from the adults-only rate key and a rate with free cancellation; the stay is booked as N adults, children and child_ages record the party, and after booking the advisor (flybestorg@gmail.com) confirms the children and any changes (extra-person charge or bedding) with the hotel and gets back to them. No link is made for a non-refundable or prepaid rate with children; those requests go to flybestorg@gmail.com with hotel, dates, room and rate, number of adults and the children's ages. allow_deposit / allow_nonrefundable permit such a rate to be offered; the page then asks the guest for consent. Creating the page sends the guest and stay details to FlyBest's booking service and the reservation system; nothing is booked until the guest submits the page and the hotel confirms. The booking then appears in my_trips.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	The guest's own e-mail address, required: the hotel sends its confirmation and any later change to it, so without it the property cannot reach the traveller.
`phone`	No
`rooms`	No	Rooms in ONE segment, all for the same guest and the same room type — the way an agent sells two rooms on one PNR. The rate_key comes from sabre_hotel_rates_coded with the same rooms=N: a two-room key and a one-room key are entirely different keys and only the two-room one sells two rooms, and its total is already the whole stay. Rooms sold together share one segment and CANNOT be cancelled individually. Different room types cannot share a sell — for that, book the first room and then mint a second link with add_to_pnr set to the locator it returned. LIVE on production since 2026-09-11 (certified on CERT: one segment carrying NumberOfUnits=2).
`adults`	No
`surname`	Yes
`check_in`	Yes	YYYY-MM-DD
`children`	No
`currency`	Yes	REQUIRED. The currency of expected_total, copied from the SAME rate row — the hotel's OWN currency, not USD. The commit compares the whole tuple, so a wrong currency refuses the booking AFTER the guest has typed their card.
`rate_key`	Yes	from sabre_hotel_rates_coded
`check_out`	Yes	YYYY-MM-DD
`add_to_pnr`	No	An EXISTING Sabre locator this room should JOIN instead of creating a new PNR. THIS is how one guest gets a king AND a suite on one record: Sabre refuses to put two room types in one sell, so book the first room normally, then mint a second link with this set to the locator it returned. Each segment keeps its OWN rate, its own deposit and its own cancellation policy, and they can be cancelled separately. Leave it out for an ordinary booking.
`chain_code`	No
`child_ages`	No
`given_name`	Yes
`hotel_code`	Yes	Sabre property code
`hotel_name`	No
`loyalty_id`	No	the guest's own programme number with the hotel's chain (not an advisor ID), filed on the segment when the room is booked
`allow_deposit`	No	permits a deposit rate — one whose card is charged now — to be offered; the page asks the guest for consent
`expected_total`	Yes	the all-in total of the chosen rate row, e.g. 288.09 - a moved rate aborts the booking
`expected_deposit`	No	the deposit figure from the rates row (deposit_amount) as shown to the payer. OPTIONAL since 2026-09-26: the page charges the hotel's own deposit as long as it is within the stay total, and reports what it took — a deposit that moved no longer refuses at the guest's card. Pass it when you have it so the guest sees the difference.
`allow_nonrefundable`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 29, 2026

changedInput schema / properties / allow_deposit / description

Previous value: -"true only for deposit rates, and only once the payer knows the card is charged now"New value: +"permits a deposit rate — one whose card is charged now — to be offered; the page asks the guest for consent"

changedInput schema / properties / email / description

Previous value: -"The GUEST's own email. The hotel sends its confirmation and any later change to this address, so without it the property cannot reach the traveller. ASK FOR IT before minting the link."New value: +"The guest's own e-mail address, required: the hotel sends its confirmation and any later change to it, so without it the property cannot reach the traveller."

changedInput schema / properties / expected_total / description

Previous value: -"all-in total you showed the payer, e.g. 288.09 - a moved rate aborts the booking"New value: +"the all-in total of the chosen rate row, e.g. 288.09 - a moved rate aborts the booking"

changedInput schema / properties / loyalty_id / description

Previous value: -"the guest's programme number with the hotel's chain, filed on the segment when the room is booked (never the advisor ID)"New value: +"the guest's own programme number with the hotel's chain (not an advisor ID), filed on the segment when the room is booked"

changedInput schema / properties / rooms / description

Previous value: -"Rooms in ONE segment, all for the same guest and the same room type — the way an agent sells two rooms on one PNR. The rate_key MUST come from sabre_hotel_rates_coded with the SAME rooms=N: a two-room key and a one-room key are entirely different keys and only the two-room one sells two rooms, and its total is already the whole stay. Rooms sold together share one segment and CANNOT be cancelled individually. Different room types cannot share a sell — for that, book the first room and then mint a second link with add_to_pnr set to the locator it returned. LIVE on production since 2026-09-11 (certified on CERT: one segment carrying NumberOfUnits=2)."New value: +"Rooms in ONE segment, all for the same guest and the same room type — the way an agent sells two rooms on one PNR. The rate_key comes from sabre_hotel_rates_coded with the same rooms=N: a two-room key and a one-room key are entirely different keys and only the two-room one sells two rooms, and its total is already the whole stay. Rooms sold together share one segment and CANNOT be cancelled individually. Different room types cannot share a sell — for that, book the first room and then mint a second link with add_to_pnr set to the locator it returned. LIVE on production since 2026-09-11 (certified on CERT: one segment carrying NumberOfUnits=2)."

First observedSep 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description goes well beyond the annotations, disclosing that no card details are taken, that guest/stay data is sent to FlyBest's booking service and reservation system at page-creation time, that nothing is booked until the guest submits and the hotel confirms, and that the result appears in my_trips. With destructiveHint=false and openWorldHint=true, this adds the missing workflow and data-flow context.

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?

Front-loaded with the core action, but the single dense paragraph runs long and includes low-value filler ('Points, elite nights and your status benefits apply as usual, on top of the partner benefits') that does not help an agent invoke the tool. Several workflow rules are buried mid-sentence rather than structured.

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

Completeness4/5

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

For a 21-parameter, no-output-schema mutation tool this covers the consequential workflows (children, deposits, non-refundable, multi-room, add_to_pnr) thoroughly. It never states what the tool returns (a link, a locator, a PNR) or how errors surface, which is the main remaining gap.

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 only 57% across 21 params, and the description compensates for several key ones — loyalty_id (guest's own number, not the advisor's), allow_deposit/allow_nonrefundable (permits offering and asks consent), and the name/e-mail/phone triple. It leaves phone, adults, chain_code and hotel_name unexplained, so it does not fully close the gap.

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 and resource ('Creates a one-time payment page for one rate') and immediately ties its inputs to the sibling tool sabre_hotel_rates_coded. An agent can tell this apart from sabre_hotel_rates_coded or sabre_hotel_search without opening a 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?

Gives explicit when-to-use branches: normal adult bookings, child stays (adults-only rate key, free-cancellation requirement), and the when-NOT case ('No link is made for a non-refundable or prepaid rate with children; those requests go to flybestorg@gmail.com'). It also routes two-room and mixed-room-type cases to rooms=N or add_to_pnr.

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

All FlyBest AI Travel — Luxury Hotels with Perks 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?