gondola

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

Annotations already indicate readOnlyHint=false and destructiveHint=true. Description adds useful behavioral context like override rules and loyalty credit details, but doesn't explicitly mention irreversibility 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?

Well-organized into paragraphs with clear front-loading of purpose and prerequisites. Slightly verbose 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 necessary aspects: prerequisites, parameter derivation, interaction with multiple other tools, override logic, and output schema present. Highly complete for a complex booking 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 thoroughly explains each parameter's source, optionality, and interrelations (e.g., loyalty_account_id overrides email).

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 'Book' and resource 'hotel room', and specifies it uses a rate from get_hotel_details, distinguishing it from siblings like 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 explicit prerequisites (Gondola account, API key, saved payment method), directs to get_payment_methods and get_hotel_details for inputs, and explains the travel profile and loyalty account interactions.

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 already indicate read-only and non-destructive behavior. The description adds value by detailing return format (comparison table with CPP valuation, value signals, recommendations) 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 with a clear intro, usage context, parameter details, and return summary. Every sentence earns its place 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 the tool's moderate complexity, annotations, and output schema, the description fully covers purpose, usage, parameters, and return. No gaps remain.

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?

Despite 0% schema coverage, the description explains each parameter: hotel_ids list with max 5 and source, date formats, and default for num_adults. This compensates for the 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?

The description clearly states the tool compares cash vs points rates across multiple hotels side-by-side, using a specific verb and resource. It distinguishes from siblings like search_hotels or diagnose_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?

It explicitly states to use after search_hotels to help decide between top hotel picks, providing clear context and when-not-to-use 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 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 indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context by stating it shows per-supplier status and a full breakdown by rate type, which goes beyond the annotations without contradicting them.

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 succinct—two sentences in the first paragraph and a clear bullet-style Args list. Every sentence adds value and avoids repetition or fluff.

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 5 parameters (3 required), an output schema, and clear purpose, the description covers all necessary information. It explains the tool's use case and all parameters adequately, leaving 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?

Schema description coverage is 0%, but the description compensates thoroughly by explaining each parameter: hotel_id as Vervotech property ID, checkin/checkout date format, num_adults default of 2, and rate_sources as optional comma-separated sources. This 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 the tool's purpose: diagnosing rate availability and source statuses for a hotel. It explains it is used to investigate why rates are or aren't showing, which distinguishes it from sibling tools like compare_rates and get_multi_night_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 explicitly says 'Use this to investigate why certain rates... are or aren't showing,' providing clear context for when to use the tool. It does not list exclusions or alternatives, but the purpose is sufficiently distinct from 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 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 indicate readOnlyHint=true and destructiveHint=false, and the description adds complementary behavioral details: two paths, deep-linking with gondola_rate_id, handling anonymous users, and card eligibility. 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-structured with sections, bullet points, and a clear args list. Every sentence adds value, no fluff. Front-loaded with purpose and usage, making it easy to scan.

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 an output schema exists, the description need not detail return values, but still mentions tailored instructions. Tool fits into workflow after search/get_details and before book_hotel. Completeness is high.

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?

Despite 0% schema description coverage, the description's 'Args' section fully explains each parameter: hotel_id as Vervotech ID, checkin/checkout format, children_ages as comma-separated, gondola_rate_id for deep-linking. Adds significant meaning 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 'Get booking options for a hotel' and elaborates on two booking paths, distinguishing it from siblings like 'book_hotel'. It specifies when to use and what the tool returns, making 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?

Explicitly states 'Use this after search_hotels or get_hotel_details when a user wants to book.' Provides conditions for each booking path and differentiates from the actual booking tool 'book_hotel', offering clear usage 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 already declare readOnlyHint=true and destructiveHint=false. The description adds that it 'Returns room options with pricing, cancellation policies, and amenities,' which provides useful behavioral detail beyond the annotations. No contradictions observed.

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 a clear structure: purpose sentence, usage guide, parameter list, and return summary. The Returns section is slightly redundant with the first sentence, but overall it's efficient and well-organized.

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 that the tool has an output schema, the description appropriately outlines return content. All parameters are documented, and the relationship to search_hotels is clarified. The description is complete for the tool's 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?

The description includes a full Args section that explains each parameter: hotel_id is 'the hotel's Vervotech property ID (returned by search_hotels),' checkin/checkout format, and num_adults default. Since schema coverage is 0%, this completely compensates and adds significant 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?

The description clearly states 'Get detailed information, room types, and rates for a specific hotel.' It uses a specific verb (Get) and resource (hotel details). It also distinguishes from siblings like search_hotels by saying 'Use this after search_hotels,' making the 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 explicitly advises 'Use this after search_hotels to get full details for a hotel the user is interested in,' which provides a clear usage context. While it doesn't explicitly exclude other scenarios, the context is strong and implies alternatives like book_hotel for booking. Lacks explicit when-not-to-use but still informative.

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. Description adds that it returns up to 10 recent reviews with ratings and comments, and that the result is a formatted list, 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?

Five sentences, no wasted words. Purpose first, then use case, then return details, then parameter. Well-structured and 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?

With one parameter, annotations, and output schema (not visible but referenced), the description sufficiently explains the tool's behavior and inputs. No gaps identified.

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 only shows hotel_id as integer. Description adds meaning: 'The hotel's Vervotech property ID (from search results).' This tells the agent where to get the ID, which is crucial for use.

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 verb+resource: 'Get guest reviews for a specific hotel.' It distinguishes from sibling tools like get_hotel_details or get_hotel_stats by specifying the resource is reviews.

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

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

States a clear use case: 'help users understand what other guests thought about a hotel.' Specifies returns up to 10 recent reviews, providing context. No explicit when-not or alternatives, but the purpose is narrow enough.

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, indicating a safe read operation. The description adds value by specifying that it shows historical comparison across the chain and yields percentile rankings, which is 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?

The description is relatively concise with a clear front-loaded purpose sentence. The 'Args:' and 'Returns:' sections are structured but could be slightly more streamlined. Every sentence contributes, with minimal 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 presence of an output schema, the description adequately explains return values as pricing stats with percentile rankings. The annotations cover safety, making the description sufficient for an agent to understand the tool's behavior and outputs.

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 explains the meaning of hotel_id (Vervotech property ID) and indicates that nightly_points_cost is optional. For 4 parameters, this adds some but not extensive meaning; more detail on currency format would improve.

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 'Get' and clearly identifies the resource as 'pricing analytics and percentile data for a hotel rate'. It distinguishes from sibling tools like 'compare_rates' and 'diagnose_rates' by focusing on historical comparison for a single rate.

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 'Use this to help users understand if a rate is a good deal,' providing clear context for when to invoke it. However, it does not explicitly state when not to use it or name alternative tools, though the sibling list suggests differentiation.

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, so the description does not need to restate safety. The description adds that it shows cash rates, points rates, and value percentiles, which provides additional 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?

The description is concise, with about six sentences covering purpose, usage, arguments, and returns. Every sentence adds value, and the structure is logical 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?

Given the presence of annotations (readOnlyHint, openWorldHint) and an output schema, the description adequately covers what the tool does, when to use it, parameters, and return value. It is complete for the tool's 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?

The input schema has no descriptions in its properties (0% coverage). However, the description's Args section explains each parameter ('hotel_id: The hotel's Vervotech property ID', 'start_date: ... YYYY-MM-DD format', etc.), adding significant meaning beyond the schema's titles and 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 'Get a rate calendar showing prices across a date range for a hotel.' It identifies the specific verb and resource, and distinguishes itself from sibling tools like compare_rates by focusing on multi-night rates with flexible dates.

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 when a user has flexible dates and wants to find the cheapest time to stay.' This provides clear context for when to use the tool, though it does not explicitly mention when not to use it or list 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?

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, so the safety profile is covered. The description adds that the tool returns 'List of similar hotels with rates and ratings,' which is useful but does not disclose other behavioral traits like pagination, rate limits, or authentication needs. With annotations carrying the primary burden, this is adequate but not exceptional.

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 a clear structure: one-line purpose, usage guideline, bulleted argument list, and return value statement. Every sentence adds value. It could be slightly more compact by merging the purpose and usage, but it is already 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?

With 4 parameters and an output schema present, the description covers all parameter details and explains the return type. It also provides essential context like the source of hotel_id ('from search results'). The only minor gap is a lack of mention of edge cases or error conditions, but overall it is sufficiently 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 description coverage is 0%, so the description must compensate for the missing parameter descriptions. It fully documents each parameter: hotel_id is described as 'Vervotech property ID (from search results),' checkin/checkout as 'YYYY-MM-DD format,' and num_adults as 'number of adult guests (default: 2).' This adds significant meaning beyond the raw schema property 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: 'Find hotels similar to one the user is looking at.' This specifies the verb ('find'), resource ('hotels similar'), and distinguishes it from sibling tools like search_hotels (which performs a search) and compare_rates (which compares rates). The usage hint 'Use this when a user wants alternatives, comparisons...' further clarifies its role.

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 when a user wants alternatives, comparisons, or asks "show me hotels like this one."' This provides clear guidance on when to invoke the tool. However, it does not explicitly state when not to use it or list alternative tools for exclusion, which would earn a 5.

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 indicate readOnlyHint=true and destructiveHint=false. The description adds that it returns formatted context or instructions to build one, and requires an API key. No contradictions; description enhances transparency 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?

Description is succinct: purpose in first sentence, then return content, usage guidance, and requirement. Every sentence 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?

Given no parameters and existence of an output schema, the description fully covers what an agent needs: what the tool returns, when to call it, and prerequisites. It is sufficiently complete for correct invocation.

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

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

The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter details. Baseline for 0 params is 4, and description is adequate.

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 the user's saved travel context to personalize recommendations. It lists specific data returned (loyalty programs, home airport, preferences, etc.), distinguishing it from sibling tools that deal with specific bookings or searches.

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 call once at the start of a travel session and weigh across hotel/flight/car recommendations. Also notes requirement of a Gondola account (API key), providing precise when-to-use 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 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, openWorldHint=true, and destructiveHint=false. The description adds behavioral context by listing the types of details returned (extras, charges, policies), which aligns with the read-only nature. 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 with a clear structure: purpose statement, usage recommendation, argument list with examples, return summary. Every sentence adds value. It could be slightly more structured by using bullet points for arguments, but it's 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 has an output schema (not shown), the description appropriately omits detailed return structure. It mentions key return categories (extras, charges, policies). For a simple lookup with three required parameters from search results, the description provides sufficient context for an AI agent to use 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% parameter description coverage (no descriptions in JSON schema). The description only says each parameter comes from search results, giving one example for vendor_code. It lacks detailed semantics such as format, length, or allowed values, which is insufficient to compensate for the 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?

The description clearly states the tool retrieves detailed information about a specific rental vehicle option, including extras, insurance, charges, and cancellation policy. It uses a specific verb ('Get') and resource ('rental vehicle option'), distinguishing it from siblings like search_vehicles (which lists options) and get_vehicle_booking (which handles 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?

The description explicitly recommends using this tool after search_vehicles and explains that the parameters come from search results. It provides an example for vendor_code. While it doesn't explicitly state when not to use this tool, the purpose is clear and no sibling tool directly competes for this specific task.

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 read-only and nondestructive behavior. The description adds valuable context: results are ranked by traveler loyalty and history, paginated at 10 per page, and 'book' mode is restricted. 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 well-structured: a summary sentence, followed by a behavioral note, then a clear parameter list, and a returns section. Every sentence is informative and concise 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 the tool's complexity (8 parameters, output schema exists), the description covers all essential aspects: parameters, ranking, pagination, cash pricing, and mode restrictions. It is sufficiently complete for correct invocation.

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

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

With 0% schema description coverage, the description fully explains all 8 parameters, including examples, defaults, enum options, and usage notes. This adds comprehensive 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 states the tool searches for flights by route and date, returning cash-priced options. It uses specific verbs and resources, distinguishing it 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 implies usage for browsing flights and cautions against using 'book' mode unless explicitly requested. However, it does not explicitly compare to alternative tools or provide when-not-to-use guidance, missing clear differentiation from sibling search 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?

The description adds substantial behavioral details beyond annotations, including how chain_name returns unfiltered results on no match, how loyalty_programs personalize earnings, and how limit notes remaining results. No contradictions with readOnlyHint/openWorldHint.

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 clear sections (Args, Returns), uses bullet points effectively, and every sentence adds value without redundancy. It is informative yet not overly verbose.

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 complexity (8 parameters, 3 required) and the existence of an output schema, the description covers all necessary aspects: input semantics, edge cases, and return value summary. It is fully complete for an AI 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 0% schema description coverage, the description compensates fully by explaining all 8 parameters: location with examples, date formats, default for num_adults, chain_name behavior, loyalty parameters, and limit guidance. Each parameter gets meaningful 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?

The description clearly states it searches for hotels by location and dates, specifically comparing cash and points pricing. It explicitly distinguishes itself from alternatives by claiming 'no other travel search shows both cash and points rates together.'

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 good context for when to use the tool (hotel search with cash/points valuation) and offers parameter guidance (e.g., raising limit only when explicitly requested). However, it does not explicitly contrast with sibling tools like compare_rates or get_hotel_details.

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, openWorldHint=true, and destructiveHint=false, which cover safety. The description adds minimal behavioral context—just that it returns a list. It does not mention rate limits, pagination, or dynamic result 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?

The description is organized with Args and Returns sections, making it easy to parse. It includes examples but could be slightly more concise (e.g., removing 'e.g.' 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?

With an output schema present (indicated true), the description appropriately summarizes return value as a list with rates and details. It covers all required parameters with examples, but lacks explanation for non-airport city searches.

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 provides essential meaning: pickup_location examples (IATA codes), date format examples, and vehicle_class options. This compensates well, though date format could be stricter.

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 rental vehicles at an airport or city.' It specifies the action (search), resource (rental vehicles), and context (airport/city). This distinguishes it from sibling tools like book_vehicle or 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 provides examples and valid inputs but does not explicitly state when to use this tool vs. alternatives (e.g., get_vehicle_booking for existing bookings). No exclusions or alternative suggestions are given.

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