Skip to main content
Glama

FlyBest Travel — Hotel Booking with Advisor Benefits

by org.flybest
OverviewDiscussionsAdmin

Get hotel rates

sabre_hotel_rates_coded
Read-onlyIdempotent

The authoritative rate list for one hotel through the agency's reservation access: returned rates with room and bed type, the stay total in the hotel's currency (total_after_tax is the amount quoted; total_after_tax_excl_fees excludes fees), what is included (breakfast), excluded or unknown mandatory fees where stated, the cancellation deadline and penalty in words, deposit or prepayment terms, and the benefits attached to preferred-partner rates (daily breakfast, property credit where offered, upgrade on arrival subject to availability, early check-in / late check-out). hotel_name and chain_code come from the search result and select the partner rates; a call without either is refused before anything is sent. loyalty_id is the guest's own number with the hotel's loyalty programme (IHG One Rewards, Hilton Honors, World of Hyatt, I Prefer, Marriott Bonvoy): it is sent to the hotel with the search so any member offer the hotel makes this guest can come back (no discount is guaranteed), and a rate found this way carries the number and books only with the same loyalty_id. Hilton Honors, World of Hyatt, IHG One Rewards, I Prefer and Marriott Bonvoy member rates are listed without a number; Marriott Bonvoy member rates come back at some Marriott properties (about 2% under the public rate where measured). Rows marked members-only book only from a search made with the guest's number. rooms=2 prices two rooms and the returned rate_key then covers both. Rooms with different guest arrangements need separate one-room quotes and payment links before booking; the combined rate key cannot be reused. Family rate searches use the actual adults, children and child_ages. A chosen row that reads "Family occupancy verified for this rate" has verified occupancy for the party on its "Requested family for this rate" line; other rows in the list may still be unverified. The selected row's family_quote_token travels unchanged with its own rate_key into the payment-link request. The direct family booking preserves the quoted party. Deposits, prepayment and non-refundable rates follow the normal payment and cancellation consent flow. Unverified occupancy or no suitable family rate needs Jay's help at jay@flybest.org. An adults-only search is an alternative only when the traveller explicitly chooses an adults-first booking: free cancellation and no deposit or prepayment, with children and their charges still pending advisor confirmation. It is not an automatic substitute for a family quote. A comparison uses the same room/product, rate plan, dates, currency, benefits and cancellation/payment terms; the difference between the lists' lowest prices is not a child surcharge. An unchanged matching total does not establish that every child extra is free. Child policy, maximum occupancy and extra-person or extra-bed charges appear only where the rate text states them. An advisor request includes hotel, dates, room/rate preference, adult count and children's ages; sending an e-mail requires the traveller's explicit request. Results start with a note for the traveller about booking in this conversation and end with a short reminder. The traveller can confirm their chosen option in this chat to receive its secure payment page. A membership question appears near the start when the hotel has a known loyalty programme and no number was supplied.

Input Schema

NameRequiredDescriptionDefault
roomsNohow many rooms at this property for these dates. Totals cover ALL of them for the whole stay; per_room_total is on each row beside it. adults/children/child_ages then describe EVERY room.
adultsNo
check_inYesYYYY-MM-DD
childrenNonumber of children, sent together with child_ages of the same length (the call is refused otherwise — Sabre answers children-without-ages with 200 and zero rates, which is indistinguishable from sold out. Omitting children means every price returned is an ADULTS-ONLY price.
currencyNo3-letter code for the DISPLAY conversion shown beside each rate (default USD). The hotel's OWN currency is always what is quoted and what gets charged — this only changes the ≈ estimate, e.g. CNY for a client who thinks in RMB. Allowed: USD CNY HKD TWD EUR GBP JPY SGD AUD CAD CHF THB KRW. Anything else is REFUSED, because Sabre answers an unknown code with 200 and ZERO rates (measured 2026-09-12) — indistinguishable from sold out.
max_rowsNorows to return, default 60, up to 400. The cap is ours, not Sabre's, and rows come cheapest-first — so a short answer lost the DEAREST rows. Check `truncated` in the reply before concluding a programme has no suites
check_outYesYYYY-MM-DD
chain_codeYesfrom sabre_hotel_search — drives programme selection
child_agesNoe.g. [10, 8]. Check occupancy.children_honoured in the result: many properties accept and then ignore children, and the total comes back adults-only.
hotel_codeYesSabre hotel code
hotel_nameYesfrom sabre_hotel_search — drives programme selection
loyalty_idNothe guest's own membership number with this hotel's loyalty programme (Marriott Bonvoy, IHG One Rewards, Hilton Honors, World of Hyatt…), as on the card, no chain code. It is sent to the hotel with the search so any member offer the hotel makes this guest can come back (no discount is guaranteed); every rate found this way carries the number into the booking and books only with the same loyalty_id. Hilton Honors, World of Hyatt, IHG One Rewards, I Prefer and Marriott Bonvoy member rates are listed without it, marked members-only (Marriott's at some properties only).
with_perksNofetch the benefit text (breakfast/credit/upgrade) for the cheapest rows — one extra Sabre call each
perks_top_nNohow many rows per programme (default 5)
room_containsNokeep only rows whose room/plan text contains this, e.g. "suite" or "villa". Applied BEFORE the row cap, so this is how you reach a room type that prices above the cheap rooms
cheapest_firstNofalse sorts dearest first — the other way to surface suites
negotiated_onlyNokeep ONLY programme-negotiated rows and drop the public ones. On a property with several plans per room the public half is what pushes suites out of the window
room_occupanciesNoone entry per room, in room order, when the rooms differ. Without rooms, the number of entries is the room count; with rooms, the two must agree. Mutually exclusive with adults/children/child_ages. Different guest arrangements need separate one-room quotes and payment links before booking; the combined rate key cannot be reused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / rate_codes
      Removed value: -{
-  "description": "override the automatic selection; unloaded codes are dropped rather than silently returning public rates",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}
  2. Changed1 schema field changed
    • changedInput schema / properties / loyalty_id / description
      Previous value: -"the guest's own membership number with this hotel's loyalty programme (Marriott Bonvoy, IHG One Rewards, Hilton Honors, World of Hyatt…), as on the card, no chain code. It is sent to the hotel with the search so any member offer the hotel makes this guest can come back (no discount is guaranteed); every rate found this way carries the number into the booking and books only with the same loyalty_id. Hilton Honors, World of Hyatt, IHG One Rewards and I Prefer member rates are listed without it, marked members-only."New value: +"the guest's own membership number with this hotel's loyalty programme (Marriott Bonvoy, IHG One Rewards, Hilton Honors, World of Hyatt…), as on the card, no chain code. It is sent to the hotel with the search so any member offer the hotel makes this guest can come back (no discount is guaranteed); every rate found this way carries the number into the booking and books only with the same loyalty_id. Hilton Honors, World of Hyatt, IHG One Rewards, I Prefer and Marriott Bonvoy member rates are listed without it, marked members-only (Marriott's at some properties only)."
  3. Changed1 schema field changed
    • changedInput schema / properties / room_occupancies / description
      Previous value: -"one entry per room, in room order, when the rooms differ. Mutually exclusive with adults/children/child_ages. Different guest arrangements need separate one-room quotes and payment links before booking; the combined rate key cannot be reused."New value: +"one entry per room, in room order, when the rooms differ. Without rooms, the number of entries is the room count; with rooms, the two must agree. Mutually exclusive with adults/children/child_ages. Different guest arrangements need separate one-room quotes and payment links before booking; the combined rate key cannot be reused."
  4. Changed1 schema field changed
    • changedInput schema / properties / room_occupancies / description
      Previous value: -"one entry per room, in room order, when the rooms differ. Mutually exclusive with adults/children/child_ages."New value: +"one entry per room, in room order, when the rooms differ. Mutually exclusive with adults/children/child_ages. Different guest arrangements need separate one-room quotes and payment links before booking; the combined rate key cannot be reused."
  5. Changed1 schema field changed
    • addedInput schema / properties / loyalty_id
      Added value: +{
+  "description": "the guest's own membership number with this hotel's loyalty programme (Marriott Bonvoy, IHG One Rewards, Hilton Honors, World of Hyatt…), as on the card, no chain code. It is sent to the hotel with the search so any member offer the hotel makes this guest can come back (no discount is guaranteed); every rate found this way carries the number into the booking and books only with the same loyalty_id. Hilton Honors, World of Hyatt, IHG One Rewards and I Prefer member rates are listed without it, marked members-only.",
+  "type": "string"
+}
  6. First observed

TDQS

A3.8/5.0
Behavior5/5

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

The description adds rich context beyond the readOnly/idempotent annotations: calls without hotel_name or chain_code are refused before sending, loyalty IDs are transmitted to the hotel with no guaranteed discount, member rates are listed without a number, rooms=2 produces a combined rate key that cannot be reused for separate arrangements, and family_quote_token must travel unchanged with its rate_key. These are meaningful behavioral constraints not available from the annotations.

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

Conciseness2/5

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

The description is a single very long paragraph that repeats schema content about loyalty programmes and family handling. While the first sentence front-loads the purpose, the remaining text is dense and difficult to scan, with multiple operational rules packed together.

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 an 18-parameter rates tool with no output schema, it covers the critical return semantics (total_after_tax, fees, cancellation deadline, deposit terms, benefits) and important caveats such as combined rate keys and family_quote_token. Some response details are left to the schema or omitted, but the description is largely complete for correct invocation.

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 94%, so the baseline is 3. The description still adds useful semantics for key parameters: hotel_name and chain_code select partner rates and are required, loyalty_id affects member-offer visibility and booking eligibility, rooms=2 changes the meaning of rate_key, and family searches must use actual adults, children, and child_ages.

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

Purpose4/5

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

The description states a specific verb and resource: it returns the authoritative rate list for one hotel with room/bed type, totals, inclusions, fees, cancellation terms, deposits, and preferred-partner benefits. It is clearly a rates-retrieval tool downstream of hotel search, though it never explicitly names sabre_hotel_search or other siblings by name.

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

Usage Guidelines3/5

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

It gives substantial operational guidance about loyalty IDs, family searches, combined room rate keys, and when an adults-only option is acceptable, but it does not explicitly state when to call this tool versus sabre_hotel_search, sabre_hotel_content, or sabre_hotel_card_link. The usage context is implied rather than routed.

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

All FlyBest Travel — Hotel Booking with Advisor Benefits toolsInspect
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