gondola

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

The description discloses key behaviors beyond annotations: requires API key and saved payment, details parameter interactions (override behavior with travel_profile_id, loyalty_account_id overriding email). No contradiction with annotations (destructiveHint=true is consistent with booking). Adds value 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?

Well-structured: starts with clear one-liner, then prerequisites, then parameter details. Though lengthy (multiple paragraphs), every sentence adds value. Could be slightly more concise for parameter explanations, but appropriate for complexity.

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 9 parameters (mostly optional), existing output schema, and sibling tools, the description covers how to obtain necessary IDs, parameter interplay, and error handling. It provides sufficient context for an agent to correctly invoke the tool without external references.

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?

With 0% schema coverage, the description fully explains parameters: gondola_rate_id from get_hotel_details, payment_id from get_payment_methods, guest details optionality, travel_profile_id prefilling, loyalty_account_id for points. Provides relational context and edge cases, adding significant meaning beyond the bare 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 'Book a hotel room using a rate from get_hotel_details.' It specifies the verb 'book' and the resource 'hotel room', and distinguishes from sibling tools like book_vehicle by focusing on hotel booking with a specific rate source.

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 prerequisites (Gondola account, saved payment method) and explains when to use this tool (when you have a rate from get_hotel_details). It also offers alternatives like using travel_profile_id to prefill details. Minor omission: no explicit 'do not use if' guidance.

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 set destructiveHint=true, confirmed by description. Adds context about required account and payment method. 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?

Well-organized with prerequisites, argument list in bullet style, and return description. Could be slightly more concise but every sentence adds value.

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 all parameters, return value, and dependencies. Output schema exists, so return details are fine. Could mention error scenarios but adequate for high complexity.

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 11 parameters explained with examples and source guidance (e.g., 'from search results'). Compensates for 0% schema description coverage.

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 'Book a rental vehicle from a search result.' Differentiates from sibling tools like book_hotel and references search_vehicles. Specific verb+resource.

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 mentions prerequisites (Gondola account, payment method) and suggests using get_payment_methods. No explicit when-not-to-use or alternatives, but context is clear.

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 provide destructiveHint=true and readOnlyHint=false. The description adds minimal behavioral context beyond clarifying the booking ID type. Does not disclose potential side effects like fees or cancellation policies.

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?

Very concise: one sentence plus structured Args/Returns. Every word adds value, no 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?

Adequate for a simple cancellation with one parameter and an output schema, but lacks broader context like cancellation policies, prerequisites, or next steps. Sibling tools are available but no guidance on sequencing.

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%, but the description explains the sole parameter 'booking_id' as 'The Gondola booking ID (confirmation number)', which adds significant meaning beyond the schema's generic title '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 clearly states 'Cancel an existing vehicle booking,' which is a specific verb-resource pair. It distinguishes from sibling tools like book_vehicle (create) and get_vehicle_booking (retrieve).

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 versus alternatives, such as checking the booking status with get_vehicle_booking first or conditions like cancellation deadlines. Lacks example contexts 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?

Annotations show readOnlyHint=true and destructiveHint=false. Description adds value by detailing the output (comparison table with cash rate, points rate, CPP, deal scores) and highlighting best deals. No contradictions, and provides 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?

Concise with a clear summary sentence, usage context, and parameter descriptions. No unnecessary fluff; each sentence is valuable.

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 complexity, schema coverage, and presence of output schema, description is complete. It covers purpose, usage, parameters, and return value details. Differentiates well from 30+ siblings.

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%, so description compensates fully. Explains hotel_ids as 'List of hotel IDs to compare (max 5). Get these from search_hotels results.' Checkin and checkout are described with format YYYY-MM-DD, and num_adults with default. Adds meaning for all 4 parameters.

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 'compare' and the resource 'cash vs points rates across multiple hotels side-by-side', and distinguishes it from siblings like 'search_hotels' by specifying it is used after that step to decide between top picks.

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 states 'Use this after search_hotels' and notes that hotel_ids come from search_hotels results with a max of 5. Provides clear context, but does not include explicit when-not or alternative tools.

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=false and openWorldHint=true. The description adds that the tool sends email notifications and requires an API key, which is valuable behavioral context beyond the annotations. 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?

The description is concise at approximately 70 words, front-loaded with the main purpose, and includes an Args section that efficiently adds parameter details without verbosity. Every sentence adds value.

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 moderate complexity (3 parameters, 1 required, output schema exists), the description covers prerequisites, parameter constraints, and return value (confirmation with notification details). It is complete enough 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 description coverage is 0%, but the description provides detailed parameter semantics: hotel_id is a Vervotech property ID, checkin and checkout must be in YYYY-MM-DD and must be provided together or both omitted. This adds significant meaning beyond the schema's type and title.

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 rate alert to monitor a specific hotel for price drops. It specifies the verb 'create' and the resource 'rate alert', and distinguishes from siblings like delete_rate_alert and get_rate_alerts.

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 clear usage context: set up an alert for price drops, optionally with dates, and requires a Gondola account. It does not explicitly exclude when not to use it, but the guidance is sufficient for typical use cases.

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 and destructiveHint=false. The description adds that the tool returns coverage type, max days, and a summary. No contradictions. Lacks mention of potential delays or data limitations, but sufficient.

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 with clear structure. Purpose stated first, then usage instructions in bullet-like format, then return info. Every sentence is necessary and adds value.

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 tool's complexity (3 optional params with dependencies) and the presence of an output schema (not shown), the description is complete. It explains parameter dependencies, return values, and stops short of duplicating schema 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 has 0% description coverage, so the description carries full burden. It fully explains each parameter: credit_card_product_name is exact and preferred; card_number_bin is first 6-8 digits; card_provider is required with bin and lists accepted values. Provides complete semantic meaning.

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 the resource 'rental car CDW/LDW coverage provided by a credit card'. It distinguishes from sibling tools like get_vehicle_booking_coverage by focusing on credit card details.

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 tells the agent to provide either credit_card_product_name or card_number_bin+card_provider, with a preferred method. Lacks explicit exclusions or alternatives, but the guidance is clear for parameter selection.

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, so the description's 'Delete' is consistent. It adds that the function returns a confirmation, but does not disclose any other behavioral traits beyond what annotations provide.

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 concise with clear sections (purpose, requirements, args, returns). Every sentence adds value. Could be slightly more streamlined but overall 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 delete action with destructiveHint and an output schema (presumably confirmation), the description provides the necessary information. However, it lacks details on error handling or idempotency.

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?

With 0% schema description coverage, the description compensates by explaining the alert_id parameter: 'The rate alert ID to delete (from get_rate_alerts).' This adds value by indicating the source of the 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?

Description explicitly states 'Delete a rate alert so you stop monitoring a hotel for price drops.' Verb and resource are clear, and the purpose differentiates it from siblings like create_rate_alert or get_rate_alerts.

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?

Specifies prerequisite ('Requires a Gondola account with an API key') but does not provide explicit guidance on when to use or alternatives. Usage is implied by the name and purpose but lacks comparison to other tools.

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 and destructiveHint=false, so the tool is clearly safe. The description adds moderate behavioral context: it shows per-supplier status and a full breakdown. It does not discuss rate limits, permissions, or any side effects beyond what annotations imply.

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 concise and well-structured. The opening sentence states the core purpose, followed by a use case paragraph, then a clean bullet list of Args. No unnecessary words or repetition.

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 adequately covers parameters and usage context. It mentions that the output includes a 'full breakdown of every rate by type,' which is sufficient given that an output schema exists (not shown but noted). It could add prerequisites (e.g., hotel_id from another tool) but is complete for a diagnostic tool with 5 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%, but the description fully compensates by explaining each parameter: `hotel_id` as Vervotech property ID, `checkin`/`checkout` with date format, `num_adults` default 2, and `rate_sources` as optional comma-separated sources. This adds significant meaning beyond the raw 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 specifies the tool's purpose: diagnosing rate availability and source statuses for a specific hotel. It uses action verbs like 'diagnose' and 'investigate', and distinguishes from sibling tools like 'compare_rates' by focusing on per-supplier status and rate breakdown.

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 explicitly states when to use the tool ('to investigate why certain rates are or aren't showing') and provides context about the optional `rate_sources` parameter. It implies usage for diagnostic purposes but does not explicitly mention when not to use it or contrast with alternatives like 'compare_rates'.

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 description's 'Get details' aligns. It adds that the response includes hotel, dates, room, rate, and status, but lacks deeper behavioral context like required permissions or error handling.

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 concise with two sentences plus structured Args/Returns sections. Every element is purposeful and efficiently conveys the tool's use.

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 covers purpose, parameter, and output. It does not mention error cases or differentiate from get_booking_link, but for a simple read tool with annotations and output schema, it is mostly 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?

With 0% schema description coverage, the description adds meaning by specifying 'booking_id' as 'The booking ID or confirmation number.' This clarifies what the parameter accepts, though format details are missing.

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 retrieves details for a specific hotel booking, distinguishing it from sibling tools like get_vehicle_booking. The Returns section further clarifies the scope.

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 like get_hotel_details or get_booking_link. Usage is implied by the name, but with many siblings, explicit context would help.

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 behavioral details about presenting two booking paths and handling anonymous users with a sign-up prompt, beyond what annotations provide. 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?

Well-organized with bullet points and sections. Slightly lengthy but all sentences add value. Front-loaded with purpose and usage context.

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 tool has 5 parameters and conditional behavior based on auth status, the description covers all essential aspects: purpose, when to use, parameter details, return type, and edge cases for anonymous users. The presence of an output schema further complements the information.

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%, but the description fully explains each parameter in the Args section, including source for hotel_id and format requirements for dates and children_ages.

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 'Get booking options for a hotel' and explains the two booking paths. It differentiates from siblings like 'book_hotel' by emphasizing this tool presents options rather than executing the 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 states 'Use this after search_hotels or get_hotel_details when a user wants to book.' Provides context on when each path is shown (anonymous vs. card-eligible), but does not explicitly list when not to use it or compare with other booking-related siblings.

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 provide readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by disclosing the specific return content: room options, pricing, cancellation policies, and amenities. It does not contradict the annotations and provides behavioral context beyond what is in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a brief main sentence, usage guidance, returns description, and an Args list. It is reasonably concise—every sentence adds value. The inclusion of a 'Returns' section might be slightly redundant given the output schema exists, but it still aids clarity. 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 the tool's complexity (4 parameters, integration with search_hotels), the description is complete. It specifies the input format, default values, and the nature of the output (room options, rates, policies, amenities). The context of being used after search_hotels is clear, and it fits well among the 30+ sibling tools. The output schema likely provides further structure, but the description sets proper expectations.

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. It does so by providing detailed explanations for each parameter: hotel_id ('Vervotech property ID returned by search_hotels'), checkin and checkout ('YYYY-MM-DD format'), and num_adults ('Number of adult guests. Defaults to 2'). This adds significant meaning beyond the bare schema property titles.

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 'Get detailed information, room types, and rates for a specific hotel.' This clearly identifies the verb (Get), resource (hotel details), and distinguishes it from siblings like search_hotels (initial search) and book_hotel (booking). It also specifies that it returns room types, rates, cancellation policies, and amenities, making the purpose very specific.

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 explicitly says 'Use this after search_hotels to get full details for a hotel the user is interested in.' This gives clear context for when to use it and implies it is for gathering details, not for booking or other actions. Although it does not explicitly state when not to use it or name alternatives, the positioning relative to search_hotels is strong.

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 readOnlyHint=true and destructiveHint=false, so the description adds value by stating it returns 'up to 10 recent reviews' and listing the fields (author names, ratings, review text), which are not in 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 brief with three sentences plus parameter/return definitions, no redundancies, and the main purpose is front-loaded.

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 tool is simple with one parameter and read-only behavior. The description covers purpose, parameter source, and return structure, making it complete for the agent to use.

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 only parameter hotel_id has its description clarified: 'The hotel's Vervotech property ID (from search results).' Since schema description coverage is 0%, this explanation is essential and adds meaning.

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 'Get guest reviews for a specific hotel' and specifies it returns recent reviews with ratings and comments, which distinguishes it from sibling tools like get_hotel_details.

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 advises using the tool to 'help users understand what other guests thought about a hotel,' providing clear context for when to invoke it. However, it does not mention when not to use or alternatives.

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 no destructive actions. The description adds that it shows historical comparison across the chain, enhancing transparency without contradicting 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 concise and front-loaded with the core purpose. The docstring format (Args/Returns) is slightly verbose but well-organized, with no wasted 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?

Given the output schema exists (though not fully shown), the description covers input parameters and return value (percentile rankings and value assessment). For a stats tool, this is complete and well-integrated with the schema.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's role: hotel_id from search results, nightly_cash_cost, currency, and optional points_cost. This provides essential meaning beyond the schema's titles.

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 retrieves pricing analytics and percentile data for a hotel rate, distinguishing it from sibling tools like get_hotel_details (general info) or compare_rates (multi-hotel comparison). The verb 'Get' and resource 'hotel stats' are specific.

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 explicitly instructs to use it to help users understand if a rate is a good deal, providing clear usage context. It does not specify when not to use it or mention alternatives, but the purpose 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 mark the tool as read-only, but the description adds value by disclosing the return structure (points balance, tier status, estimated cash value, recent changes, expiration dates) and the requirement for an API key. It also hints at the return format (formatted list vs instructions to connect), which goes 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?

The description is brief (three sentences) and front-loaded with the primary purpose. Every sentence provides relevant information without redundancy or unnecessary detail, making it easy to parse.

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 read-only tool with no parameters and an output schema present, the description covers purpose, prerequisites, return contents, and return format. It is complete enough 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?

With zero parameters and trivially 100% schema coverage, the description does not need to add parameter details. According to guidelines, baseline for 0 parameters is 4, and the description adequately covers the lack of arguments.

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 specifies 'Get the user's hotel and airline loyalty accounts with points balances and values,' which is a specific verb and resource. It distinguishes itself from sibling tools like 'optimize_loyalty_portfolio' (which modifies) and 'get_payment_methods' (which gets payment info) by focusing on loyalty accounts.

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 states a prerequisite ('Requires a Gondola account (API key)') but does not provide explicit guidance on when to use this tool versus alternatives like search or booking tools. No exclusions or when-not scenarios are mentioned, leaving the agent to infer usage context.

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 and destructiveHint=false. The description adds detail about the output (cash rates, points, value percentiles), which goes beyond the annotations. 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?

The description is compact (8 lines), front-loaded with purpose, and structured with Args/Returns. Every sentence adds value without 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?

For a read-only tool with 4 parameters and an output schema, the description explains the output (rate calendar with pricing) and covers all parameters. It is complete given the tool's simplicity.

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?

With 0% schema description coverage, the description provides format for dates (YYYY-MM-DD), source for hotel_id (Vervotech ID from search results), and default for nights. This adds significant meaning but could be more explicit about valid ranges.

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 retrieves a rate calendar for a hotel across a date range, specifically for flexible date searches. It distinguishes itself from siblings like compare_rates or get_hotel_details by targeting multi-night pricing and value percentiles.

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 usage context is given: 'Use this when a user has flexible dates and wants to find the cheapest time to stay.' While it does not list sibling alternatives or when-not-to-use, the context is clear enough to guide the agent.

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 (readOnlyHint=true), the description discloses that it returns dates, confirmation numbers, costs, loyalty earnings, and notes the response indicates remaining items. It also states the requirement for a Gondola account. This adds useful context without contradicting 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 well-structured with a clear purpose statement, return summary, requirement note, and parameter documentation. It is front-loaded and concise, though the Args section slightly duplicates schema 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 the simple tool (one optional parameter, output schema exists), the description covers all essential aspects: purpose, return content, parameter usage, and prerequisites. It is complete 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?

The description provides extensive meaning for the limit parameter: ordering (most recent first), default value, and guidance on usage ('raise this only when the user wants their full history'). This fully compensates for the 0% schema description coverage.

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 'Get the user's past trips including hotel stays and flights,' providing a specific verb and resource. It clearly distinguishes from sibling tools like 'get_upcoming_trips' by focusing on past travel.

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 mentions when to adjust the limit ('raise this only when the user wants their full history') but does not explicitly compare with alternatives or state when not to use this tool. No exclusions or sibling comparisons are 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 declare readOnlyHint=true and destructiveHint=false, and description adds details about returned fields (brand, last 4 digits, expiration, payment ID, bookable status) and the fallback instruction to add a payment method.

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?

Four sentences that are each valuable: purpose, prerequisite, return details, and summary. 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 zero parameters and existence of an output schema, the description fully covers what the tool returns and its purpose.

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 no param info, but none is needed.

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?

Clear verb 'List' and resource 'saved payment methods'. Distinguishes itself from sibling tools like book_hotel and get_booking by focusing on payment methods.

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?

Mentions prerequisite (Gondola account) and links to book_hotel via payment ID, but does not explicitly state when to use this tool vs alternatives like get_loyalty_accounts.

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 destructiveHint=false. The description adds context about returning a list of active rate alerts with hotel names, dates, and current rates, which is useful beyond annotations. 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?

The description is brief and front-loaded, with three concise sentences and a clear 'Returns:' line. No extraneous 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?

The description covers purpose, return format, and authentication requirement. For a zero-parameter read-only tool with an output schema, it is largely complete, though it could mention pagination or sorting.

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

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

There are zero parameters, so the description does not need to explain them. With 100% schema coverage, baseline is 4.

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 'Get all active rate alerts for the current user', which is a specific verb and resource. It distinguishes from sibling tools like create_rate_alert and delete_rate_alert by focusing on retrieval.

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 mentions the prerequisite of a Gondola account with an API key, but does not provide guidance on when to use this tool versus 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 and destructiveHint=false. Description adds return info (list with rates and ratings) but no additional behavioral traits beyond what annotations cover.

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 purpose, followed by brief usage guidance, then structured Args and Returns sections. No fluff, 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 the simple tool with 4 parameters and existence of output schema, the description covers purpose, usage, parameter details, and return values adequately.

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% for parameter descriptions. The description explains hotel_id source, date format for checkin/checkout, and num_adults default, adding meaning beyond the schema for all four parameters.

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 'Find hotels similar to one the user is looking at' and provides an example usage query. It distinguishes this tool from siblings like 'search_hotels' and 'get_hotel_details'.

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 'Use this when a user wants alternatives, comparisons, or asks 'show me hotels like this one.'' Provides clear context and example usage, but lacks explicit 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by disclosing the tool uses user preferences, recent searches, popular destinations, and upcoming holidays. No contradictions 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 at 3 sentences plus a returns line. Could be slightly more structured, but every sentence adds value. The 'Returns:' line is somewhat redundant given the output schema.

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

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

Given no parameters, existing annotations, and an output schema, the description is complete. It covers what the tool does, when to use it, and the type of results, without needing additional explanation.

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 exist, so schema coverage is 100%. The description adds no parameter-level details, but that's acceptable since there are no parameters to explain. The tool's invocation requires no user input beyond context.

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 provides personalized travel suggestions and trip inspiration, specifically curated hotel recommendations. Distinguishes from sibling search tools by emphasizing it's for when the user doesn't know where to go.

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 'Great for when the user doesn't know where to go,' providing clear usage context. Implies that when the user has a specific destination, other tools like search_hotels should be used, but does not name alternatives explicitly.

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 read only and non-destructive. Description adds that it requires a Gondola account (API key) and describes return 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?

Efficient two-paragraph format: purpose, usage with example, auth requirement, return info. 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 zero parameters and an output schema, the description fully explains the tool's purpose, how to use result, and auth requirement. Sufficient 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?

No parameters exist, so schema coverage is 100%. Baseline 4; description does not need to add parameter info.

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 retrieves saved travel profiles (guest name, email, phone presets). It distinguishes from siblings like booking tools by focusing on profile retrieval.

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 explains when to use: pass Profile ID to book_hotel to prefill guest details. Also implies alternative of manual entry. Lacks explicit 'when not to use' but provides strong context.

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 and destructiveHint=false. The description adds detail on what the tool returns (dates, confirmation numbers, costs, loyalty earnings, savings opportunities) and that it may return instructions to connect an account. This provides 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?

Three sentences, each serving a purpose: first states the primary function, second details the output, third states a requirement. Front-loaded and efficient with 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?

With 0 parameters, annotations covering safety, and an output schema present, the description is complete. It explains the return value and prerequisite, leaving no ambiguity for a tool with this complexity.

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

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

There are 0 parameters, so the schema is fully covered (100%). The description explains the output meaningfully, compensating for the lack of parameters. Baseline for 0 params is 4.

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 starts with 'Get the user's upcoming trips including hotel stays, flights, and car rentals.' It clearly states the verb and resource, and distinguishes from siblings like get_past_trips and get_booking by focusing on upcoming reservations across multiple categories.

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 mentions 'Requires a Gondola account (API key),' but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. Usage is implied but lacks exclusions or comparisons.

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 and destructiveHint=false. The description adds that the tool returns booking details including vendor, pickup/dropoff, vehicle, rate, and status, which provides useful context beyond the annotations. 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?

Five lines with a front-loaded sentence stating the purpose, followed by concise parameter and return descriptions. No superfluous 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 the presence of an output schema (as per context signals), the description's mention of return fields is sufficient. The tool has low complexity (one required parameter), and the description covers the essential information for an agent to invoke it correctly.

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

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

The schema has 0% description coverage, but the description adds a clear explanation for the 'booking_id' parameter: 'The Gondola booking ID (confirmation number)'. This compensates for the missing schema descriptions and adds meaning.

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 'Get details for a specific vehicle booking', specifying the action (get details) and resource (vehicle booking). It effectively distinguishes from sibling tools like 'get_booking' (generic) and 'get_vehicle_booking_link' (retrieves a link).

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 provides clear context for when to use the tool: retrieving details of a specific vehicle booking. However, it lacks explicit when-not or alternative tool guidance, such as noting that 'get_booking' might be used for non-vehicle bookings.

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 destructiveHint=false, so the description adds only that it returns coverage details or an error message, which is minimal extra context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two well-structured sentences and a parameter description, 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 read tool with one parameter and an output schema, the description provides enough context about what it does and returns, though it could mention edge cases or error behavior.

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?

With 0% schema description coverage, the description adds valuable context by specifying that booking_id is a 'Gondola booking ID' and relates to the vehicle booking, compensating for the schema's lack of detail.

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 gets rental car CDW/LDW coverage for a specific vehicle booking, using a specific verb and resource that distinguishes it from sibling tools like get_vehicle_booking.

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

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

The description implies when to use (to retrieve coverage for a vehicle booking) but does not provide explicit when-not-to-use scenarios or alternatives like credit_card_coverage.

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; the description adds context about auth-dependent responses (instructions vs direct link). This goes beyond annotations but could detail auth requirements more.

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?

Well-structured with intro, args list, and returns. The args section largely duplicates schema field names, which adds slight redundancy. Still clear and front-loaded.

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 5 required params, output schema exists, and description covers purpose, parameter sources, and behavioral differences. Complete enough for a read-only link 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 has 0% description coverage, but the description compensates by explaining parameter sources (e.g., search_id from search_vehicles). This adds meaning beyond schema types.

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 gets a deep link for a vehicle from search results, distinguishing it from siblings like get_booking_link (for hotels). It also specifies behavior for authenticated vs anonymous users.

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 from search results but doesn't explicitly state when not to use or provide alternatives beyond mentioning book_vehicle as an in-conversation option. Guidance is present but not exhaustive.

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 and destructiveHint=false, so the safety profile is clear. The description adds value by stating the return contents (extras, charges, policies), but does not disclose any additional behavioral traits such as idempotency, rate limits, or side effects. With annotations covering safety, a score of 3 is appropriate as the description adds moderate but not excessive additional transparency.

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 concise: three sentences plus a parameter list, with no wasted words. It front-loads the purpose and then provides usage guidance. The parameter list is structured clearly. It loses a point because it could be slightly more structured (e.g., using bullet points), but it is still 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?

Given the tool's simplicity and the presence of an output schema (which reduces the need to explain return format), the description is complete. It explains what the tool does, when to use it, what parameters are needed, and what is returned. It does not explicitly mention that a search_id must come from a prior search, but that is implied. Annotations cover safety traits.

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 provide parameter meanings. It does so effectively: listing vendor_code (with examples like 'ZE' for Hertz, 'AL' for Alamo), rate_code, and search_id, all described as coming from search results. This adds significant meaning beyond the schema's bare parameter names.

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's purpose: 'Get detailed information about a specific rental vehicle option.' It uses a specific verb ('get') and resource ('vehicle details'), and distinguishes itself from siblings like 'get_vehicle_booking' by specifying it is used after 'search_vehicles' to get extras, insurance, charges, and cancellation policy.

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 explicitly says 'Use this after search_vehicles,' providing clear context for when to use the tool. It also lists what the tool returns (extras, insurance, charges, cancellation policy), helping the agent understand its value. However, it does not explicitly mention when not to use it or name alternative tools, though the sibling list indirectly provides that information.

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 reinforces non-destructive analysis. Adds behavioral context about factors considered (points, redemption rates) without contradicting 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?

Well-structured with purpose, usage guidance, and Args/Returns. Efficient but could be slightly more concise without losing clarity.

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 tool's complexity and presence of an output schema, the description covers return values and behavioral context adequately.

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 has no parameter descriptions (0% coverage), but the description compensates fully with clear explanations, examples, and default values for all 4 parameters.

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 optimizes loyalty portfolios for trips and analyzes hotel loyalty programs to recommend best value, distinguishing it from sibling tools which focus on booking or searching.

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 mentions when to use with example user queries ('Which loyalty program should I use?'), but does not specify when not to use, though alternatives are implied by sibling tools.

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 readOnlyHint=true and destructiveHint=false. Description adds that it uses historical price data and trends, and returns a recommendation with confidence. This provides useful behavioral context beyond the 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?

Well-structured: purpose, method, usage trigger, then parameter list. No unnecessary details, though could be slightly more 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?

Covers all 6 parameters (5 required) and mentions return values (recommendation, confidence, signals). Output schema exists to detail returns, so description is complete enough.

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%, but the description fully documents all parameters with meanings (e.g., hotel_id as Vervotech property ID, date formats, currency). This compensates entirely for missing 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?

Description clearly states it predicts whether to book now or wait, using historical price data. The verb 'predict' and resource 'booking timing' are specific. It distinguishes from siblings like compare_rates and book_hotel.

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 states when to call: when user asks 'Should I book now or wait?' or wants to know if a price is good. Does not mention exclusions, but context is clear.

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 destructiveHint=false, so the tool is safe. The description adds behavioral context: it returns a formatted list sorted by price, includes loyalty points, and explains optional parameters. No contradictions 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 well-structured with a clear main sentence, followed by a paragraph on features, then a bullet-pointed args section. Every sentence adds value, and it is appropriately sized without 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 6 parameters, 0% schema coverage, and a full description of each parameter plus a clear return value overview (formatted list with fields), the description is complete. Annotations and output schema further support understanding, making it sufficient for correct tool invocation.

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

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

Schema description coverage is 0%, so the description carries full burden. It includes an 'Args' section that explains all 6 parameters with examples, valid values for cabin_class, and defaults for num_passengers. This adds significant meaning beyond the schema's field titles.

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 searches for flights by route and dates with cash and points pricing. It specifies the resource (flights) and action (search), and is distinct from sibling tools like search_hotels or search_vehicles.

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 explains how to use the tool: it returns offers sorted by price, includes points costs, and specifies that return_date is optional for one-way searches. While it does not explicitly list when not to use it, the context is clear and no alternative flight search tool exists among siblings.

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 and destructiveHint=false, so the safety profile is clear. The description adds behavioral details: returns a formatted list with cash rates, points rates, CPP valuation, and deal recommendations. It also explains the chain_name filter fallback behavior, which is beyond what annotations provide.

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 well-structured: a concise intro sentence, a clear Args section with bullet-like format, and a short Returns sentence. It is front-loaded with the main purpose and every sentence adds value. 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?

Despite the tool's complexity (8 parameters, 31 siblings, output schema exists), the description covers all necessary aspects: purpose, parameters, return format, and usage guidance. It is complete for an AI agent to select and 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?

Schema description coverage is 0%, so the description fully compensates. It explains all 8 parameters with examples and edge cases (e.g., chain_name: 'case-insensitive substring match… if nothing matches, unfiltered results are returned with an explicit note'). The description adds significant 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?

The description clearly states 'Search for hotels by location and dates with cash AND points pricing,' specifying the verb (Search), resource (hotels), and unique value proposition. It distinguishes this tool from siblings like book_hotel, get_hotel_details, and compare_rates.

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 highlights the tool's unique advantage ('no other travel search shows both cash and points rates together'), implying when to use it. It also provides guidance on the limit parameter ('raise this only when the user explicitly wants a longer list'). While it doesn't explicitly list alternatives, it gives sufficient context for an AI agent to decide.

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?

Disclosures beyond annotations: specifies search location and datetime requirements, return type (list with rates/details). Annotations only indicate read-only and non-destructive; description adds significant behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Structured with Args and Returns sections. Every sentence is informative without redundancy. 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?

Given moderate complexity and presence of output schema, description covers all necessary aspects: purpose, parameters, and return value summary. No gaps.

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?

With 0% schema coverage, description compensates fully: explains each parameter with format and examples (e.g., IATA codes, ISO datetimes, optional vehicle_class enum). Adds meaning beyond plain schema titles.

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 rental vehicles at airports or cities, which distinguishes it from sibling tools like search_hotels or book_vehicle.

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 clear context for usage (searching rental vehicles) but does not explicitly state when not to use or mention alternatives. However, the sibling list implies differentiation.

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