Book 5-star hotels with the perks usually reserved for luxury travel advisors. Search Four Seasons, Aman, Rosewood, Ritz-Carlton, Park Hyatt and more at live rates, with Virtuoso/preferred-partner amenities shown per rate: daily breakfast for two, upgrade when available, early check-in/late check-out, hotel credit. Tax-inclusive price and cancellation policy on every rate. Book in chat, view or cancel trips anytime. By FlyBest Travel, a Virtuoso agency. Secure OAuth 2.0 sign-in.
Scored across 8 tools
Tools mostly target distinct resources (hotel search/content/rates, booking link, trips, currency), but my_trip and my_trips have nearly identical names that could cause misselection despite descriptions clarifying their roles.
All names use snake_case and descriptive terms with clear groupings (my_ for user trips, sabre_ for external system), but cancel_my_trip uses a verb-first pattern while most others are noun-first, a minor deviation.
8 tools is well-scoped for a hotel booking server, covering search, content, rates, booking, trip management, and currency conversion without unnecessary bloat.
Covers search, book, view, and cancel, but lacks an update/modify booking operation; agents cannot alter an existing reservation and must cancel/rebook (often with penalties), a notable gap.
Cancels one of the connected user's own bookings, by the number shown in my_trips. Two steps: the first call returns the cancellation terms accepted at booking and cancels nothing; a second call with confirm=true within 30 minutes of that preview performs the cancellation. When those terms carry a penalty or are non-refundable, the cancellation also needs accept_penalty=true, which records that the traveller accepted the charge. Not reversible.
| Name | Required | Description | Default |
|---|---|---|---|
| trip | Yes | number from my_trips | |
| confirm | Yes | second step: cancels when the terms were previewed within the last 30 minutes; otherwise the call returns the preview | |
| accept_penalty | No | records that the traveller accepted the penalty shown in the preview; required when the terms carry a penalty or are non-refundable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantive behavior beyond them: the first call is a non-mutating preview, the second must occur within 30 minutes, and penalty acceptance is recorded. 'Not reversible' partly restates destructiveHint, capping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences, front-loaded with the action and identifier, then the protocol, then the penalty condition. No filler, though the density is high enough that it reads as more than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description explains what the first call returns (the accepted cancellation terms) and what triggers actual cancellation. For a destructive, multi-step tool this covers everything an agent needs to call it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the three parameters are already documented (baseline 3). The description adds workflow meaning by linking confirm to the 30-minute preview window and accept_penalty to the previewed terms, which is more than the schema alone conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Cancels one of the connected user's own bookings') and ties the identifier to the sibling my_trips, so an agent can distinguish it from my_trip/my_trips immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the required two-step flow, the 30-minute window for confirm=true, and the conditional need for accept_penalty=true when terms carry a penalty or are non-refundable. Conditions for correct invocation are fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details of one of the connected user's own bookings, by the number shown in my_trips.
| Name | Required | Description | Default |
|---|---|---|---|
| trip | Yes | number from my_trips |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds only the scoping fact that the booking must belong to the connected user, which is modest added value; nothing is said about errors for unknown numbers or what the returned detail contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the resource and the lookup key front-loaded. Nothing is padded or repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with a full annotation safety profile this is nearly adequate, but with no output schema the description never indicates what details the booking detail object contains or how a missing/invalid trip number is surfaced, leaving a small but real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, and the schema already states 'number from my_trips'. The description merely restates that same origin, adding no format, range, or validity detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (one of the connected user's own bookings) and the retrieval key (the number shown in my_trips), which cleanly separates it from the list-style sibling my_trips. It is clear, though the singular-vs-list distinction from my_trips is only implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by the number shown in my_trips' implies the agent must call my_trips first to obtain a valid trip number, which is useful workflow context. However, there is no explicit when-to-use statement, no exclusion of cancel_my_trip or the hotel/currency siblings, and no note about what happens with an invalid number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The bookings made through this connection — only the connected user's own. The number printed beside each one identifies it for my_trip and cancel_my_trip.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: the result is scoped to the connected user only and each entry carries an identifier. It does not mention pagination or ordering, keeping it out of 5 territory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the scope constraint and followed by the only other fact an agent needs (the identifying number). No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema and a trivial read operation, the description covers what the tool returns and how its results feed sibling tools. Only the return ordering/pagination is unaddressed, a minor gap for a zero-arg list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly avoids inventing filter syntax that does not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource (bookings) and a key scope qualifier ('only the connected user's own'), which meaningfully distinguishes it from the other lookup siblings. It never uses an explicit verb like 'list', leaning on the title to supply that, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It routes the agent forward by explaining that each booking's printed number 'identifies it for my_trip and cancel_my_trip', effectively telling the agent this is the source of the IDs the other two tools need. There is no explicit when/when-not phrasing, so it stops at clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts an amount between currencies at the reservation system's banker's selling rate. For estimates only: hotel bookings are made in the rate's own currency. on_date (DDMMMYY) selects a past day's rate.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | e.g. 1780.00 | |
| on_date | No | DDMMMYY - the rate in force that day, max 400 days back | |
| via_nation | No | 2-letter country, to convert through a third currency | |
| to_currency | No | 3-letter code; omit for local currency | |
| from_currency | Yes | 3-letter code, e.g. EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds real context beyond that: the rate type (banker's selling), the estimate-only caveat, and that hotel bookings are made in the rate's own currency – a crucial behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core action and rate type. The second sentence adds a critical caveat and a param hint without padding, though the param hint could be slightly reorganized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations for safety, the description adequately covers rate type, estimate nature, and on_date semantics. It doesn't explain via_nation or to_currency defaults, but the schema does that partially; overall sufficient for a read-only conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning for on_date (DDMMMYY selects a past day's rate) and explains the estimate-vs-booking currency caveat, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Converts an amount between currencies') and adds scope: the banker's selling rate. Among siblings (hotel/trip tools) this is clearly the only currency tool, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are named, but the description implies usage by framing results as estimates for hotel bookings. This is implied rather than stated guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Details for one hotel: address, description, amenities, check-in and check-out times, room count and a gallery of photos by category. No prices; rates come from sabre_hotel_rates_coded.
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_code | Yes | Sabre hotel code from sabre_hotel_search | |
| image_size | No | thumb | medium (default) | large | original |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuine value beyond that by scoping the payload (content only, no prices) and pointing to the rates tool, though it says nothing about auth requirements, rate limits, or failure modes for invalid hotel codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The content inventory is front-loaded and the pricing exclusion/routing follows immediately, so the agent gets the scope and the boundary in one pass.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing return values, and it lists the returned fields explicitly. Combined with 100% schema coverage and annotations covering safety, an agent has everything needed to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (hotel_code, image_size) are already documented in the schema. The description mentions a photo gallery by category, which loosely relates to image_size, but adds no format or constraint detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and enumerates exactly what is returned (address, description, amenities, check-in/out times, room count, photo gallery). It also names the sibling it is not (rates come from sabre_hotel_rates_coded), so an agent can distinguish it from sabre_hotel_rates_coded without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly routes pricing lookups to sabre_hotel_rates_coded, and the schema notes the hotel_code comes from sabre_hotel_search, implying the correct call ordering. It stops short of an explicit when-to-use statement or exclusions for the other siblings, but the alternative is named clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | No | how 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. | |
| adults | No | ||
| check_in | Yes | YYYY-MM-DD | |
| children | No | 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. | |
| currency | No | 3-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_rows | No | rows 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_out | Yes | YYYY-MM-DD | |
| chain_code | Yes | from sabre_hotel_search — drives programme selection | |
| child_ages | No | e.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_code | Yes | Sabre hotel code | |
| hotel_name | Yes | from sabre_hotel_search — drives programme selection | |
| rate_codes | No | override the automatic selection; unloaded codes are dropped rather than silently returning public rates | |
| with_perks | No | fetch the benefit text (breakfast/credit/upgrade) for the cheapest rows — one extra Sabre call each | |
| perks_top_n | No | how many rows per programme (default 5) | |
| room_contains | No | keep 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_first | No | false sorts dearest first — the other way to surface suites | |
| negotiated_only | No | keep 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_occupancies | No | one entry per room, in room order, when the rooms differ. Mutually exclusive with adults/children/child_ages. |
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.
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.
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.
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.
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.
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.
Hotels near a place for given dates: names, Sabre hotel codes, star rating, distance and a provisional lowest rate per property; preferred-partner properties are flagged. The prices are provisional — the bookable rates, terms and benefits of a property come from sabre_hotel_rates_coded.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | ||
| check_in | Yes | YYYY-MM-DD | |
| location | Yes | 3-letter city/airport code (SBA), or a city name — "Paris", "东京", or "City, CC" for anywhere unusual | |
| check_out | Yes | YYYY-MM-DD | |
| rate_codes | No | narrow to specific codes, e.g. ["API"], ["WMP"] Hilton for Luxury, ["BC9"] Bellini Club | |
| radius_miles | No | ||
| all_programmes | No | default true; one query per loaded consortia programme so PP properties are flagged |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the description's remaining burden is low. It adds real value by disclosing that prices are provisional and that preferred-partner properties are flagged, plus that 'all_programmes' drives one query per consortia programme. It does not mention latency or result caps, which would have pushed it to a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the tool returns, then the caveat and the handoff to the rates sibling. Every clause carries information; nothing is restated from the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sensibly enumerates the returned fields and flags the provisional-price caveat, which is the key completeness requirement for this tool. Minor gaps remain around result volume/pagination and the meaning of less-obvious parameters like all_programmes, but nothing essential for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, just below the high-coverage bar, with adults, radius_miles and both dates effectively self-explanatory from the schema. The description mentions none of the parameters directly, so it adds no syntax or format meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Hotels near a place for given dates') and enumerates exactly what comes back: names, Sabre hotel codes, star rating, distance, and a provisional lowest rate, plus the preferred-partner flag. It explicitly names the sibling sabre_hotel_rates_coded that supplies real rates, so an agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It routes the agent to sabre_hotel_rates_coded for bookable rates, terms and benefits, which implies the search-then-rate workflow. It stops short of an explicit 'use this first to discover properties' instruction or any when-not condition, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cancel_my_trip2 fields changedInput schema / properties / accept_penalty / descriptionPrevious value: -"true only when the traveller explicitly accepted the penalty the preview showed"New value: +"records that the traveller accepted the penalty shown in the preview; required when the terms carry a penalty or are non-refundable"Input schema / properties / confirm / descriptionPrevious value: -"true only after the preview was shown to the traveller and they confirmed"New value: +"second step: cancels when the terms were previewed within the last 30 minutes; otherwise the call returns the preview"sabre_hotel_card_link5 fields changedInput schema / properties / allow_deposit / descriptionPrevious 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"Input schema / properties / email / descriptionPrevious 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."Input schema / properties / expected_total / descriptionPrevious 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"Input schema / properties / loyalty_id / descriptionPrevious 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"Input schema / properties / rooms / descriptionPrevious 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)."sabre_hotel_rates_coded1 field changedInput schema / properties / children / descriptionPrevious 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."cancel_my_tripmy_tripmy_tripssabre_currency_convertsabre_hotel_card_linksabre_hotel_contentsabre_hotel_rates_codedsabre_hotel_search
Add one secure layer between your agents and this server.