Virtuoso luxury hotels with perks included: search 2,000+, get a quote, book. Pay hotels directly.
Scored across 14 tools
There are parallel booking concepts (create_booking vs create_booking_session, cancel_booking vs cancel_booking_session, get_booking_status vs get_booking_session) that can easily be confused despite detailed descriptions. The async availability/quote flow and advisor request flow also overlap, though descriptions mostly clarify when to use each.
All tools use a consistent snake_case verb_noun pattern. Session-related tools also consistently share the _booking_session suffix, making the naming predictable overall.
With 14 tools, the server fits the typical well-scoped range. The count is reasonable for a travel booking domain that includes search, quoting, session management, and advisor requests.
The booking-session lifecycle is well covered with create, get, update, complete, and cancel, plus search and quoting. Minor gaps exist around listing bookings and tracking non-session itinerary requests, but the advisor workflow provides workarounds.
Cancel a booking request. A confirmed hotel reservation is cancelled with the hotel under its own cancellation policy, which comes with the quote and the confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Reason for cancellation | |
| booking_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It notes that cancellation happens with the hotel under its own policy and that the policy comes with the quote and confirmation, but it omits critical traits for a destructive operation: irreversibility, fees/refunds, permissions, and what happens to the booking record.
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 two tight sentences, front-loaded with the primary action and followed by relevant cancellation-policy context. There is no wasted wording.
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 annotations, no output schema, and only 50% schema coverage, the description should do more. It lacks sibling differentiation, explicit usage guidance, parameter clarification, and the operational consequences of cancellation, leaving the definition under-specified for a destructive 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 description coverage is only 50%: the reason parameter is documented in the schema, but booking_id is not. The description adds no parameter-level meaning and does not compensate for the undocumented booking_id.
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: cancel a booking request, specifically a confirmed hotel reservation. It is clear what the tool does, but it does not distinguish itself from the sibling tool cancel_booking_session, which could cause confusion.
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 by the mention of confirmed hotel reservations and cancellation policy, but there is no explicit guidance on when to use this tool versus cancel_booking_session or other booking-related siblings. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SENSITIVE WRITE. Withdraws a booking before the hotel confirms it (the advisor is told). Confirmed reservations are cancelled with the hotel under its cancellation policy, through the advisor.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive and open-world, but the description adds real value beyond them: the advisor gets notified and confirmed reservations are handled under the hotel's cancellation policy rather than simply voided. It doesn't say what happens to the session record afterward or how failures surface.
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 critical warning 'SENSITIVE WRITE' is front-loaded, and all three sentences carry distinct information: severity, scope of the pre-confirmation case, and the confirmed-reservation fallback. 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?
For a one-parameter destructive mutation with no output schema, the description covers consequences and the advisor side effect reasonably well. The key gap is parameter meaning and any indication of what state the booking session is left in, which an agent needs before calling a destructive 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 0% and the single required parameter session_id is never explained — the description doesn't say it is a booking-session ID or where to obtain it (e.g., from get_booking_session or create_booking_session). With no annotation or schema help here, the description should compensate and does not.
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 (withdraws a booking) plus a temporal scope condition (before the hotel confirms it) that separates it from the sibling cancel_booking for confirmed reservations. It never names cancel_booking explicitly, so the differentiation must be inferred.
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 'before the hotel confirms it' clause implies when to use it, and the second sentence sketches the alternative path for confirmed reservations. But it doesn't name the alternative tool or state an exclusion directly, leaving the agent to map 'confirmed reservations ... through the advisor' to cancel_booking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a request goes straight to Geisel Power, the Virtuoso advisor, for a quote (hotel stays always do).
| Name | Required | Description | Default |
|---|---|---|---|
| trip_id | Yes | ||
| num_nights | No | ||
| num_travelers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description contributes one genuinely useful behavioral rule not present in structured fields: hotel stays always go direct. It says nothing about what the check returns (boolean vs. routing object) or what happens when required inputs are missing, which matters given there is no 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 with no filler; the key condition (hotel stays always direct) is in a parenthetical immediately after the main claim. Slight loss for the trailing parenthetical being the most decision-relevant fact.
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, so the description should say what the check yields, and it does not. Combined with 0% parameter coverage and a mutation-adjacent workflow (quote routing before booking), the definition leaves too much for the agent to infer.
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 0% across three parameters (trip_id, num_nights, num_travelers), and the description mentions none of them. It hints that stays/nights matter via the hotel-stay rule, but never explains why num_nights or num_travelers influence the routing decision or what trip_id must reference.
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 concrete decision the tool answers: whether a request routes straight to Geisel Power for a quote, with hotel stays always qualifying. However, it never ties back to the tool name 'check_complexity' or names the entity being checked (a trip? a booking request?), and the jargon 'Geisel Power, the Virtuoso advisor' assumes domain knowledge. An agent can guess the purpose but cannot cleanly restate it.
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 when-to-use or when-not-to-use guidance is given, and no sibling is named as an alternative (e.g., get_availability_quote, create_booking). The only implied trigger is the hotel-stay special case, which is a routing rule rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SENSITIVE WRITE — get the traveler's explicit approval of the full total and the hotel's cancellation policy first. Asks Geisel Power to place the reservation. No payment is taken: the traveler pays the hotel directly under its own terms, and hotel bookings carry no fee. Returns complete_in_progress with a confirmation deadline (within 24 hours); poll get_booking_session for the hotel's confirmation number, which is also emailed to the traveler.
| Name | Required | Description | Default |
|---|---|---|---|
| booker | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: no payment is taken, the traveler pays the hotel directly, hotel bookings carry no fee, and the call returns complete_in_progress with a 24-hour confirmation deadline plus email notification. It does not explain the destructiveHint implications (what consuming the session does) or clarify what happens on repeated calls despite idempotentHint=true, leaving a small gap.
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 safety warning, then purpose, then economics, then return/poll behavior — four tight sentences with no filler. The parenthetical deadline is compact and useful.
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 return-value burden well by naming the complete_in_progress status, the deadline, and how the confirmation number arrives. The only meaningful omission is guidance on the session_id/booker parameters.
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 0% and the description never mentions session_id or the nested booker fields (first/last name, email, phone). With two required parameters, one of them a nested object, the description should at least say where the session_id comes from and whether the booker must be the traveler; it does neither.
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 action ('Asks Geisel Power to place the reservation') on a specific resource and marks it as a SENSITIVE WRITE, which cleanly separates it from create_booking_session, update_booking_session, and cancel_booking_session. An agent can identify 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?
Explicit precondition is given: obtain the traveler's explicit approval of the full total and cancellation policy before calling. It also names the follow-up path ('poll get_booking_session for the hotel's confirmation number'), so both the gate and the next step are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the steps to book a hotel, cruise or experience found with search_trips. Geisel Power, the Virtuoso advisor, quotes it in writing within 24 hours (rate, taxes, the hotel's cancellation policy and the perks) and books only after the traveler approves. This tool sends nothing itself (request_sent: false). Hotel bookings carry no fee and nothing is charged by Stay Perks: the traveler pays the hotel directly.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_id | Yes | ||
| num_nights | No | ||
| traveler_info | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint/openWorldHint: it discloses that nothing is sent (request_sent: false), that a named human advisor quotes in writing within 24 hours, that booking only occurs after traveler approval, and that no fee is charged with payment going directly to the hotel. This is exactly the side-effect and timing context an agent needs before calling.
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 action and workflow reference, then layers on the advisor/approval and fee details in compact sentences. The advisor's name is mildly decorative but the rest 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?
Behavioral context is thorough for a read-only, non-destructive tool with no output schema, but the nested and completely undocumented parameters leave a real hole in what an agent needs 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 description coverage is 0% and traveler_info is a nested object with six sub-fields, none of which the description explains. The text never mentions trip_id, num_nights, or any traveler_info field, so an agent gets no guidance on what to supply or how the fields are used.
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 outcome ('get the steps to book a hotel, cruise or experience') and ties it to a sibling ('found with search_trips'). It is clear this tool produces guidance rather than a reservation, which distinguishes it from create_booking_session, though the mismatch with the imperative name 'create_booking' leaves some initial ambiguity that the body has to repair.
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?
Implies the workflow ('found with search_trips' → get steps) but never says explicitly when to pick this over create_booking_session or complete_booking_session, nor what preconditions exist. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Opens a UCP lodging booking session from a quoted offer (stay_id from get_availability_quote). Returns the authoritative total, the cancellation policy (show it to the traveler), the Virtuoso amenities, the payment term (pay at the hotel) and evidence. Nothing is charged; the session is held until the quote expires.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | ||
| booker | No | Lead traveler (legal name + email). Without it the session stays "incomplete". | |
| stay_id | Yes | stay_id of a quoted offer | |
| children | No | ||
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that nothing is charged, that the session is held only until the quote expires, and that the cancellation policy must be shown to the traveler. The 'WRITE' marker matches readOnlyHint=false and destructiveHint=false, so there is no contradiction.
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 'WRITE.' then purpose, then returned data, then the safety note; every sentence carries distinct information and there is no padding.
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 correctly enumerates the meaningful return values (authoritative total, cancellation policy, amenities, payment term, evidence). The main gap is the lack of guidance on property_id/adults/children, though these are largely self-evident.
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 40%, so the description must compensate. It adequately explains stay_id's provenance and the schema itself covers booker's behavior ('incomplete' without it), but property_id, adults and children receive no meaning in either place.
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 ('Opens a UCP lodging booking session from a quoted offer') and ties the key input to its producing sibling (get_availability_quote). Differentiation from create_booking and complete_booking_session is only implied by the session-vs-booking wording, not called out by name.
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 prerequisite is explicit: the session is built from a quote, and stay_id must come from get_availability_quote. It does not explicitly say when to choose this over create_booking or complete_booking_session, so context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
READ. Returns the status of a quote from search_availability: "pending" (try again later), "quoted" (offers with stay_id, full total, cancellation terms), "unavailable", or "expired". Use an offer's stay_id with create_booking_session.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | Quote id returned by search_availability |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value by enumerating the four possible states and what 'pending' means for polling behavior, plus what a 'quoted' result contains (stay_id, total, cancellation terms).
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 and dense in two sentences, with the state enumeration carrying most of the information. The leading 'READ.' is redundant with readOnlyHint and is the only wasted token.
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?
There is no output schema, so the description must carry the return semantics — and it does, listing every state and the shape of a successful quote. Combined with the single well-documented parameter, an agent has everything needed to call and interpret this 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?
Only one parameter with 100% schema description coverage ('Quote id returned by search_availability'), so the schema already does the work. The description repeats the same origin of quote_id without adding format or validation detail; 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 status of a quote from search_availability') and anchors the tool to its producer sibling, so the agent knows exactly which object this reads. Distinct from create_booking_session / cancel_booking_session among siblings.
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 workflow explicitly: obtain quote_id from search_availability, and when the state is 'quoted' use the offer's stay_id with create_booking_session. It even tells the agent to retry on 'pending'. It stops short of stating when not to use it, but the routing is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
READ. Current state of a booking session: ready_for_complete (awaiting the traveler's approval), complete_in_progress (the advisor is placing the reservation), completed (includes the hotel's own confirmation number; the traveler is also emailed), or canceled.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read semantics need no restatement. The description nevertheless adds genuine value by enumerating the four possible states and disclosing downstream effects: completed carries the hotel's own confirmation number and the traveler is emailed, and complete_in_progress means the advisor is actively placing the reservation. It does not cover error behavior for an invalid or expired session_id.
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 a compact state enumeration; the parentheticals earn their place by conveying approval/implicit side effects. The leading 'READ.' is redundant against readOnlyHint=true and is the one wasted token.
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 one-parameter read tool with no output schema, the description covers the key return semantics by naming every terminal and in-flight state and what 'completed' carries. What the response otherwise contains (other session fields) and how failures surface is left unstated, so it falls just short of complete.
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 0%: session_id is typed string but has no schema-level definition, and the description never mentions the parameter or where to obtain it (e.g., from create_booking_session). The parameter is self-evident from its name, which limits the damage, but the description does nothing to compensate for the coverage 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?
The description states a specific resource (a booking session) and what it returns (current state), and the title reinforces the read intent. It does not distinguish itself from nearby siblings like get_booking_status or get_trip_details, which an agent could plausibly confuse with this 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?
Usage is only implied: having a session_id, you call this to check where the session stands. There is no explicit guidance on when to prefer this over get_booking_status, get_trip_details, or get_booking_session's mutation siblings, and no preconditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an existing booking
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that—no indication of what status values may be returned, whether the status is real-time or cached, or what happens for a cancelled/unknown booking.
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 no filler. It is efficient but so short that the brevity comes at the cost of the missing detail noted elsewhere.
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?
There is no output schema, so the description should describe the return payload (status fields, possible states, error behavior for unknown IDs) and it says nothing. For a status-lookup tool the return semantics are the core value, and they are entirely absent.
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 0%, so the description must compensate and it does not: booking_id has no documented format, source, or example. 'Existing booking' only hints that the ID must reference a real booking, leaving the agent to guess the identifier's shape.
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 ('check') and resource ('status of an existing booking'), which is clear enough to distinguish it from mutation siblings like cancel_booking and create_booking. It is less clearly differentiated from read siblings such as get_booking_session and get_trip_details, which the description never mentions.
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 guidance on when to use this versus get_booking_session, get_trip_details, or search_availability, all of which likely return overlapping booking information. The phrase 'existing booking' only weakly implies a prerequisite (the booking must already exist) and gives no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the details of a hotel, package, cruise or private experience from search_trips, with a hotel's Virtuoso perks. Virtuoso records carry no published rate or availability; the advisor quotes those in writing within 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_id | Yes | trip_id from search_trips, or a hotel's virtuoso_property_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly and closed-world, and the description adds genuinely new behavioral context: Virtuoso records carry no published rate or availability, and an advisor quotes in writing within 24 hours. It also discloses that responses include a hotel's Virtuoso perks. It stops short of describing error behavior or what a non-Virtuoso record returns.
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, with the core action and source leading and the Virtuoso caveat following as a secondary constraint. Nothing 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?
For a one-parameter read tool with no output schema, the description sets the right expectations about response content (perks) and its limits (no rate/availability, 24-hour written quote). Only minor gaps remain, such as behavior when the trip_id is invalid or not found.
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% and the schema already states trip_id comes from search_trips or a virtuoso_property_id. The description repeats the search_trips origin without adding format, fallback, or edge-case guidance, 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?
States a specific verb (get details) plus the exact resource types (hotel, package, cruise, private experience) and anchors the source to search_trips, a named sibling. An agent can distinguish this from search_trips or get_availability_quote 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?
Explicitly ties invocation to a prior search_trips call and names the input it expects, which is clear usage context. The Virtuoso note implicitly signals that rate/availability questions belong elsewhere (e.g., get_availability_quote), but no sibling is named as an alternative for that need, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Send Geisel Power, the Virtuoso advisor, the traveler's request for a Journey (Journeys by Geisel Power: a whole trip she plans, books and confirms, usually from about $15,000 to $20,000) or a hotel stay (Stay Perks Reserve, no minimum). Call it only after the traveler has agreed to share their name, email and trip details with Geisel Power, and set traveler_consented to true. Returns a reference and what happens next: Geisel replies to a Journeys request the same day, with the full proposal after a discovery call, and to a hotel request in writing within 24 hours; some requests also get a link to book a 30-minute call with her (call_url). Nothing is booked or charged. Hotel bookings carry no fee and the traveler pays the hotel directly; a Journey carries a planning fee, which depends on the trip's length and complexity and which Geisel explains on the discovery call.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | journey (the default): a whole trip Geisel designs; hotel: a hotel stay only | |
| name | Yes | The traveler's full name | |
| Yes | The traveler's email: Geisel replies there | ||
| notes | No | Anything else the traveler wants Geisel to know | |
| occasion | No | What the trip is for: anniversary (Anniversary or honeymoon), birthday (A milestone birthday), family (Family or multigenerational trip), celebration (Another celebration), business (Business with some leisure), escape (Simply time away) | |
| travelers | No | Who is traveling ("2 adults, 1 child") | |
| flexibility | No | How flexible the dates are: exact (Exact dates), few-days (A few days either way), month (Any time in a month), open (Open, advise me) | |
| trip_budget | No | The whole trip's budget in USD, for a Journey: under-15k (Under $15,000), 15k-20k ($15,000 to $20,000), 20k-50k ($20,000 to $50,000), 50k-plus ($50,000 or more). No budget is needed for a hotel stay | |
| destinations | No | Where: places, regions or hotels ("Amalfi Coast, Lake Como") | |
| travel_dates | No | When ("10 to 20 May 2027", "late spring") | |
| traveler_consented | Yes | true, and only once the traveler has agreed to share these details with Geisel Power |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say write/open-world/non-idempotent/non-destructive; the description goes far beyond them by disclosing response SLAs (same day, written reply within 24 hours), the optional call_url, that no charge occurs, who pays whom, and that a Journey carries a planning fee explained on the discovery call. That is exactly the context an agent needs to set expectations and obtain consent.
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 "WRITE" and the core action, then moves to precondition, then returns. It is a dense single paragraph with a few long parentheticals (the $15,000–$20,000 range) that could be tightened, but no sentence is pure 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 11 params and no output schema, the description still tells the agent what comes back (a reference and next steps, plus a possible call_url) and what does not happen (no booking, no charge). Consent, pricing model and follow-up timing are all covered, so an agent can call it correctly and explain the outcome.
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% and the enum labels already carry the explanations (kind, occasion, flexibility, trip_budget), so the description adds little parameter-level meaning. The one useful cross-parameter note — budget applies to a Journey, not a hotel stay — is already in the schema too, leaving the baseline 3.
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 "WRITE" and a specific verb+resource: send the traveler's request to a named advisor for either a Journey or a hotel stay. It also draws the line against the booking siblings by stating "Nothing is booked or charged," so an agent can tell this apart from create_booking 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?
Gives an explicit precondition: call only after the traveler agreed to share name, email and trip details, with traveler_consented set true. It does not name a sibling alternative (e.g. create_booking for an actual reservation), so routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Ask Geisel Power, the Virtuoso advisor, to price a stay at a Virtuoso hotel (property_id from search_trips). Virtuoso data carries no live rates, so pricing is asynchronous: this returns a quote id with status "pending" and a quote_due_by time (within 24 hours); poll get_availability_quote. A firm offer includes the full total, taxes and fees, the hotel's cancellation policy, and the Virtuoso amenities (e.g. breakfast for two, a hotel credit, an upgrade, subject to availability). Nothing is reserved or charged by this call, and hotel bookings carry no fee.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | Yes | Number of adults | |
| children | No | Number of children | |
| end_date | Yes | Check-out date, YYYY-MM-DD | |
| start_date | Yes | Check-in date, YYYY-MM-DD | |
| property_id | Yes | Virtuoso property id (virtuoso_property_id) from search_trips |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description explains the asynchronous pricing model, the pending status, the 24-hour quote window, and what a firm offer contains. This is exactly the behavioral context needed for a non-idempotent, open-world write-shaped request that does not itself reserve or charge.
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 "WRITE" and then moves directly through purpose, async behavior, polling, and booking implications. Every sentence contributes either selection guidance or behavioral clarity, with no wasted framing.
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?
There is no output schema, so the description must explain the return behavior, and it does: a quote id, pending status, quote_due_by, polling via get_availability_quote, and the contents of a firm offer. It also covers the key non-effects of the call, making it complete for an agent to invoke and interpret 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 all five parameters. The description adds useful routing context for property_id, but does not add syntax or meaning for dates, adults, or children beyond what the schema provides, making the baseline score 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?
The description states a specific verb and resource: asking the Virtuoso advisor to price a stay at a Virtuoso hotel. It also distinguishes the call from search_trips (source of property_id) and get_availability_quote (the polling step), so an agent can identify its role without opening other schemas.
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 explicitly says when to use this tool and how to continue afterward: obtain property_id from search_trips, expect an asynchronous quote, and poll get_availability_quote. It also clarifies that no reservation or charge occurs, which prevents an agent from treating it as a booking action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 2,000+ Virtuoso hotels, plus packages, cruises and private experiences, by place, brand or kind of stay. Results show whether Virtuoso perks apply, a trip_id for get_trip_details, and how to book. No live rates: the advisor quotes them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page, up to 50 (default 10) | |
| offset | No | Results to skip, for the next page | |
| check_in | No | Check-in date (ISO 8601) | |
| check_out | No | Check-out date (ISO 8601) | |
| trip_type | No | hotel_only (the default), fixed_package, cruise, service (private experiences) or custom_itinerary | |
| budget_usd | No | Max budget in USD | |
| destination | No | A city, region or country ("Paris", "Tuscany", "Caribbean"), a hotel or brand ("Four Seasons"), both ("Four Seasons Paris"), or a kind of stay ("beach", "safari") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false; the description goes beyond them by disclosing return content (Virtuoso perk eligibility, a trip_id usable with get_trip_details, booking instructions) and by warning that no live rates are returned. A permissions/visibility caveat or result-ordering note would push this higher.
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 short sentences: capability first, then result contents, then the rate caveat. Zero filler and no repetition of schema or annotation content.
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 usefully sketches what comes back (perks, trip_id, booking path) and warns about the missing rate data, which is enough for correct invocation alongside a fully documented 7-parameter schema. Minor gaps: no mention of default trip_type behavior or how to page, though limit/offset are schema-documented.
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 limit, offset, dates, trip_type enum, budget_usd and destination are all documented in structured form. The description's 'by place, brand or kind of stay' loosely echoes the destination parameter but adds no syntax or format 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?
States a specific verb and resource plus the exact inventory searched (2,000+ Virtuoso hotels, packages, cruises, private experiences) and the query axes (place, brand, kind of stay). It also separates itself from the rate-related siblings by declaring 'No live rates: the advisor quotes them,' and names get_trip_details as the follow-up, so an agent can route correctly 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 clear context for when to call it (discovery by destination/brand/stay type) and an explicit exclusion for live pricing, which routes rate questions to availability/quote tools. It stops short of naming those siblings directly, so the exclusions are implied rather than enumerated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE. Change occupancy (within the quote) or set the booker before completing. Not allowed after completion.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | ||
| booker | No | ||
| children | No | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the idempotent, non-destructive write profile, and the description adds real context beyond them: the occupancy value must remain within the existing quote, and the call is only valid pre-completion. It doesn't say what happens to fields that are omitted (partial vs. full replacement).
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, the write nature front-loaded and the precondition trailing. Nothing repeats the annotations verbatim or wastes tokens.
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?
The lifecycle guard is covered, but with a nested booker object at 0% schema coverage, no output schema, and no statement about partial-update semantics or the quote constraint's error behavior, an agent still has to guess at invocation details.
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 0%, and the description only glosses two of the four parameters ('occupancy' and 'booker'). It never mentions session_id, the required booker sub-fields (first/last name, email), or that children may be set independently of adults.
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 specific mutable fields (occupancy, booker) on the booking session and leads with 'WRITE', so the agent can distinguish it from complete_booking_session or cancel_booking_session. The resource is never named explicitly, which keeps it 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?
'before completing' and 'Not allowed after completion' give a clear lifecycle window plus an explicit exclusion. The alternative tool (complete_booking_session) is implied rather than named, so it misses the top band.
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.
request_itinerarycancel_bookingcancel_booking_sessioncheck_complexitycomplete_booking_sessioncreate_bookingcreate_booking_sessionget_availability_quoteget_booking_sessionget_booking_statusget_trip_detailssearch_availabilitysearch_tripsupdate_booking_sessionLuxury hotel search, rate comparison, booking quotes, and secure checkout handoff.
Search, quote and book independent hotels: official rates, live availability, pay at the hotel.
Hotel direct booking for VIP and corporate rates - upgrades and loyalty eligible, 100K+ hotels
Travel: live hotel rates with advisor benefits (breakfast, credit, upgrade), booked via a US agency.
Add one secure layer between your agents and this server.
