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 describing the return format (comparison table with cash rate, points rate, CPP valuation, value signals) and the constraint of max 5 hotel_ids. This goes beyond what annotations provide, though it could mention rate limits or data freshness.

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: purpose, usage context, return value, then args list. It is not overly long, but the args list somewhat repeats information already in the schema. Could be slightly more concise, 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?

Given the tool has an output schema (not shown but stated), the description doesn't need to detail return values beyond mentioning the comparison table and highlights. All four parameters are explained, and the context of using after search_hotels is clear. 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, including the constraint that hotel_ids come from search_hotels and max 5, the date format YYYY-MM-DD, and the default for num_adults. 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 states it compares cash vs points rates across multiple hotels side-by-side. It specifically distinguishes from sibling tools like search_hotels (which searches for hotels) and get_hotel_details (which gets details for a single hotel), making the purpose precise and unique.

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 help a user decide between their top hotel picks,' providing clear context. However, it does not mention when not to use it or alternative tools like get_multi_night_rates for single hotel rates, which would have earned 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 indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description confirms by saying 'Create a rate alert' and adds details like email notification and optional date constraints, 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 with an introductory line, usage note, and parameter list. It is concise without being overly terse. Slight improvements could include shortening the prerequisites line, but overall effective.

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 (3 parameters, output schema exists), the description covers purpose, usage prerequisites, parameter details, and return value. No obvious gaps are present.

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

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

Schema coverage is 0%, but the description includes an exhaustive 'Args:' section explaining each parameter, constraints (e.g., checkin/checkout must be provided together), and the source of hotel_id. This compensates well for the lack of 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 creates a rate alert to monitor a hotel for price drops. It uses a specific verb ('create') and resource ('rate alert'), distinguishing it from related tools 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 explains when to use the tool (set up an alert for price drops) and mentions prerequisites (requires Gondola account with API key). It does not explicitly state when not to use it or compare to alternatives, but the context is clear 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. The description adds context about the two query modes and the return structure (coverage type, max days, summary). However, it does not disclose edge cases like what happens if no coverage is found or if the card is unrecognized. Since annotations carry the read-only signal, a slight gap remains.

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

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

The description is front-loaded with the purpose, followed by usage instructions and return values, in three short paragraphs. Every sentence serves a clear purpose 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?

The tool has an output schema (not shown but mentioned), so the description's brief return summary is acceptable. It covers the core functionality but could mention error handling or what happens with invalid inputs. Given low complexity, it is nearly 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?

The input schema has 0% description coverage for parameters. The description fully compensates by explaining each parameter's semantics: 'credit_card_product_name' is the exact product name, 'card_number_bin' is the first 6-8 digits, 'card_provider' is the network, and it clarifies the required combination. This adds essential 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's action: 'Look up rental car CDW/LDW coverage provided by a credit card.' It uses a specific verb ('look up') and resource (credit card coverage), which distinguishes it from sibling tools like search_vehicles or get_vehicle_booking_coverage.

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 tells when to use each parameter set: 'Provide EITHER credit_card_product_name OR card_number_bin + card_provider.' It also specifies the exact values for card_provider ('visa', 'mastercard', 'amex', or 'discover') and the BIN format ('First 6-8 digits'). This provides clear guidance for correct invocation.

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 destructive nature is known. The description adds that it requires authentication and returns a confirmation, but does not elaborate on side effects like irreversibility. With annotations covering the primary behavioral trait, the description adds moderate value.

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

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

The description is very concise: one sentence for purpose, one for requirement, then structured Args/Returns. Every sentence is meaningful and 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 simplicity (one parameter, no nested objects, output schema present), the description covers all necessary details: purpose, prerequisites, argument source, and return value. It is fully adequate for an agent to use the tool 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 only parameter, alert_id, has no description in the schema (0% coverage). The description adds value by specifying 'from get_rate_alerts', telling the agent how to obtain the ID. This goes beyond the schema's bare type information.

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

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

The description clearly states the action 'Delete' and the resource 'rate alert', and explains the purpose 'so you stop monitoring a hotel for price drops'. This effectively distinguishes it from sibling tools like create_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 specifies a prerequisite ('Requires a Gondola account with an API key'), which helps the agent determine if it can use the tool. However, no explicit guidance on when not to use or alternatives are provided, though the context of deletion is clear from the verb.

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 context about output (per-supplier status, rate breakdown) but does not disclose potential behavioral traits like data freshness, error handling, or rate limits. With annotations covering safety, a 3 is appropriate for lack of additional behavioral depth.

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 first sentence stating purpose followed by a structured Args section. Some redundancy exists (e.g., 'e.g.' examples), but overall it is 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 moderate complexity and an existing output schema (not shown), the description adequately explains inputs and output content. It lacks details about error scenarios or pagination, but the combination with annotations and output schema makes it sufficiently complete.

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

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

Schema description coverage is 0%, so the description must compensate. It fully describes each parameter: hotel_id (type), checkin/checkout (format), num_adults (default), and rate_sources (optional, with comma-separated examples). 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 states the tool's purpose: 'Diagnose rate availability and source statuses for a specific hotel.' It explains the use case ('investigate why certain rates are or aren't showing') and distinguishes from siblings like compare_rates or get_multi_night_rates by focusing on diagnostic breakdown per supplier.

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 implicitly guides usage by stating 'Use this to investigate why certain rates... are or aren't showing.' However, it does not explicitly mention when not to use or provide alternatives among siblings. The guidance is present but not comprehensive.

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. The description adds detail on return values (hotel, dates, room, rate, status), which is useful context beyond annotations. It does not disclose auth requirements or potential failures, but for a read-only retrieval tool, it is 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?

The description is concise with three sentences: a main line, an Args section, and a Returns section. It is well-structured, front-loads the purpose, and contains no 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?

For a simple tool with one parameter and an output schema, the description explains the return value and parameter meaning. It is complete enough given the tool's complexity and the presence of an output 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?

The input schema has one parameter with no description (0% coverage). The description adds 'The booking ID or confirmation number', which clarifies the parameter's nature beyond the schema title 'Booking Id'. This fully compensates for the lack of schema description.

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 details for a specific hotel booking', using the specific verb 'Get' and resource 'booking'. It distinguishes from sibling tools like get_vehicle_booking by specifying 'hotel 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 a specific booking) but does not provide explicit guidance on when not to use or mention alternatives like get_booking_link. It is adequate but lacks clarity for an AI agent to discriminate 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 indicate readOnlyHint=true (safe, no side effects) and destructiveHint=false. The description adds value by explaining the booking path: it returns a link to an external checkout page, and behavior varies by auth status (OAuth scope). It doesn't contradict annotations; it complements them with context about the external redirection and auth-dependent 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 longer but well-structured: it starts with the core purpose, then context, usage sequence, and parameter details. No fluff, each sentence adds value. Minor redundancy in repeating format for checkin/checkout could be trimmed but is not excessive.

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 (though not provided fully here), the description doesn't need to detail return structure. It covers prerequisites (prior search), optional parameters, and auth-dependent behavior. Gaps: doesn't mention error cases or what happens if hotel_id is invalid, but these are minor given the richness of the description and annotations.

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 the description must compensate, and it does. It explains each parameter's purpose: hotel_id as Vervotech property ID, checkin/checkout formats, num_adults default, children_ages format, and gondola_rate_id's deep-linking behavior. This adds meaningful semantics beyond the bare 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 booking options and returns a checkout link for a hotel, distinguishing it from siblings like get_booking (which likely retrieves existing bookings) and get_vehicle_booking_link (vehicle-specific). The verb 'get' plus resource 'booking link' is specific and the scope is unambiguous.

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

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

Explicitly says to use after search_hotels or get_hotel_details when the user wants to book, and mentions when to pass gondola_rate_id (when a specific rate is surfaced). It also notes the OAuth scope requirement for the in-conversation booking alternative, providing clear when-to-use 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 already indicate readOnlyHint=true. The description adds useful behavioral details: what each certificate includes (program, count, coverage, expiry, top-up) and that it returns a formatted list or instructions. It also requires an API key.

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, no redundant words. The most important information (action and resource) is front-loaded. 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?

With no parameters, an output schema available, and annotations providing safety profile, the description covers purpose, prerequisites, return details, and even potential alternative outcomes ('instructions to connect'). 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?

No parameters exist, so schema coverage is 100%. The description adds no parameter info, but it is not needed. Baseline of 4 is appropriate given no burden.

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

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

The description clearly states the action ('Get') and the resource ('free night certificates across loyalty programs'). It distinguishes from sibling tools like 'get_loyalty_accounts' by specifying certificates instead of general 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 mentions a prerequisite ('Requires a Gondola account (API key)') but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings. No alternatives are named.

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 and destructiveHint, so the description adds value by specifying what the tool returns (room options, pricing, cancellation policies, amenities). It aligns with annotations and provides useful context without redundancy.

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 no wasted sentences. It starts with a clear purpose, flows into usage guidance, then details parameters and return value. Every sentence adds value and is appropriately 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 an output schema, the description's summary of return content ('rooms, rates, policies, amenities') is sufficient. It also covers parameter semantics and usage flow. For a tool with 4 parameters and a well-defined output structure, this is complete.

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

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

Schema description coverage is 0%, but the description compensates fully with an Args section that explains each parameter: hotel_id's source (Vervotech property ID from search_hotels), date formats (YYYY-MM-DD), and num_adults default. This adds critical meaning beyond the schema's bare types and 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 verb 'Get' and the resource 'detailed information, room types, and rates for a specific hotel.' It distinguishes from siblings like search_hotels (which returns a list) and compare_rates (which compares multiple hotels), making its 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 says 'Use this after search_hotels to get full details for a hotel the user is interested in.' This provides clear context for when to use it. However, it does not explicitly exclude alternative tools like get_hotel_reviews or compare_rates, leaving some room for improvement.

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 behavioral detail: returns up to 10 recent reviews with ratings and comments, 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?

Two concise sentences plus structured Args/Returns section. No redundant information; 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 single param, clear output description (formatted list with author, rating, text, limit 10), and output schema exists, the description is fully complete for agent 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?

Single parameter hotel_id explained as 'The hotel's Vervotech property ID (from search results),' adding source context beyond schema type/title. Schema coverage 0% but description compensates well.

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 'Get guest reviews for a specific hotel' using a specific verb and resource. Distinguishes from siblings as no other review tools exist.

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 usage context: 'Use this to help users understand what other guests thought about a hotel.' Lacks exclusion criteria but appropriate given no alternative review 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. The description adds context about historical comparison and percentile rankings, which aligns with read-only behavior. No contradictory or missing behavioral details.

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 concise with a clear intro, usage guidance, and well-structured Args/Returns sections. Every sentence contributes 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?

Given the low complexity, schema coverage, and output schema existence, the description provides sufficient information about purpose, parameters, and return type (percentile rankings and value assessment). No major 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 coverage is 0%, but the description fully explains each parameter's meaning and source (e.g., hotel_id as Vervotech property ID, nightly_cash_cost as current cash rate). This compensates completely for lack of 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 it provides 'pricing analytics and percentile data for a hotel rate' and explains it shows historical comparison of cash and points rates. This distinguishes it from sibling tools like search_hotels, book_hotel, etc.

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 to help users understand if a rate is a good deal', providing clear context. However, it does not mention when not to use it or compare to alternatives like compare_rates or predict_price.

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, but the description adds valuable behavioral details: it returns a formatted list including points balance, tier status, estimated cash value, recent changes, expiration dates, and instructions to connect if no accounts. 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 concise with three short paragraphs. Every sentence adds value: purpose, returned fields, auth requirement, and return format. 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?

Given the low complexity (0 parameters, read-only), the description fully covers the tool's purpose, behavior, and prerequisites. The presence of an output schema means return values need not be elaborated further.

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

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

The tool has zero parameters, so the description cannot add meaning beyond the schema. Per guidelines, baseline is 4. The description appropriately outlines what the tool returns without needing parameter details.

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 the user's hotel and airline loyalty accounts', specifying the verb and resource. It distinguishes from sibling tools like get_payment_methods and get_free_night_credits 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 notes that a Gondola account (API key) is required, providing context. It does not explicitly exclude scenarios or mention alternatives, but the requirement gives a clear prerequisite.

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 agent knows it's a safe read. The description adds context about the output: 'Shows cash rates, points rates, and value percentiles for each available check-in date,' which goes 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 moderately long but well-structured: first line states purpose, followed by usage guideline, output summary, and parameter list. It is front-loaded and every sentence adds value. No unnecessary 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?

Given 4 parameters and an existing output schema, the description covers purpose, usage, parameter semantics, and return summary. It does not mention pagination or behavior for unavailable dates, but overall it provides sufficient context 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%, meaning property descriptions are missing in the schema. However, the description compensates by explaining each parameter: hotel_id is from search results, date formats, and nights default. This adds meaning beyond the schema titles, though some details like date format are assumed.

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 showing prices across a date range for a hotel. The verb 'get' and resource 'rate calendar' are specific, and it distinguishes itself from siblings like compare_rates (which compares multiple hotels) and predict_price (which predicts future prices).

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. It does not directly name alternatives but implies that for fixed dates other tools might be used; overall guidance is solid.

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 goes well beyond the readOnlyHint annotation by disclosing that a Gondola account/API key is required, that historical seat assignments are only included when Gondola parsed real row+letter seats from emails, and that the response notes how many more trips exist. These are meaningful behavioral details an agent needs to manage expectations.

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 concise summary up front, then a detailed field list, then a use-case sentence, then auth and Args/Returns sections. Every sentence adds useful information and the structure makes 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?

For a single-parameter read-only tool with an output schema present, the description covers all necessary context: what data is returned, when historical seat data exists, authentication requirements, limit semantics, and fallback behavior when no account is connected. Nothing important is missing.

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

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

The input schema provides only a bare 'limit' parameter with a default, and schema description coverage is 0%. The description fully compensates by explaining that limit controls the max number of past trips returned, that results are most-recent-first, and that the limit should be raised only when the full history is requested.

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 'Get the user's past trips' and specifies the scope: hotel stays and flights. It enumerates the exact data returned (dates, confirmation numbers, status, costs, loyalty programs, routes, airlines, etc.), making it easy to distinguish from siblings like get_upcoming_trips or search_flights.

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 for trip-history questions' and lists concrete use cases like favorite hotels, frequent routes, and seat preferences. It does not explicitly name when not to use it or alternatives, but the 'past trips' context and the sibling get_upcoming_trips make the boundary 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 declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying return structure (list of rate alerts with hotel names, dates, current rates) and noting API key requirement, which 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?

The description is three sentences plus a Returns line, efficiently front-loaded with the main purpose. Every sentence adds value without waste.

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 low complexity (no parameters, read-only), existing annotations, and an output schema, the description adequately covers the tool's behavior, specifying return fields and prerequisites.

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, and schema coverage is 100%. With zero parameters, the description cannot add meaning beyond what the schema provides, earning a baseline of 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 the tool gets active rate alerts for the current user, specifically for monitoring hotel price drops. This verb+resource combination is distinct from sibling tools like create_rate_alert and delete_rate_alert.

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 retrieving the user's rate alerts but does not explicitly state when to use this tool versus alternatives like create_rate_alert or delete_rate_alert. It mentions a prerequisite (requires Gondola account with API key) but lacks guidance on 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 declare readOnlyHint=true and destructiveHint=false. Description does not add significant behavioral context beyond stating it returns a list. It is consistent with annotations, but the bar is lower due to annotations covering safety profile.

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: one-line purpose, usage guidance, then args and returns. Every sentence serves a purpose with no extraneous text.

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 presence of an output schema (mentioned in context), the description covers the key aspects: purpose, usage, parameters, and return type. No major 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 descriptions are absent (0% coverage). The description provides brief but helpful explanations for each parameter, e.g., 'The hotel's Vervotech property ID (from search results)' and 'Check-in date in YYYY-MM-DD format.' This adds value but is minimal.

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 title 'Get similar hotels' and first sentence 'Find hotels similar to one the user is looking at' clearly state the verb and resource. It distinguishes from siblings like search_hotels, 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?

Explicitly says 'Use this when a user wants alternatives, comparisons, or asks show me hotels like this one.' Provides clear context but does not mention when not to use 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?

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds behavioral context: returns results based on preferences, recent searches, popular destinations, and upcoming holidays. This helps the agent understand the personalization logic.

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 plus a concise return description. Front-loaded with purpose. Every sentence earns its place. Could be slightly shortened, but no waste.

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 good annotations, the description covers purpose, usage context, and return value. No obvious gaps. An output schema exists, so return details are likely handled there.

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 parameters and 100% schema coverage, the baseline is 4. The description adds value by explaining that results are influenced by user context and popular trends, which is not captured in the empty schema.

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

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

The description explicitly states it provides 'personalized travel suggestions and trip inspiration' and 'curated hotel recommendations'. It clearly distinguishes from sibling tools like search_hotels or get_hotel_details by focusing on suggestion-based discovery.

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?

Directly states when to use: 'Great for when the user doesn't know where to go.' While it doesn't list exclusions or alternatives, the sibling tool names and clear purpose allow the agent to make appropriate choices.

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, destructiveHint=false, and openWorldHint=false, so the read-only safety profile is covered. The description adds genuinely useful behavioral context beyond the annotations: the contents of the returned context, that preferences may be learned from past conversations, that a Gondola account/API key is required, and the fallback behavior of returning 'instructions to build one.' No contradiction with annotations.

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

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

The description is front-loaded with the primary purpose, then covers contents, usage timing, alternative routing, auth, and return format in a logical sequence. It is slightly redundant in listing the contents and then adding a 'Returns:' line, but every sentence still contributes meaningful guidance.

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 zero-parameter read-only tool with an output schema, the description is quite complete: it covers what data is included, when to call it, how to use it, which sibling to use for raw evidence, auth requirements, and the fallback response. It does not mention the sibling get_travel_profiles, but the description's emphasis on being 'the single best source' gives enough signal for an agent to select this tool.

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

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

The tool has zero parameters, so the schema provides nothing to describe; the baseline for 0 params is 4. The description does not need to explain parameter meaning, and it appropriately focuses on what the tool returns instead of parameter details.

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

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

The description opens with a specific verb and resource ('Get the user's saved travel context') and states its purpose ('to personalize recommendations'). It explicitly differentiates itself from the close sibling get_past_trips: 'For raw evidence from actual past reservations... use get_past_trips.' An agent can clearly tell what this tool does and what it is not.

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 invocation guidance: 'Call this once at the start of a travel or planning session' and tells the agent how to use the output, 'weigh it across hotel, flight, and car recommendations.' It also names the alternative for a different need, get_past_trips, and adds the auth prerequisite of a Gondola account.

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 the operation read-only and non-destructive. The description adds useful behavioral context beyond that: it requires an API key, returns a 'Formatted list of travel profiles with IDs,' and may return 'instructions to add one' when no profiles exist. This is meaningful operational transparency with no contradiction of 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 short and front-loads the core purpose, but the second sentence is convoluted and repeats 'guest name, email, and phone' and 'prefill' unnecessarily. It conveys useful context but could be tighter without losing meaning.

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 zero-parameter, read-only tool with an output schema, the description covers everything an agent needs: what the tool returns, what profiles are for, and the API key requirement. Nothing essential is missing.

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

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

The tool has zero parameters, so the baseline for this dimension is 4. There is nothing for the description to add about parameter meanings; the schema correctly shows an empty properties object.

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

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

The description states a specific verb and resource: 'Get the user's saved travel profiles' and clarifies what those profiles contain (guest name, email, phone presets, Profile ID). It clearly distinguishes this from collecting checkout details field by field and, in context, from sibling tools like get_loyalty_accounts or get_traveler_context.

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 the usage scenario: profiles exist to prefill guest details at checkout 'instead of collecting name, email, and phone field by field.' It also states a prerequisite, 'Requires a Gondola account (API key).' However, it does not explicitly compare this tool to alternatives or state when not to use it, so usage guidance remains mostly implied.

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, but the description adds valuable context: it is a read operation, seat assignments are only included when Gondola parsed actual row+letter seats, an API key is required, and the tool returns instructions if no account is connected. This goes well beyond the annotation baseline.

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

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

The description is front-loaded with a clear purpose and then expands into a detailed but justified list of return contents. It is slightly long and has a redundant final 'Returns:' section, but every part contributes useful information about scope, auth, and output behavior.

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 zero parameters and an output schema exists, the description is fully sufficient. It explains what the tool returns, what data fields may appear, what authentication is required, and what happens when the user has no connected account. No essential detail is missing.

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

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

There are zero parameters, so the baseline of 4 applies; there is no parameter schema gap to compensate for. The description still usefully clarifies what the return payload covers, which is more than enough for a parameterless call.

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 and resource: 'Get the user's upcoming trips' and enumerates what is included (hotel stays, flights, car rentals). The word 'upcoming' clearly distinguishes it from the sibling get_past_trips, and the content list removes ambiguity about 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?

The description clearly implies this tool is for upcoming travel reservations and notes the prerequisites: a Gondola account and API key. It does not explicitly name alternatives or exclusion conditions, but the contrast with get_past_trips is evident and the fallback behavior when no account is connected is stated.

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 no contradiction. The description adds valuable context about return fields (vendor, pickup/dropoff, vehicle, rate, status), enhancing 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?

The description is two short paragraphs, front-loaded with the main purpose. Every sentence adds value—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-only tool with one parameter and output schema, the description covers the argument and return content. It could mention error handling (e.g., invalid ID) but is adequate 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?

The schema has one string parameter with 0% description coverage, but the description adds meaning: 'The Gondola booking ID (confirmation number).' This clarifies the parameter's format and context, compensating for the schema's lack of description.

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 details for a specific vehicle booking' with a specific verb and resource. It distinguishes from siblings like 'get_vehicle_details' (vehicle info) and 'book_vehicle' (creation).

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

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

The description explains the required argument (booking_id as Gondola confirmation number), providing clear context. However, it does not explicitly guide when to use this over siblings like 'get_booking', but the purpose is sufficiently 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 declare readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context beyond stating it returns coverage details or an error. It does not mention any side effects, prerequisites, or response format details.

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 extremely concise with two sentences plus Args/Returns. It front-loads the purpose without any redundant or extraneous text.

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 (not shown) and only one required parameter, the description sufficiently covers the tool's function. It mentions coverage details and errors, which is adequate for a simple read-only retrieval 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?

The description explains that booking_id is a 'Gondola booking ID of the vehicle booking', adding clarity beyond the schema's simple type and title. Schema coverage is 0%, so this parameter information is valuable.

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 rental car CDW/LDW coverage for a vehicle booking, using specific terms. It distinguishes from siblings like get_vehicle_booking and credit_card_coverage.

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 does not provide explicit guidance on when to use this tool versus alternatives like credit_card_coverage. It only states what it does, not when 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, and the description adds meaningful behavioral context: it returns a checkout link, requires the mcp:book OAuth scope for partner-specific in-conversation options, and returns booking instructions tailored to the user's auth status. No contradiction with annotations is present.

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 concise main statement followed by an Args/Returns breakdown. The parenthetical about partner OAuth scope is relevant and not filler, though the Returns line is slightly vague and could be more explicit.

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 link retrieval tool with 5 required parameters and an output schema, the description provides enough information to invoke the tool correctly. It identifies the source of each parameter, notes auth-dependent behavior, and clarifies the booking flow. Minor gaps like exact datetime format variants or error behavior are not critical for selection and 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 the burden of documenting all 5 parameters. It names each argument and adds source context ('from search_vehicles', 'from search results') and format guidance for datetimes ('ISO format'), which goes 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 clearly states the tool gets a Gondola.ai deep link for a specific vehicle from search results, which is a specific verb-resource pairing. It does not explicitly name sibling tools like get_vehicle_booking or get_booking_link, but the phrase 'deep link' and 'checkout' makes the function reasonably distinct.

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 useful context: it is the booking path for a connection and may return an in-conversation option for approved booking partners with the mcp:book OAuth scope. However, it does not explicitly say when to prefer this tool over alternatives such as get_vehicle_booking or get_booking_link, leaving some routing to inference.

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 this as read-only and non-destructive; the description adds the behavioral context that this is a follow-up lookup returning a specific set of detail categories such as extras, charges, and policies. No contradiction with 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 front-loaded with the core purpose, then a one-line usage directive, then a clean parameter list and returns summary. No filler or redundant repetition of schema titles.

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 7-parameter lookup with an output schema, the description gives the prerequisite workflow, all parameter semantics, and the category of returned data. Nothing essential is missing for an agent to call it correctly.

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

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

Schema coverage is 0%, but the description compensates fully by explaining every parameter's source and, for vendor_code, gives concrete examples ('ZE' for Hertz, 'AL' for Alamo). All seven parameters are accounted for in plain language.

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

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

The description states a specific action ('Get detailed information') on a specific resource ('specific rental vehicle option') and lists what is included: extras, insurance options, charges, and cancellation policy. It does not explicitly differentiate from the sibling get_vehicle_booking, which could overlap, so it falls just short of full sibling distinction.

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

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

It explicitly says to use it after search_vehicles, which sets clear context and ordering. It does not name alternatives or exclusions, so it gets a 4 rather than 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, and the description adds valuable context: trip-independent, looks across all programs, reports expiring points, transfer opps, tailors to travel profile. 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?

Description is informative and well-structured, front-loaded with the main verb and resource. A few sentences could be tightened but 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?

Covers all aspects: behavior, when to use, no arguments, return format (Markdown portfolio summary or instructions to connect accounts). With an output schema existing, no further detail on return needed.

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

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

Tool has zero parameters (schema coverage 100%), so baseline is 4. The description explicitly states 'Takes no arguments', which is clear 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 uses specific verbs ('analyze', 'surface') and resource ('loyalty portfolio') and clearly distinguishes from siblings by mentioning alternatives for trip-specific 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 when to use ('how to make the most of points, expiring, transfers') and when not to use (specific trips, pointing to search_hotels/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 and destructiveHint=false. The description adds that it uses historical price data and returns a recommendation, confidence level, and key signals. This 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?

The description is well-structured with a concise intro, usage note, and organized Args section. It is front-loaded with purpose and contains no fluff, though could be slightly shorter.

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 (5 required), 0% schema coverage, and an existing output schema, the description provides sufficient context for parameter meanings and usage context. It is complete enough for an agent to use the tool 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 includes an Args section with clear explanations for each parameter, such as hotel_id being the Vervotech property ID, date formats, and currency examples. This fully compensates for the lack of 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 it predicts whether to book now or wait for a better price using historical data. It specifies the verb 'predict' and the resource 'price timing', and distinguishes itself from siblings like 'compare_rates' and '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?

Explicitly says to call when a user asks 'Should I book now or wait?' or wants to know if a price is good. It provides clear context but does not mention when not to use or contrast with 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, openWorldHint=true, and destructiveHint=false. The description adds mild context by stating the output is 'factual' metadata with listed prices, but it does not disclose pagination, result-size limits, or date-filter behavior beyond the schema defaults.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to identifying the resource and the nature of the returned data.

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 is adequate for a minimal keyword-only invocation, and the output schema covers return values. However, with many optional filter parameters and no parameter descriptions in the schema, an agent gets no guidance on using location, date, radius, or classification filters.

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 should compensate for the 10 parameters, but it does not mention any input semantics beyond the overall search concept. Parameter names and enums in the schema are self-explanatory, but date formats, radius-unit behavior, and classification values are left undocumented.

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

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

The description states a specific verb ('Search') and resource ('live events'), and clarifies the return contents: event, venue, date, and listed-price metadata. It is clearly distinct from hotel, flight, and vehicle search siblings, though it does not explicitly name an alternative.

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 usage context is implied by the resource name: an agent needing live event data should use this tool. However, there is no explicit guidance about when not to use it or how it compares to related 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?

With readOnlyHint=true already available, the description still adds substantial behavioral context: results are ranked by the backend based on loyalty and travel history, only cash prices are returned, award pricing must not be implied, and browse-mode round trips are searched as two one-way legs.

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 summary is front-loaded, the Args section is ordered logically, and the caveat about award pricing is clearly separated under Returns. Every paragraph earns its place, and the length is justified by the tool's 10 parameters and important behavioral constraints.

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

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

For a tool with 10 parameters, an output schema, and nuanced booking-mode behavior, the description covers all essential invocation details: required parameters, optional filters, pagination, mode restrictions, and the cash-only limitation. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, but the description's Args section richly documents every parameter: origin/destination accept codes or city names, date format is specified, cabin_class values are enumerated, mode restrictions are explained, and max_stops semantics are clarified. This goes far beyond the bare input 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 states a specific verb and resource: 'Search for flights by route and date and return cash-priced options.' This clearly distinguishes the tool from hotel, vehicle, and event search tools among the siblings.

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

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

The description gives clear usage context: browse mode is the default, book mode is restricted to explicit user requests, and pagination instructions tell the caller how to get more results. It does not explicitly contrast with sibling search tools, but the flight-specific scope makes that contrast unnecessary.

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 behavioral context beyond annotations: it explains return format (cash vs points rates, CPP, deal scores), chain_name fallback, and limit behavior. No contradiction with readOnly/readOnly/world/destructive hints. The annotations already cover the read-only safety, so the description supplements well.

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 an introductory paragraph and bullet-like Args section. Every sentence adds value, from the unique selling point to detailed parameter semantics. It is concise yet thorough, with no redundant information.

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

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

Given 8 parameters and an existing output schema, the description covers all necessary information: parameters, return summary, edge cases, and usage guidelines. It is self-contained and leaves no ambiguity for an AI agent.

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

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

Schema description coverage is 0%, but the description's Args section provides comprehensive parameter explanations including examples, defaults, and conditional behaviors (e.g., chain_name case-insensitive match, loyalty_points affordability check). This fully compensates for the lack of schema-level 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 searches hotels by location and dates with cash and points pricing, and explicitly highlights its unique advantage over other travel searches, distinguishing it from siblings like get_hotel_details or 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?

The description provides detailed guidance on parameter usage, defaults, and edge cases (e.g., chain_name fallback behavior, limit usage advice). However, it lacks explicit when-to-use versus alternative tools, though the uniqueness statement partially addresses this.

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 a list of vehicles with rates and details, which provides additional context about the output 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 briefly structured with args listed and a return statement. It is front-loaded with purpose. Could be slightly more concise, but 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 4 parameters, no nested objects, and presence of an output schema, the description covers all necessary aspects: purpose, parameter semantics, and return format. It is complete for an agent to use the 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?

With 0% schema description coverage, the description fully explains each parameter: pickup_location as 'Airport IATA code' with examples, datetime fields in ISO format, and vehicle_class with a list of options. This adds significant value beyond the schema structure.

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' with a specific verb and resource. It is distinct from sibling tools like get_vehicle_details or book_vehicle, but does not explicitly differentiate itself.

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 searching available vehicles with location and dates. It provides examples for pickup location (IATA codes) but does not explicitly state when to use this tool vs. alternatives like get_vehicle_details or other 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?

Annotations already indicate a non-destructive write (readOnlyHint=false, destructiveHint=false). The description adds useful behavioral context: requires API key, returns confirmation/error, and entries persist across sessions.

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 clear purpose, usage guidelines, parameter/return details. Every sentence adds value, 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 prerequisites, parameter semantics, return values, and persistence. With only one parameter and output schema, it is quite complete. Could mention if updating existing entries replaces or appends, but not critical.

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 explains the parameter profile_entry with specificity and actionability guidance, including good/bad examples.

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 ('Save') and resource ('traveler profile'), clearly distinguishing this write operation from siblings like get_traveler_context. It explicitly states what is saved: durable preferences, likes, dislikes, trip experiences.

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 guidance: use for durable preferences (examples given), not for temporary logistics. Also notes the prerequisite of a Gondola account and explains that saved entries persist and come back via get_traveler_context.

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