GetMyHotels

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

The description aligns with annotations (non-read-only, non-destructive write). It adds clarity that the operation is additive, but lacks details on side effects like duplicate handling or permission requirements.

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 a single, well-structured sentence that front-loads the action and resource, with no unnecessary words.

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 description lacks information about return values or error conditions, which is notable given no output schema. It is adequate for a simple mutation but incomplete for full behavioral clarity.

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 well-documented. The description adds minimal extra meaning (e.g., example types), but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the verb 'Add', the resource 'item', and the context 'to a saved trip on a given day'. It distinguishes the tool from siblings like save_trip (which saves the trip itself) and list_trips (which lists trips).

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 description implies usage context (adding items to a trip) but does not explicitly state when to use this tool over alternatives, such as save_trip for creating trips, or any conditions for not using it (e.g., if the trip does not exist).

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

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

Annotations already indicate destructiveHint=true. The description adds that the action may be irreversible and can trigger a refund, providing behavioral context beyond the annotation alone. It also mentions the verification code requirement, which is a key behavioral constraint.

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 very concise at three sentences, covering purpose, prerequisite, and consequence with no unnecessary words. It front-loads the core action.

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 relatively simple cancellation tool with annotations and full schema coverage, the description covers the essentials: what it does, what is needed, and the outcome. It could optionally mention how the result is returned or if there is any confirmation, but it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides descriptions for all three parameters (100% coverage). The description references the verificationCode and its source, but this is redundant with the schema. It does not add new semantic information beyond the schema.

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

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

The description explicitly states the verb 'cancel' and the resource 'booking', and specifies it cancels one of the signed-in user's bookings. This clearly distinguishes it from sibling tools like modify_booking or request_booking_action_code.

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 description identifies a clear prerequisite: the verification code from request_booking_action_code. It also notes that cancellation may be irreversible and can trigger a refund, which guides the agent on implications. However, it does not explicitly state when not to use this tool (e.g., for modifications).

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false, so the tool modifies state. The description adds that it does not charge the card but creates a checkout that defers payment. However, it does not clarify whether it reserves/holds inventory or expiration behavior.

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: first states purpose and output, second clarifies payment, third gives prerequisite steps. Every sentence adds value, front-loaded with key 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?

Provides the essential workflow: prerequisite quote, confirmation requirement, output URL. Missing details like expiration of the checkout or whether inventory is temporarily held, but overall adequate for an agent to invoke 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?

Input schema describes all 14 parameters fully (100% coverage). The description adds context by linking price to 'get_checkout_quote' and ref to 'search_hotels', but does not add new semantic detail beyond the schema.

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

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

The description clearly states the tool creates a secure checkout for a hotel room and returns a getmyhotels.com URL for payment. It distinguishes from siblings like 'create_one_click_checkout' by focusing on a hosted payment page.

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 instructs to confirm hotel/room/dates/price with user before calling, and to call 'get_checkout_quote' first to confirm live price. Also clarifies that the tool does not charge the card, guiding when to use it vs. other payment flows.

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

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

Annotations already indicate destructiveHint=true, and the description adds that no charge occurs—the user confirms on the hosted page. This clarifies an important behavioral trait beyond annotations. It doesn't cover idempotency or rate limits, but the key 'no charge' is well-disclosed.

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 concise sentences, front-loaded with purpose, then behavioral clarification, then source hint. No wasted words.

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?

Given 14 parameters and no output schema, the description covers purpose, key behaviors, and preconditions. It lacks error handling or output format, but the essential context for safe invocation is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds sourcing hints (e.g., savedPaymentMethodPublicId from list_payment_methods, grandTotal for price) but doesn't elaborate on each parameter. Extra value is modest.

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 clearly states the tool creates a one-click checkout for signed-in users with a saved card, returning a confirmation URL. It distinguishes this from a standard checkout by emphasizing the one-click aspect and saved card pre-selection.

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 guidance is given: get the savedPaymentMethodPublicId from list_payment_methods, confirm hotel/room/dates/price with the user first. It also clarifies that the tool does not charge the card. However, it doesn't explicitly compare to the sibling create_checkout, so a slight deduction.

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

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

Annotations provide readOnlyHint and openWorldHint. Description adds return fields but no additional behavioral traits (e.g., error handling, auth requirements). Adequate but minimal extra value.

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 input types. No fluff, every word serves a purpose. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 1-parameter fetch without output schema, the description adequately explains input types and return fields. Missing details on error behavior or potential unexpected results, but overall sufficient.

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 its description already specifies the id types. The tool description repeats the schema description, adding no new semantic meaning for the parameter. Baseline score 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?

Clearly states it fetches full record for result ids or booking refs. Verb 'fetch' with specific resource types. Lacks explicit differentiation from sibling tools like get_booking or get_hotel_details, but purpose is unambiguous.

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?

Tells when to use (with result id or booking ref) but no guidance on when not to use or alternatives among siblings like get_booking or get_hotel_details. Incomplete contextual advice.

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

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

Annotations indicate readOnlyHint=true, and description adds that it returns booking status, hotel, dates, and guest details, providing useful behavioral context beyond annotations.

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 key information, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup with one required parameter and no output schema, the description sufficiently covers purpose, input, and output fields.

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% with a description for the parameter. Description repeats the token's source but adds no new meaning beyond the schema.

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

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

Description clearly states the verb 'look up' and resource 'hotel booking', and distinguishes from sibling tools like get_my_booking and cancel_booking by specifying the management token as the identifier.

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 to use the management token from the confirmation email, but does not mention when not to use or provide alternatives like get_my_booking for user-specific lookups.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds value by detailing the live re-pricing nature, no charge, and the returned data (grand total, rateValidUntil, taxes/fees). No contradiction with annotations.

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 sentences: first sentence states the core action and constraints, second provides usage guidance and return type. No filler words, front-loaded with purpose, every sentence is informative.

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?

Given 13 parameters and no output schema, the description names the returned fields (grand total, rateValidUntil, taxes/fees) and links to search_hotels. It could be more complete by explaining the ref vs supplierCode+supplierHotelId choice or mentioning expiration of the quote, but it adequately covers the core flow.

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% with descriptions for all 13 parameters. The description adds meaning beyond schema by explaining the relationship to search_hotels (e.g., using supplierRoomId and price/currency from there) and the purpose of totalPrice for detecting price changes. This enhances parameter understanding.

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 uses a specific verb ('re-price') and resource ('room'), clarifies it's live against the supplier before checkout, and explicitly states no booking/charge. It distinguishes from siblings like search_hotels (search) and create_checkout (booking) by positioning itself as a pre-checkout re-pricing step.

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 description tells when to use the tool ('before checkout') and references the necessary prior call to search_hotels. It does not explicitly list alternatives or when not to use, but the context of 'no booking, no charge' clearly implies it is for price verification only.

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

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

The description adds value beyond annotations (readOnlyHint, openWorldHint) by specifying the exact categories of details returned. It also clarifies the identification mechanisms. No contradictions with annotations. It does not mention latency or rate limits, but the annotation already signals a safe read operation.

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 a single concise sentence that front-loads the essential action and includes the most important usage note. Every word contributes value; no filler or redundancy.

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?

Given the lack of an output schema, the description reasonably covers what the tool returns (description, amenities, photos, policies, location). It explains how to identify the hotel. It may slightly under-specify error conditions or behavior when both identification methods are provided, but overall it is sufficiently complete for an AI agent.

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?

Although the input schema already covers the three parameters with descriptions, the description adds the crucial semantic that ref and supplierCode+supplierHotelId are alternative ways to identify the hotel. This relationship is not explicit in the schema alone. The schema coverage is high, but the description enhances parameter understanding.

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 clearly states the action ('Get full property details') and the resource (hotel details including description, amenities, photos, policies, location). It distinguishes itself from siblings by specifying the identification method (ref from search_hotels or alternative supplierCode+supplierHotelId), making the tool's purpose unambiguous.

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 description provides a clear usage context: after a search using search_hotels, to retrieve detailed information. It explains alternative identification methods but does not explicitly state when not to use this tool or compare with siblings like get_rooms or search_hotels. However, the context is sufficient for an AI agent to decide when to invoke it.

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

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

Annotations provide readOnlyHint=true, so the read-only nature is covered. Description adds authentication scope (signed-in user) but no further behavioral details like rate limits or response structure. Acceptable given annotations.

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?

Single sentence, front-loaded with purpose, no unnecessary words. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get-by-id operation with annotations present, the description is largely complete. It could optionally mention the return format or fields, but the typical expectation is the full booking details. Minor gap in not explaining the response structure.

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% with a clear description for the single parameter. Description does not add new information beyond the schema ('by its public id' restates the schema's 'The booking\'s public id.'). Baseline score 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?

Description clearly states the action (Get full details), resource (one of the signed-in user's bookings), and identifier (public id). It distinguishes from siblings like 'get_booking' (any booking) and 'list_my_bookings' (all bookings).

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?

Description implies usage context (signed-in user, by public id) but does not explicitly state when to use this tool vs alternatives like 'get_booking' or 'list_my_bookings'. No when-not or prerequisites are mentioned.

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

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

Annotations already indicate readOnlyHint: true and openWorldHint: true. The description adds that it lists 'bookable' rooms (availability-sensitive) and that each room's `supplierRoomId` is used downstream, which is useful context beyond annotations.

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 well-structured sentences: first states core purpose, second explains output's role in downstream tools, third provides usage scenarios. No redundant 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?

Given no output schema and 8 parameters (100% schema docs), the description covers the essential: what the tool returns (rooms with supplierRoomId), how to get the ref, and when to call. It doesn't detail optional parameters but they are schema-described. Satisfactory for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how the `ref` parameter relates to search results and the output `supplierRoomId` usage, but does not elaborate on other parameters like checkIn/checkOut format or the meaning of rooms/adults/children beyond what's in the schema.

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

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

The description clearly states the tool lists bookable rooms for a specific hotel and date range, using the verb 'list' and specifying the resource 'rooms for ONE hotel and date range'. It also distinguishes from sibling tools like search_hotels and get_checkout_quote by mentioning the `supplierRoomId` connection.

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 guidance: 'Use the hotel `ref` from `search_hotels` or `search`' and 'Call this to see all of a chosen hotel's rooms, or to refresh availability before checkout' provides clear context on when to use. It doesn't explicitly state when not to use, but the scenario is well-defined.

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

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

Annotations already indicate readOnlyHint=true. The description adds that it lists the signed-in user's bookings, which is consistent but does not disclose pagination behavior beyond 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?

One sentence, no waste, front-loaded with key information. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with two pagination parameters and no output schema, the description is sufficient. No additional behavioral context needed.

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% with descriptions for page and limit. Description does not add beyond schema, so baseline of 3 is 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?

Description specifies verb 'list', resource 'hotel bookings', and scope 'signed-in user', clearly distinguishing from siblings like 'get_my_booking' (singular) or 'search_hotels' (global search).

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

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

No explicit guidance on when to use this tool vs alternatives. While self-explanatory, it does not mention that for a single booking, 'get_my_booking' should be used.

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

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

Annotations already mark it as read-only. Description adds the output fields but does not disclose any additional behavioral traits like caching, ordering, or limits beyond the annotation.

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?

Extremely concise: one sentence for action and one brief usage instruction. No unnecessary words, front-loaded with purpose.

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?

Given no output schema, the description adequately covers return fields and linkage to another tool. Minor omission: no mention of ordering or potential empty results.

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?

No parameters, so baseline is 4. Description adds value by explaining return fields (brand, last 4, expiry, default) and how to use the publicId, going beyond the empty schema.

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

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

Clearly states the tool lists the signed-in user's saved payment cards with specific fields (brand, last 4, expiry, default). Distinguishes from sibling tools that handle bookings or creation.

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?

Provides a post-usage hint about using the returned publicId with create_one_click_checkout, but lacks explicit guidance on when to use this tool over alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds that it lists the signed-in user's trips but does not disclose any further behavioral traits like pagination or ordering. The added value is minimal.

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 a single, concise sentence with no unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with no parameters and no output schema, the description is mostly complete. It explains what is listed and for whom, though it could clarify what constitutes a 'saved trip'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters and schema coverage is 100%. The description clarifies the scope and ownership ('signed-in user's saved trips'), which adds meaning beyond the empty schema.

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

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

The description clearly states the verb 'List' and the resource 'signed-in user's saved trips (itineraries)', which distinguishes it from siblings like 'search' and 'list_my_bookings'. However, it does not explicitly differentiate from 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?

No guidance is provided on when to use this tool versus alternatives like 'search' or 'list_my_bookings'. There are no usage conditions or exclusions mentioned.

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

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

Beyond annotations (destructiveHint=true), description adds critical details: special requests always apply, date changes trigger cancel-and-rebook, price/confirmation may change, and supplierModifyStatus indicates actual outcome. No contradiction with annotations.

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?

Concise yet thorough. Front-loaded with main action, each sentence adds necessary detail. No fluff. Well-structured for the complexity of the tool.

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 date change behavior, special requests, verification code, supplierModifyStatus, and error scenarios. No output schema but description compensates by mentioning result fields. Complete for an agent to use 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% but description adds meaning: verificationCode requirement, date change behavior, and special-request applicability. Baseline 3 is raised due to added context beyond schema descriptions.

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

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

Clearly states the tool modifies a signed-in user's booking, with a specific verb ('Change') and resource ('one of the signed-in user's bookings'). Distinguishes from sibling cancel_booking by focusing on modification.

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 requires verificationCode from request_booking_action_code. Provides when-to-use and when-not-to (date change on unsupported suppliers returns error). Advises not to promise date change unless supplierModifyStatus is modified or simulated. Offers clear alternatives (cancel and rebook).

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

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

Annotations declare idempotentHint=true and destructiveHint=false. The description adds behavioral context: it sends an email and is a prerequisite step. It does not contradict annotations.

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, concise and front-loaded with the core action. 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?

Given no output schema, the description lacks information about the response format or error conditions. However, for a tool that is part of a two-step process, the essential context is provided.

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% with descriptions for both parameters. The description adds value by linking the 'action' parameter to the subsequent tool calls, but doesn't elaborate on parameter details beyond schema.

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

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

The description clearly states it emails a verification code required before cancelling or modifying a booking. It distinguishes itself from sibling tools by explicitly naming cancel_booking and modify_booking as next steps.

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 description provides explicit usage guidance: use this tool as step 1 of 2 when you need to cancel or modify a booking, then call cancel_booking or modify_booking with the code. No when-not-to guidance needed.

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

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

Description adds the context that trips are associated with the signed-in user (scope). Annotations confirm mutability (readOnlyHint=false). No disclosure of side effects, required permissions, or error behavior. Adequate but not rich.

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?

Single sentence, no redundancy, front-loaded with core purpose. Every word 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?

Tool has 6 parameters (3 required) and no output schema. Description lacks information on return values, success/failure indicators, or constraints beyond user scope. Adequate for a simple create operation but leaves agents guessing on response format.

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?

All 6 parameters have full schema descriptions (100% coverage), so the description adds no additional meaning beyond what the schema already provides. Baseline score of 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?

Description uses specific verb 'Create' with resource 'saved trip (itinerary)' and scope 'for the signed-in user'. Clearly distinguishes from sibling tools like list_trips, add_trip_item, and 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?

No guidance on when to use this tool vs alternatives like add_trip_item or modify_booking. No prerequisites, exclusions, or context signals provided.

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

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

Annotations already indicate readOnlyHint and openWorldHint. Description adds that it returns a list of IDs for fetch, but no further behavioral traits like pagination or rate limits. No contradiction with annotations.

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 clear sentences plus a brief usage hint. Efficient and front-loaded, though could be more structured with bullet points.

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?

Given 10 parameters and no output schema, the description covers basic purpose and workflow but lacks details on pagination, error handling, or return format beyond mentioning IDs.

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. Description adds minimal extra meaning beyond schema, mainly clarifying the role of the query parameter for natural-language input.

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?

Clearly states it searches for hotels and returns IDs for use with fetch. However, it does not differentiate from the similarly named sibling 'search_hotels', so it's not fully distinguishing.

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?

Suggests providing destination and travel dates in the query, and mentions the fetch workflow. Lacks explicit when-to-use vs alternatives or exclusions.

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

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

Descriptions states it returns a price-sorted list with ref and supplierRoomId. Annotations declare readOnlyHint and openWorldHint; description adds context about live data and JSON format. No contradictions.

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?

Concise paragraph front-loaded with core purpose, then explains booking workflow and sibling tools. No redundant 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?

Explains return value structure and usage flow. Lacks details on pagination or limits, but for a read-only search tool with annotations covering safety, this is adequate.

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 covers all 9 parameters with descriptions. The description adds value for keywords (narrowing with hotel name/area/amenities). Other parameters like guestNationality are sufficiently described in schema.

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

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

Clearly states it searches live hotel availability for a destination and date range. Distinguishes from siblings like get_rooms (for other rooms) and get_checkout_quote (for 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?

Explicitly says when to use (search) and when to use alternatives: get_rooms for other rooms, get_checkout_quote then create_checkout for booking. Also mentions narrowing with keywords.

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