Live hotel and flight prices compared across Booking.com, Agoda, Trip.com and Traveloka, in USD.
Scored across 13 tools
Most tools occupy clearly distinct slots: async start/poll pairs, a two-step cancellation flow, city search vs single-hotel detail vs link-based price comparison. The weak spot is the trio get_hotel_detail, get_hotel_info and get_ota_hotel_detail, which all return 'hotel detail' for different sources/date requirements and only stay separable because the descriptions repeatedly cross-reference each other. An agent skimming names alone could easily pick the wrong one.
Nearly everything follows a verb_noun snake_case pattern (search_*, poll_*, get_*, request_*, cancel_booking, check_booking_status). The one inconsistency is that poll_search_results is the hotel-search poller while search_hotels_live is its starter — the flight pair is symmetric (search_flights_live/poll_flight_results) but the hotel pair is not, which slightly breaks the pairing convention.
13 tools is well within a comfortable range and each earns its place: two async search pairs, three granularity levels of hotel detail, a link-based comparison, and a complete request/cancel lifecycle. Nothing looks redundant or padded.
The core domain is covered end to end: discover, compare, inspect, request, track status, and cancel with a proper token/policy flow. Gaps are minor — there is no way to retrieve full booking details (only status) or modify a booking, and flights stop at a booking link with no cancel/status path, though those are defensible for a metasearch server.
Second of two steps to cancel a booking: cancels it and starts any refund due. Irreversible. Requires the confirmation code and the single-use token that request_cancel_token emailed to the guest; a missing, expired or already-used token is rejected. get_cancellation_policy shows the refund terms that apply.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Guest-provided cancellation reason (at least 3 characters) | |
| cancelToken | Yes | Single-use cancellation token from the email request_cancel_token sent to the guest. | |
| confirmationCode | Yes | 8-char booking confirmation code, e.g. K7X9M2P4 |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| refundAmount | Yes | |
| refundStatus | Yes | |
| gatewaySettlementEta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds value beyond them: it flags irreversibility, discloses the side effect of initiating a refund, and describes token validation failure modes. For a mutation tool, that is rich behavioral 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?
Three tight sentences, front-loaded with purpose and reversibility, then prerequisites, then the sibling pointer. No sentence is redundant.
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 an output schema present, return values need no explanation; the description covers workflow position, irreversibility, token requirements, and refund implications. Nothing an agent needs to call it correctly 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 100%, so all three parameters are already documented (including the token's origin and the confirmation code format) and the description adds no syntax or format detail beyond that. This is the baseline case where the schema carries the semantics.
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 opens with a specific verb+resource ('Second of two steps to cancel a booking: cancels it and starts any refund due'), placing it precisely in the two-step workflow and distinguishing it from request_cancel_token, which is named as step 1. An agent can tell it apart from siblings without opening the 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 states the exact prerequisites (confirmation code plus the single-use token request_cancel_token emailed to the guest) and the negative condition ('a missing, expired or already-used token is rejected'). It also routes to get_cancellation_policy for refund terms, giving explicit when-to-use and companion-tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current status of a booking request (waiting for the hotel, confirmed or cancelled) by the confirmation code request_booking returned.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language | en |
| confirmationCode | Yes | confirmationCode from request_booking structuredContent (e.g. 'K7X9M2P4') |
| Name | Required | Description |
|---|---|---|
| paidAt | Yes | |
| status | Yes | |
| checkIn | Yes | |
| checkOut | Yes | |
| bookingId | Yes | |
| guestName | Yes | |
| guestEmail | Yes | |
| roomNumber | Yes | |
| propertyName | Yes | |
| paymentMethod | Yes | |
| paymentStatus | Yes | |
| paymentLinkUrl | Yes | |
| confirmationCode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds the enumeration of possible status outcomes, which is modest extra behavioral context, but says nothing about freshness, repeated polling, or rate limits.
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 front-loaded sentence with zero filler: the action, the enumerated outcomes, and the input source all appear in one pass. Nothing repeats the title or restates 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?
With an output schema present, the description needn't explain return values, and it correctly avoids doing so. It covers what the tool does and where the required key comes from; it only omits minor context such as whether repeated polling is expected or how the language parameter affects output.
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 are already documented in the schema, including the confirmationCode format and example. The description only reinforces where confirmationCode comes from; it adds no syntax 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 verb+resource ('Returns the current status of a booking request'), enumerates the possible states (waiting for the hotel, confirmed, cancelled), and identifies the lookup key's origin. It is clearly distinguishable from siblings like cancel_booking or request_booking.
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 confirmation code request_booking returned' implies the tool is used after request_booking, giving implicit sequencing guidance. However, no when-not conditions or explicit alternatives (e.g. polling vs. cancel flows) are stated, so usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares prices for the one hotel behind a link from Booking.com, Agoda, Traveloka, Trip.com, Hotels.com or Airbnb: finds the same hotel on the other sites and lists each site's price for the whole stay, cheapest first, with a link to each. The dates and guests in the link are used when it has them, otherwise checkIn, checkOut and adults. Share links and links inside pasted text work too. Takes about 10-30 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The hotel link as the user pasted it, e.g. 'https://www.agoda.com/radisson-hotel-danang/hotel/da-nang-vn.html'. | |
| adults | No | Number of adults, used when the link does not say (default 2). | |
| checkIn | Yes | Check-in date YYYY-MM-DD, used when the link has no dates. | |
| checkOut | Yes | Check-out date YYYY-MM-DD, used when the link has no dates. | |
| language | No | Optional UI language hint. Only used when queryText gives no signal. | |
| queryText | No | Short excerpt (one sentence at most) of the guest's latest message in their own words, used only to detect the reply language; it is not stored or forwarded. It carries no names, contact details or other parts of the conversation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring openWorldHint=true and destructiveHint=false, the description adds useful behavior: it takes about 10-30 seconds and returns each site's whole-stay price, cheapest first, with a link to each. It does not contradict the annotations and does not imply a destructive write.
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 description is front-loaded with the main action and output shape, then covers fallback dates, link formats, and latency. Each sentence adds actionable information without repetition or 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?
For a tool with no output schema, the description explains the return behavior well: cross-site matches, whole-stay prices, cheapest-first ordering, and per-site links. It could be slightly more complete about failure cases, such as unsupported links or no match found, but it is sufficient for correct invocation.
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 parameters are already documented. The description still adds cross-parameter meaning by explaining that dates and guests embedded in the link take precedence, with checkIn, checkOut and adults used only as fallbacks.
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 states a specific verb and resource: compares prices for the one hotel behind a link across named OTAs. It distinguishes this from a general hotel search by emphasizing a single linked hotel, cross-site matching, and a cheapest-first price list with links.
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 clearly explains the input context: a hotel link from Booking.com, Agoda, Traveloka, Trip.com, Hotels.com or Airbnb, including share links and links inside pasted text. It does not explicitly name when to use a sibling such as search_hotels_live instead, but the single-hotel-from-a-link scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the cancellation terms for one rate plan at an OpenTravel partner hotel: whether it is refundable, the free-cancellation window, the refund percentage, a plain-language summary and, given the check-in date, the exact free-cancellation deadline. Takes the propertyId and the ratePlanId from get_hotel_detail.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Reply language. Falls back to queryText, then English. | |
| queryText | No | Short excerpt of the guest's request, used only to pick the reply language. | |
| propertyId | Yes | OpenTravel propertyId UUID from search results | |
| ratePlanId | Yes | ratePlanId from get_hotel_detail roomTypes[].ratePlanId | |
| checkInDate | Yes | Check-in date YYYY-MM-DD — required to compute the exact free-cancel deadline |
| Name | Required | Description |
|---|---|---|
| policyText | Yes | |
| ratePlanId | Yes | |
| nonRefundable | Yes | |
| computedDeadline | Yes | |
| freeCancelUntilHours | Yes | |
| refundPercentAfterWindow | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's added behavior is that the exact free-cancellation deadline is computed from the check-in date, which is useful, but much of the remaining text restates return fields already covered by the output schema.
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 front-loaded sentence that leads with the action and resource, then lists outputs, then input provenance. It is long but each clause carries information; no filler sentences.
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 an output schema present and annotations covering safety, the description only needs to establish scope and inputs, which it does fully: what is returned, for which entity, and where the required ids come from. Nothing an agent needs to invoke it correctly 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 100%, so the schema already documents all five parameters, including the provenance of propertyId and ratePlanId and the purpose of checkInDate. The description reinforces the two id parameters but adds no syntax or format 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 verb and resource ('Returns the cancellation terms for one rate plan at an OpenTravel partner hotel') and enumerates the concrete outputs: refundability, free-cancellation window, refund percentage, summary, and computed deadline. That level of specificity clearly separates it from siblings like get_hotel_detail or cancel_booking.
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 clear provenance for two of the three required inputs ('Takes the propertyId and the ratePlanId from get_hotel_detail'), which tells the agent when in a workflow this call fits. It stops short of stating exclusions or naming alternatives (e.g., that this is not the tool for actually cancelling), so it is clear context without routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prices and availability for one OpenTravel direct-listed hotel over a date range, with its photos, amenities and room types, each room with its rate plan and total price. Takes the propertyId from search results (source 'OPENTRAVEL_DIRECT'), or a hotel name plus city for a known direct listing. get_hotel_info returns the same hotel's static facts without dates.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City of the hotel — required when resolving by hotelName. | |
| adults | No | Number of adults (default 2) | |
| checkIn | Yes | Check-in date YYYY-MM-DD. Must be today or later. | |
| checkOut | Yes | Check-out date YYYY-MM-DD. Must be after checkIn. | |
| children | No | Number of children (default 0) | |
| language | No | Preferred UI language (en/vi/de/ja/ko/zh/fr/es/ru/th/id). | |
| hotelName | No | Fallback name for a confirmed OpenTravel direct listing when propertyId is unavailable | |
| queryText | No | Optional short excerpt of the current request, used only to detect the UI language; it is not stored or forwarded. | |
| propertyId | No | OpenTravel propertyId UUID from search results (opentravelResults[].propertyId). |
| Name | Required | Description |
|---|---|---|
| adults | Yes | |
| nights | Yes | |
| checkIn | Yes | |
| checkOut | Yes | |
| language | Yes | |
| property | Yes | |
| discovery | No | |
| roomTypes | Yes | |
| bookingUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds the nature of the content returned (live rates, per-room rate plans), but says nothing about latency, rate freshness, failure modes when a name/city lookup is ambiguous, or whether the pricing is cacheable — so it adds only modest context beyond structured fields.
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 sentences, zero filler, front-loaded with what the tool returns before moving to identification inputs and then the sibling boundary. Every sentence earns its place.
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 an output schema present and 100% parameter coverage, the description needn't restate return fields, and it covers identification, data scope and one alternative. The only gap is an explicit contrast against get_ota_hotel_detail, a name-adjacent sibling an agent could easily confuse with this one.
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 schema carries the per-field detail and baseline would be 3. The description goes slightly further by stating the resolution pairing ('a hotel name plus city') and the provenance of propertyId (search results with source 'OPENTRAVEL_DIRECT'), which clarifies a real dependency the schema only encodes per-field.
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 precise verb+resource+scope: prices and availability for one OpenTravel direct-listed hotel over a date range, plus the returned payload (photos, amenities, room types with rate plans and total prices). It also implicitly carves out the sibling boundary by specifying 'OpenTravel direct-listed', which distinguishes it from get_ota_hotel_detail.
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 clear entry conditions: take propertyId from search results (source 'OPENTRAVEL_DIRECT'), or resolve by hotelName plus city for a known direct listing. It names get_hotel_info as the static-facts alternative, but never explicitly contrasts with get_ota_hotel_detail or search_hotels_live, leaving one sibling boundary to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Static facts about an OpenTravel direct-listed hotel, with no check-in or check-out date required: photo gallery, property description, address, facilities (parking, pool, pets and so on), check-in and check-out times, the house cancellation policy, and each room type's description, floor area, capacity, photos and in-room facilities. Carries no prices and no availability — get_hotel_detail covers those for a specific date range. Takes the propertyId UUID from search results.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Preferred reply language (en/vi/de/ja/ko/zh). | |
| queryText | No | Optional short excerpt of the current request, used only to detect the reply language; it is not stored or forwarded. | |
| propertyId | Yes | OpenTravel propertyId UUID from search results (opentravelResults[].propertyId). |
| Name | Required | Description |
|---|---|---|
| property | Yes | |
| roomTypes | Yes | |
| cancellationPolicy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: this endpoint is date-agnostic, deliberately carries no prices or availability, and is scoped to 'direct-listed' properties. It stops short of covering rate limits or error behaviour, but that is minor given the annotation coverage.
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?
One dense paragraph, front-loaded with the defining trait (no dates needed) followed by the returned-data inventory and the sibling comparison. The long enumerated clause list is justified by the number of distinct facts returned, though it could be tightened slightly.
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?
An output schema exists, so return values need no further explanation, yet the description still tells the agent what categories of data come back. Combined with the date-agnostic scope, sibling routing and identifier provenance, nothing needed to call this tool correctly 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 100%, so the schema already documents propertyId, language and queryText; baseline is 3. The description reinforces where propertyId comes from (search results) but adds nothing about the language or queryText parameters, so it does not exceed what the schema 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?
Names the specific resource (static facts about an OpenTravel direct-listed hotel) and enumerates exactly which fields are returned — photos, description, address, facilities, check-in/out times, cancellation policy, room details. It explicitly distinguishes itself from the sibling get_hotel_detail by scope (no dates, no prices, no availability).
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?
States the selection condition outright: use this when no check-in/check-out date is needed, and use get_hotel_detail instead when a specific date range's prices and availability are required. It also names the source of the required identifier (the propertyId UUID from search results), so the agent knows where to get the input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail (rooms, live prices, facilities, photos, reviews) from Booking.com for one named hotel over a date range, for requests about a single hotel rather than a whole city (search_hotels_live lists a city). The name is resolved through the city's listings, so it takes the hotel name together with its city; a Booking.com URL from an earlier result skips that lookup. OpenTravel direct listings are covered by get_hotel_detail. The fetch is live and takes up to about two minutes; under heavy load it can return not-found.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City of the hotel, used to resolve the name, e.g. 'Da Nang'. Required with hotelName. | |
| rooms | No | Number of rooms (default 1) | |
| adults | No | Number of adults (default 2) | |
| checkIn | Yes | Check-in date YYYY-MM-DD. Must be today or later. | |
| checkOut | Yes | Check-out date YYYY-MM-DD. Must be after checkIn. | |
| language | No | Optional UI language. Indonesian (id) cannot be detected from text, so for Indonesian this is how the language is set. | |
| hotelName | No | Name of the hotel, e.g. 'Mercure Danang French Village Bana Hills'. Required unless propertyUrl is given. | |
| queryText | No | Short excerpt (one sentence at most) of the guest's latest message in their own words, used only to detect the reply language; it is not stored or forwarded. It carries no names, contact details or other parts of the conversation. | |
| propertyUrl | No | Booking.com property URL from an earlier result (hotel.prices.booking.url); skips the name lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only mark openWorldHint=true and destructiveHint=false), the description discloses that the fetch is live, can take about two minutes, and may return not-found under heavy load. That is meaningful operational context. It stops short of covering auth or why readOnlyHint is false, so it is strong but not exhaustive.
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?
Content is front-loaded with what the tool returns and its scope distinction, then resolution mechanics, alternatives, and latency. Every sentence carries information, though the sentence packing several ideas plus the OpenTravel aside is dense enough that it is not maximally tight.
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?
Despite no output schema and nine parameters, the description covers the return payload, the naming/resolution requirement, the URL shortcut, sibling routing, and the latency/failure behavior. An agent has everything needed to call it 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 coverage is 100%, so baseline is 3, but the description adds relational meaning: the hotel name is resolved through the city's listings (so hotelName and city are used together), and propertyUrl bypasses that lookup. This clarifies parameter interaction beyond the per-field schema text.
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 verb+resource (fetch full hotel detail for one named hotel over a date range) and enumerates the returned payload (rooms, live prices, facilities, photos, reviews). It explicitly differentiates scope from the sibling 'search_hotels_live' (city-wide) so the agent can route 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 states when to use this tool (requests about a single hotel) and contrasts it against both a sibling for city searches (search_hotels_live) and a sibling for OpenTravel direct listings (get_hotel_detail). It also tells the agent how to skip the name lookup via a Booking.com URL from an earlier result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current results of a flight search session started by search_flights_live: outbound and return options with airline, flight number, times, stops, fare and booking link. Results can be partial while the search runs; status reads 'completed' or 'failed' when it ends.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session ID from search_flights_live |
| Name | Required | Description |
|---|---|---|
| cabin | Yes | |
| adults | Yes | |
| cached | Yes | |
| origin | Yes | |
| status | Yes | |
| language | No | |
| tripType | Yes | |
| sessionId | Yes | |
| returnDate | No | |
| destination | Yes | |
| totalReturn | Yes | |
| departureDate | Yes | |
| returnFlights | Yes | |
| totalOutbound | Yes | |
| outboundFlights | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: results may be partial mid-search and a status field terminates at 'completed' or 'failed'. This is the kind of polling-lifecycle detail annotations cannot express.
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 tightly written sentences with no filler. The payload contents are front-loaded and the partial/status caveat follows immediately, which is exactly the order an agent needs.
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 single-parameter read tool with annotations and an output schema, the description is nearly complete: it covers the source of the session, the payload, and terminal statuses. The only omission is relation to the generic poll_search_results sibling, which an agent might otherwise confuse it with.
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?
Only one parameter, and schema description coverage is 100% with the sessionId field already documented as coming from search_flights_live; the description repeats that origin without adding format or validation detail. Baseline 3 applies when the schema does the heavy lifting.
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 (returns/polls) and resource (flight search session results), and names the sibling that creates the session, search_flights_live. It does not distinguish itself from the near-identical sibling poll_search_results, so it stops 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?
Usage is implied: the description notes results may be partial while the search runs and that status flips to 'completed'/'failed' when done, which tells the agent to keep polling. However, there is no explicit when-to-use versus poll_search_results, and no exclusion or prerequisite (e.g. session must exist) stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current results of a hotel search session started by search_hotels_live: hotels with their price from each source, and OpenTravel direct listings with the propertyId that get_hotel_detail and get_hotel_info take. Results can be partial while the search runs; status reads 'completed' once every source has answered.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Optional override for the area filter captured at search time | |
| limit | No | Max hotels to return; 0 = all (default 50) | |
| nights | Yes | Number of nights | |
| offset | No | Skip first N hotels for pagination (default 0) | |
| priceMax | No | Optional override for the maximum-price filter | |
| priceMin | No | Optional override for the minimum-price filter | |
| hotelName | No | Optional override for the hotel-name filter captured at search time | |
| sessionId | Yes | Session ID from search_hotels_live | |
| priceCurrency | No | ISO 4217 code of priceMin/priceMax; defaults to the UI language's currency |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| tier | Yes | |
| limit | Yes | |
| cached | No | |
| hotels | Yes | |
| nights | Yes | |
| offset | Yes | |
| status | Yes | |
| checkIn | Yes | |
| fxRates | Yes | |
| hasMore | Yes | |
| checkOut | Yes | |
| language | No | |
| progress | Yes | |
| sessionId | No | |
| agodaStatus | Yes | |
| totalHotels | Yes | |
| bookingStatus | Yes | |
| longStayNotice | No | |
| travelokaStatus | Yes | |
| opentravelStatus | Yes | |
| tier2AgodaStatus | Yes | |
| opentravelResults | Yes | |
| tier2BookingStatus | Yes | |
| tier2TravelokaStatus | Yes | |
| opentravelIndicativeResults | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuine behavioral value beyond that: results can be partial while the search runs, and status flips to 'completed' only once every source has answered. It also flags that OpenTravel listings carry a propertyId consumable by get_hotel_detail/get_hotel_info.
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 purpose and then the polling/completion semantics, with zero wasted wording. Every clause carries information an agent needs.
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?
An output schema exists, so return-value detail is not required, yet the description still sketches the payload (hotels with per-source prices, OpenTravel listings with propertyId). Combined with the partial-results behavior, it covers what an agent needs to poll and chain into detail tools 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 every parameter including the optional override filters is already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 appropriate.
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 ('Returns the current results of a hotel search session') and anchors it to the originating tool, search_hotels_live. This lets an agent distinguish it from search_hotels_live (which starts a search) and from the sibling poll_flight_results 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 clearly establishes the calling context (a session started by search_hotels_live) and tells the agent how to know when to stop polling via the 'completed' status. It stops short of naming explicit when-not conditions, but the usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a booking request for a room at an OpenTravel partner hotel. Nothing is charged and no room is held: the hotel confirms the request by email, and the guest pays at the property on arrival. There is no payment step, now or later. Takes the room and rate from get_hotel_detail and the guest's name, phone number and email; when any of these is missing, the result asks for it and, in clients that show widgets, opens a form for it. One request covers several rooms of the same room type (roomCount), with adults and children counted across all of them; each call is a separate request with its own code, so rooms of one type booked call by call reach the hotel as unrelated requests. Returns one confirmation code for the whole request.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | Yes | Number of adults across ALL rooms of the request — at least one per room | |
| checkIn | Yes | Check-in date YYYY-MM-DD. Must be today or later. | |
| checkOut | Yes | Check-out date YYYY-MM-DD. Must be after checkIn. | |
| children | No | Number of children across ALL rooms of the request (default 0) | |
| currency | Yes | Currency of totalAmount, as quoted by get_hotel_detail for the chosen room. | |
| language | No | Optional response language hint. Only used when queryText gives no signal. | |
| guestName | No | Full name of the primary guest. When omitted, the result asks the user for it. | |
| queryText | No | Short excerpt (one sentence at most) of the guest's latest message in their own words, used only to detect the reply language; it is not stored or forwarded. It carries no names, contact details or other parts of the conversation. | |
| roomCount | No | How many rooms of this room type the guest wants (default 1). All of them go in this one request, under one confirmation code. | |
| guestEmail | No | Email address the confirmation is sent to, as the guest gave it; it cannot be changed after the request is sent. When omitted, the result asks the user for it. | |
| guestPhone | No | Guest phone number; the hotel calls it to confirm the request. When omitted, the result asks the user for it. | |
| propertyId | Yes | OpenTravel propertyId from get_hotel_detail | |
| roomTypeId | Yes | roomTypeId from get_hotel_detail roomTypes array | |
| totalAmount | Yes | Total amount for ALL rooms in the property's base currency: the room's price for the stay × roomCount |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| nextStep | Yes | |
| bookingId | Yes | |
| roomCount | Yes | |
| quotedAmount | Yes | |
| assignedRoomId | Yes | |
| quotedCurrency | Yes | |
| paymentRequired | Yes | |
| confirmationCode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true). It discloses the no-charge/no-hold model, that the hotel confirms by email and the guest pays at check-in, that there is no payment step ever, how missing guest fields are prompted (including widget forms), and that email cannot be changed once sent.
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-loads the most decision-relevant fact (request only, nothing charged, pay at hotel) before mechanics. It is dense and every sentence carries information, though the multi-sentence run-on about call-by-call requests is close to over-explaining.
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 14-parameter, 7-required mutation-ish tool with an output schema present, it covers the missing pieces: charge/confirmation model, dependency on get_hotel_detail, guest-field fallback behavior, and multi-room semantics. Return values are (correctly) left to the output schema aside from noting the single confirmation code.
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 parameters are already well documented; baseline is 3. The description adds useful grouping context (roomCount covers several rooms under one code, adults/children counted across all rooms) but largely restates semantics the schema already carries.
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 ("Sends a booking request for a room at an OpenTravel partner hotel") and immediately frames the transactional model (no charge, hotel confirms, pay on arrival). It names get_hotel_detail as the source of the room/rate, distinguishing it from sibling read/lookup tools and from cancel_booking.
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?
Explains the upstream dependency (take room and rate from get_hotel_detail) and the preconditions for guest fields, and warns that call-by-call bookings of the same room type arrive as unrelated requests. It does not explicitly state when NOT to use it or name the alternative for guest-detail gathering, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First of two steps to cancel a booking. Emails a single-use cancellation token to the address on the booking, given its confirmation code and that same email address. Nothing is cancelled, charged or refunded by this step. The token expires after 24 hours and works once; cancel_booking completes the cancellation with it.
| Name | Required | Description | Default |
|---|---|---|---|
| guestEmail | Yes | Guest email address — must match the booking primary guest email | |
| confirmationCode | Yes | 8-char booking confirmation code, e.g. K7X9M2P4 |
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description goes well beyond: it discloses the side effect (emails a token to the booking address), the token's lifecycle (single-use, expires in 24 hours), and explicitly scopes the blast radius ('nothing is cancelled, charged or refunded'). That is exactly the extra context annotations cannot convey.
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 sentences, front-loaded with the step position, then the mechanism, then the constraints and the handoff. No sentence is redundant and none could be dropped without losing information.
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?
Output schema exists, so return values need not be described. The description still covers sequencing, the real-world side effect, token expiry and single-use, and the handoff to cancel_booking — everything an agent needs to call this correctly and to explain the outcome to a user.
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 the schema already documents both parameters, including the 'must match the booking primary guest email' constraint. The description restates that the email must be the one on the booking but adds no syntax or format 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?
Names a specific verb and resource ('Request Cancellation Link'), states its position in a two-step flow, and distinguishes itself from the sibling that finishes the job (cancel_booking). An agent can tell exactly what this tool does without opening the 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?
Explicitly says this is step 1 of 2, names cancel_booking as the step that 'completes the cancellation with it', and pre-empts the most likely false expectation by stating nothing is cancelled, charged, or refunded. When-to-use and when-not-to-use are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a live one-way flight search for a route and date. Fares come from Agoda and Google Flights. Origin and destination are 3-letter IATA airport codes (for example SGN, HAN, DAD). Returns a session ID; poll_flight_results returns the results. When the route or date is missing, the result is a question for the user instead of a search.
| Name | Required | Description | Default |
|---|---|---|---|
| cabin | No | Cabin class (default economy) | economy |
| adults | No | Number of adults (default 1) | |
| origin | No | Departure airport IATA code, e.g. 'SGN'. When omitted, the result asks the user for it. | |
| language | No | Preferred UI language (en/vi/de/ja/ko/zh/fr/es/ru/th/id). | |
| queryText | No | Optional short excerpt of the current request, used only to detect the UI language; it is not stored or forwarded. | |
| returnDate | No | Return date YYYY-MM-DD. Return flights are not searched at the moment: the result lists outbound flights only. | |
| destination | No | Arrival airport IATA code, e.g. 'HAN'. When omitted, the result asks the user for it. | |
| departureDate | No | Departure date YYYY-MM-DD, today or later. When omitted, the result asks the user for it. |
| Name | Required | Description |
|---|---|---|
| cabin | Yes | |
| adults | Yes | |
| cached | Yes | |
| origin | Yes | |
| status | Yes | |
| language | No | |
| tripType | Yes | |
| sessionId | Yes | |
| returnDate | No | |
| destination | Yes | |
| totalReturn | Yes | |
| departureDate | Yes | |
| returnFlights | Yes | |
| totalOutbound | Yes | |
| outboundFlights | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description is consistent with those signals and adds useful context: live external fare sources, asynchronous session creation, and the fallback behavior when required trip details are missing. It does not cover session expiry or rate limits, but the core behavioral model is clear.
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 description is four tight sentences with no wasted language. The core action and the polling dependency are front-loaded, followed by parameter-format guidance and the missing-information fallback.
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 asynchronous search tool with an output schema, the description covers the essential call flow: start the search, receive a session ID, then poll_flight_results. It also explains external fare sources and the ask-the-user fallback, which are the main behavioral details an agent needs to invoke it 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 the schema already documents parameters such as origin, destination, dates, cabin, adults, language, and queryText. The description reinforces that origin and destination are 3-letter IATA codes and notes the missing-route/date behavior, but it adds little 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?
The description states a specific verb and resource: starts a live one-way flight search for a route and date. It also names the downstream sibling poll_flight_results, so an agent can distinguish this initiation tool from the results-retrieval tool.
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 clearly explains the usage flow: this tool returns a session ID and poll_flight_results returns the results. It also states that missing route or date information yields a question for the user instead of a search. It does not explicitly compare against search_hotels_live, but the flight-specific scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a live hotel search for a city and date range. Prices come from Agoda, Booking.com, Traveloka, Trip.com, Hotels.com and Airbnb, plus direct rates from OpenTravel partner hotels. Returns a session ID; poll_search_results returns the results as they arrive. Optional filters narrow the results by hotel name, area or total price for the stay. Prices depend on the party: it defaults to 2 adults in 1 room, and the result states the party searched and flags when it was defaulted. When the city or dates are missing, the result is a question for the user instead of a search; the stay dates searched are echoed back for confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Optional district, ward, or neighborhood filter within the city | |
| city | No | City or broad destination, e.g. 'Da Nang'. When omitted, the result asks the user for it. | |
| rooms | No | Number of rooms (default 1). | |
| adults | No | Number of adults (default 2). Prices depend on it. | |
| checkIn | No | Check-in date (YYYY-MM-DD), today or later. When omitted, the result asks the user for it. | |
| checkOut | No | Check-out date (YYYY-MM-DD), after checkIn. When omitted, the result asks the user for it. | |
| children | No | Number of children sharing the room (default 0). OTA prices cannot include children; the result says so when children are given. | |
| language | No | Preferred UI language (en/vi/de/ja/ko/zh/fr/es/ru/th/id). | |
| priceMax | No | Maximum total price for the whole stay (not per night), in priceCurrency. | |
| priceMin | No | Minimum total price for the whole stay (not per night), in priceCurrency. | |
| amenities | No | Optional amenities every hotel shown must have, as at least one of its sites lists them: pool, beach, breakfast, parking, gym, spa, airport_shuttle, kitchen, family (family rooms). | |
| hotelName | No | Optional hotel-name filter when the user names a specific property | |
| queryText | No | Optional short excerpt of the current request, used only to detect the UI language; it is not stored or forwarded. | |
| priceCurrency | No | ISO 4217 code of priceMin/priceMax (USD, EUR, VND, …); defaults to the currency of the UI language. |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| tier | Yes | |
| limit | Yes | |
| cached | No | |
| hotels | Yes | |
| nights | Yes | |
| offset | Yes | |
| status | Yes | |
| checkIn | Yes | |
| fxRates | Yes | |
| hasMore | Yes | |
| checkOut | Yes | |
| language | No | |
| progress | Yes | |
| sessionId | No | |
| agodaStatus | Yes | |
| totalHotels | Yes | |
| bookingStatus | Yes | |
| longStayNotice | No | |
| travelokaStatus | Yes | |
| opentravelStatus | Yes | |
| tier2AgodaStatus | Yes | |
| opentravelResults | Yes | |
| tier2BookingStatus | Yes | |
| tier2TravelokaStatus | Yes | |
| opentravelIndicativeResults | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: a session ID is returned rather than results, party size defaults to 2 adults/1 room and is flagged when defaulted, OTA sources are listed, and stay dates are echoed for confirmation. These are behavioral traits an agent could not infer from readOnlyHint/openWorldHint alone.
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?
Five sentences, each carrying distinct information (sources, async handoff, filters, party defaults, missing-input behavior), with the core action front-loaded in the first sentence.
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?
Covers async retrieval, default-party semantics, filter scope and the degenerate no-city/no-dates case; an output schema exists so return shapes need not be spelled out. Nothing essential for correct invocation 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 coverage is 100%, so the baseline is 3; the description nonetheless adds meaning by clarifying that priceMin/priceMax apply to the whole stay rather than per night and that filters narrow by name, area or total price.
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 ('Starts a live hotel search for a city and date range') and names the downstream sibling poll_search_results, so an agent can place it in the workflow without opening the 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?
Explicitly says results are retrieved via poll_search_results and explains the missing-city/dates fallback (returns a question to the user). It lacks exclusions versus siblings like get_hotel_detail or compare_hotel_link, so routing to refinement tools is left implicit.
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.
search_flights_live3 fields changedInput schema / properties / returnDate / anyOfAdded value: +[
+ {
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+ },
+ {
+ "const": "",
+ "type": "string"
+ }
+]Input schema / properties / returnDate / patternRemoved value: -"^\\d{4}-\\d{2}-\\d{2}$"Input schema / properties / returnDate / typeRemoved value: -"string"search_hotels_live1 field changedInput schema / properties / amenitiesAdded value: +{
+ "description": "Optional amenities every hotel shown must have, as at least one of its sites lists them: pool, beach, breakfast, parking, gym, spa, airport_shuttle, kitchen, family (family rooms).",
+ "items": {
+ "enum": [
+ "pool",
+ "beach",
+ "breakfast",
+ "parking",
+ "gym",
+ "spa",
+ "airport_shuttle",
+ "kitchen",
+ "family"
+ ],
+ "type": "string"
+ },
+ "maxItems": 9,
+ "type": "array"
+}compare_hotel_linksearch_flights_live1 field changedInput schema / properties / returnDate / descriptionPrevious value: -"Return date YYYY-MM-DD (omit for one-way). Must be on or after departureDate."New value: +"Return date YYYY-MM-DD. Return flights are not searched at the moment: the result lists outbound flights only."poll_search_results1 field changedOutput schema / properties / hotels / items / properties / prices / properties / airbnbAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}search_hotels_live1 field changedOutput schema / properties / hotels / items / properties / prices / properties / airbnbAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}poll_search_results5 fields changedOutput schema / properties / hotels / items / properties / prices / properties / expediaAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}Output schema / properties / hotels / items / properties / prices / properties / hotelscomAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}Output schema / properties / hotels / items / properties / prices / properties / officialAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}Output schema / properties / hotels / items / properties / prices / properties / pricelineAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}Output schema / properties / hotels / items / properties / prices / properties / tripcomAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}search_hotels_live5 fields changedOutput schema / properties / hotels / items / properties / prices / properties / expediaAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}Output schema / properties / hotels / items / properties / prices / properties / hotelscomAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}Output schema / properties / hotels / items / properties / prices / properties / officialAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}Output schema / properties / hotels / items / properties / prices / properties / pricelineAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}Output schema / properties / hotels / items / properties / prices / properties / tripcomAdded value: +{
+ "$ref": "#/properties/hotels/items/properties/prices/properties/agoda"
+}request_booking6 fields changedInput schema / properties / adults / descriptionPrevious value: -"Number of adults"New value: +"Number of adults across ALL rooms of the request — at least one per room"Input schema / properties / children / descriptionPrevious value: -"Number of children (default 0)"New value: +"Number of children across ALL rooms of the request (default 0)"Input schema / properties / roomCountAdded value: +{
+ "default": 1,
+ "description": "How many rooms of this room type the guest wants (default 1). All of them go in this one request, under one confirmation code.",
+ "maximum": 10,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / totalAmount / descriptionPrevious value: -"Total amount in the property's base currency"New value: +"Total amount for ALL rooms in the property's base currency: the room's price for the stay × roomCount"Output schema / properties / roomCountAdded value: +{
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "bookingId",
- "confirmationCode",
- "status",
- "paymentRequired",
- "nextStep",
- "assignedRoomId",
- "quotedAmount",
- "quotedCurrency"
-]New value: +[
+ "bookingId",
+ "confirmationCode",
+ "status",
+ "paymentRequired",
+ "nextStep",
+ "assignedRoomId",
+ "roomCount",
+ "quotedAmount",
+ "quotedCurrency"
+]cancel_booking2 fields changedInput schema / properties / confirmationCode / minLengthRemoved value: -1Input schema / properties / confirmationCode / patternAdded value: +"^[A-Za-z0-9]{4,32}$"check_booking_status1 field changedInput schema / properties / confirmationCode / patternAdded value: +"^[A-Za-z0-9]{4,32}$"poll_search_results3 fields changedInput schema / properties / sessionId / maxLengthRemoved value: -128Input schema / properties / sessionId / minLengthRemoved value: -1Input schema / properties / sessionId / patternAdded value: +"^[A-Za-z0-9_-]{1,64}(\\.[A-Za-z0-9_-]{1,16})?$"request_booking1 field changedInput schema / properties / propertyId / formatAdded value: +"uuid"request_cancel_token2 fields changedInput schema / properties / confirmationCode / minLengthRemoved value: -1Input schema / properties / confirmationCode / patternAdded value: +"^[A-Za-z0-9]{4,32}$"cancel_bookingcheck_booking_statusget_cancellation_policyget_hotel_detailget_hotel_infoget_ota_hotel_detailpoll_flight_resultspoll_search_resultsrequest_bookingrequest_cancel_tokensearch_flights_livesearch_hotels_liveLive flight, hotel and seat prices, cheapest-day calendars, and price-drop alerts.
Search hotels & rentals: live prices & reviews across Booking.com, Airbnb, Vrbo & Google Hotels.
Live hotel and resort prices (taxes included) and secure booking links for travelers. Since 1993.
Hotel and product prices: Booking.com, Google Hotels, Expedia, Agoda, Airbnb, Amazon, Walmart, eBay.
Add one secure layer between your agents and this server.
