Skip to main content
Glama

FlyBest AI Travel — Luxury Hotels with Perks

Get hotel rates

sabre_hotel_rates_coded
Read-onlyIdempotent

The rate list for one hotel through the agency's reservation access: every bookable rate with room and bed type, the stay total in the hotel's currency (total_after_tax is the amount quoted), what is included (breakfast), 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. rooms=2 prices two rooms and the returned rate_key then covers both. Partner rates and their benefit text are returned for adults-only occupancy, so the list is priced adults-only unless children and child_ages are passed. A second call with children and child_ages returns the hotel's family price only when the reply says 'children priced': for the same room and rate plan, the difference from the adults-only total is the hotel's child charge. When the property ignores the children or cannot price them, there is no child price in the system and none can be estimated. Child policy, maximum occupancy and extra-person or extra-bed charges appear only where the rate text states them. A payment link for a stay with children 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, 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. A non-refundable or prepaid rate is not offered by link for a stay with children; those requests go to flybestorg@gmail.com with hotel, dates, room and rate, number of adults and the children's ages.

Input Schema

TableJSON 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
rate_codesNooverride the automatic selection; unloaded codes are dropped rather than silently returning public rates
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. Mutually exclusive with adults/children/child_ages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / children / description
      Previous value: -"number of children. MUST be sent with child_ages of the same length, or the call is refused — 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."New value: +"number 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."
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations declare a safe read (readOnlyHint/idempotentHint), and the description adds substantial non-obvious behavior: prices are adults-only unless children+child_ages are passed, 'children priced' is the only signal a family price exists, non-refundable/prepaid rates are not linkable for child stays, and child charges can only be inferred by diffing totals. This is exactly the extra context the 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?

The lead sentence front-loads the payload well, but the rest is a dense, run-on paragraph that restates schema-level child/child_ages rules and mixes pricing, booking-link, and escalation policy into one block. Much is useful, yet it is not tightly edited and some content duplicates the schema.

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, no-output-schema read tool with 94% schema coverage, the description supplies the pricing semantics, the adults-only default, and the child-stay workflow that an agent needs to invoke it correctly. The main gap is that return-field interpretation (e.g. total_after_tax, truncated, occupancy.children_honoured) is split between description and schema rather than consolidated.

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 already 94%, so the baseline is 3, but the description adds real semantics beyond the schema: rooms=2 means the returned rate_key covers both rooms, partner/benefit rates are priced adults-only, and a non-refundable rate is barred from the link flow. It stops short of explaining several parameters that only live in 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?

Opens with a specific verb+resource+scope: 'The rate list for one hotel through the agency's reservation access.' The scope 'for one hotel' and the enumerated payload (room/bed type, stay total, cancellation) clearly separate it from siblings like sabre_hotel_search (which feeds hotel_name/chain_code) and sabre_hotel_content.

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 explains the workflow prerequisites (hotel_name and chain_code come from the search result) and when a second call with children/child_ages is needed, but never states when to choose this tool over sabre_hotel_content or sabre_hotel_card_link, nor any explicit exclusion. Usage is implied rather than prescribed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources