Hotel & Vacation Rental MCP - live prices & reviews across Booking, Airbnb, Vrbo & Google Hotels

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

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond these flags: it operates on 'known listing(s)' (not a search), returns 'day-by-day' granularity, and is limited to 'one platform' per call. This sets expectations about input requirements and output shape that annotations do not cover.

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

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

The description is a single sentence of 14 words, front-loaded with the core function ('Day-by-day availability'). It contains no fluff or redundant information; every word contributes to defining the tool's purpose and scope.

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

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

Despite lacking an output schema, the description clearly signals the output type (day-by-day availability) and the required context (known listings, one platform, date range). It is adequate for a moderately complex tool with 7 parameters. However, it does not mention edge cases like inclusive/exclusive date boundaries or error behavior when a listing is unknown, which could be helpful given no output schema exists.

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 already cover 86% of the 7 parameters, including explicit descriptions for url, listingId, listingIds, startDate, endDate, and platform. The description reinforces these by implying their combined use (listing(s) + platform + date range) but does not add new parameter-specific semantics beyond what the schema provides. The high schema coverage warrants the baseline score of 3.

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

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

The description clearly states the tool checks 'Day-by-day availability for known listing(s) on one platform over a date range.' It uses a specific verb (check availability) and resource (known listings) with clear scope (one platform, date range). This distinguishes it from siblings like search_stays (search) and get_price (pricing), making its purpose immediately evident.

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 no guidance on when to use this tool versus alternatives like search_stays or get_listing. It does not mention exclusions, prerequisites, or alternative recommendations, leaving the agent to infer usage from the description alone.

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 establish readOnly/idempotent/non-destructive safety, and the description adds valuable behavioral context beyond that: 'Returns offers + min/median' discloses the output shape, and 'Fee coverage differs per platform — compare on totalPrice' warns about a cross-platform inconsistency. It also explains that the tool either resolves via Google or prices provided listings directly, which is a notable operational behavior. No contradiction with annotations.

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

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

The description is two sentences and approximately 60 words. The first sentence is a crisp purpose statement, and the second packs mode guidance, output summary, and a key caveat without redundancy. It is front-loaded and every clause earns its place.

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

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

The tool has 10 parameters, no output schema, and two modes, but the description covers the essential context: purpose, mode selection, return values, and an important fee-cover caveat. It doesn't enumerate every parameter (schema partially does), and it omits details like input validation/error behavior, but for a comparison tool this is a strong, nearly complete description.

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 only 50% schema description coverage, the description compensates by mapping parameters to modes: name/location/googleHotelId are grouped as the Google-resolve path, and listings is explained with format examples ('platform:listingId'). It also clarifies that listings mode is for known-same properties and adds the totalPrice comparison caveat. However, it leaves checkIn/checkOut/currency semantics to the schema (which lacks descriptions for them), so it doesn't fully complete the parameter picture.

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 'Cross-OTA price comparison for one property,' a specific verb+resource statement that clearly distinguishes this from siblings like get_price (single price) and check_availability. It further details two distinct operational modes (Google-resolved vs. direct listings), leaving no ambiguity about what the tool does.

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 explicit guidance on choosing between the two modes: 'Either let Google resolve it (name / location / googleHotelId), or pass listings=...' and clarifies when direct listings are appropriate ('for listings you already know are the same property'). It also advises on interpreting results ('compare on totalPrice'), but it does not explicitly reference sibling tools or state when to prefer this over get_price/check_availability, so it misses the top bar.

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, idempotentHint, and destructiveHint, covering safety. The description adds 'Costs 0 credits', which is useful operational context. It also explains the polling nature, but does not go into error handling or edge cases.

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

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

The description is two sentences, front-loaded with the core purpose, and every word adds value. There is no filler or repetition of schema details.

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?

This is a simple one-parameter tool with strong annotations and no output schema. The description covers the purpose and adds cost information, which is sufficient for the tool's complexity. It does not describe return values, but that is not strictly required for such a simple 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 schema provides 100% coverage for jobId with a clear description, so the baseline is 3. The description does not add any additional semantic meaning to the parameter beyond what the schema already states.

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 'Poll status and fetch results' and identifies the resource as 'an async scrape job'. This clearly distinguishes it from sibling tools like get_price or search_stays, which are all about stay data rather than job status.

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 after an async job is initiated, and the title 'Check an async job' reinforces this. It does not explicitly state when not to use it or mention alternatives, but the unique purpose among siblings makes the context 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: 'optional live price for dates' indicates date-sensitive pricing behavior, and listing the included fields gives insight into the response content beyond what annotations convey.

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

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

A single, information-dense sentence that front-loads the core purpose and lists content. No filler or repetition; every word contributes.

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 9-parameter tool with no output schema, the description is reasonably complete: it names the return categories and the optional live-price feature. It does not explain all parameters or edge cases, but the schema covers many, and annotations provide safety context. Could be more explicit about when pricing is returned, but overall adequate.

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

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

Schema coverage is 56%, and the description adds value by tying date parameters to 'optional live price for dates'. However, it does not explain other undocumented parameters like currency or checkIn/checkOut formats, nor does it clarify the platform enum values. The description partially compensates for schema gaps but not fully.

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 verb and resource: fetch full detail for one listing, listing specific content (amenities, photos, host, ratings). It distinguishes from siblings like get_price (price-focused), get_reviews (reviews-only), and search_stays (search) by emphasizing the comprehensive single-listing 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?

Usage is implied: use when you need full details for a specific listing, not for searching. However, it does not explicitly name alternatives or exclusions (e.g., 'for price only, use get_price'). The context signal of sibling tools helps but the description itself does not provide direct 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 the tool as read-only, non-destructive, and idempotent. The description adds minimal behavioral context beyond that, such as no mention of rate limits, auth requirements, or error behavior. 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?

A single, front-loaded sentence that concisely captures the essence of the tool. No filler or 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?

For an 8-parameter tool with no output schema, the description is too sparse. It omits critical details like whether checkIn/checkOut are required, what the response format is, currency handling, and how this integrates with other tools. The annotations clarify safety but not functional completeness.

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

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

Schema description coverage is only 38%, and the description does not compensate for the undocumented parameters (checkIn, checkOut, currency, listingId). The phrase 'specific dates + occupancy' hints at some parameters but adds no format, constraints, or default behaviors beyond the schema's sparse notes.

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, while not using a strong verb, clearly states the function: generating a price quote for one listing, scoped by dates and occupancy. This distinguishes it from sibling tools like compare_prices (likely multi-listing comparison) and check_availability (availability, not pricing).

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

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

The description implies usage context (a single listing, specific dates, occupancy) but does not explicitly state when to use it over alternatives like compare_prices or search_stays. No exclusions or alternative tool mentions 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 already declare read-only, idempotent, and non-destructive. The description adds behavioral context by noting results are 'normalized' and 'paginated', which indicates output format and pagination behavior 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 a single concise sentence that front-loads the key qualifiers (normalized, paginated) and scoping (one listing, one platform). 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?

This tool has 8 parameters and no output schema, but the description only hints at the output ('reviews') and scope. It does not explain the expected response structure, parameter relationships, or edge cases, leaving significant gaps 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?

Schema coverage is only 13% (only 'language' has a description). The description mentions 'one listing' and 'one platform' but does not clarify which parameters identify the listing (e.g., listingId vs. url) or explain other parameters like sort, limit, cursor, or minRating. It fails to compensate for the lack of schema documentation.

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 this tool retrieves reviews for a single listing on a single platform. It distinguishes itself from siblings like get_listing or compare_prices by specifying 'reviews' and the scope constraints.

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

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

Usage is implied: use when you need reviews for one listing on one platform. However, no explicit guidance on when to prefer this over other tools, or what the alternatives are, beyond the inferred scope.

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, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. The description adds useful behavioral context by noting that it 'returns normalized listings with embedded prices when dates are supplied,' which clarifies output conditions and result format—details not covered by 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 a single, well-structured sentence that front-loads the core purpose ('Discover properties') and packs essential specifics (platforms, filters, output condition) without waste. Every phrase earns its place, making it highly concise and readable.

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

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

Despite having 18 parameters and no output schema, the description gives a high-level overview but omits important details like pagination (cursor), sorting, currency, and the nature of normalized listings. It mentions the return of normalized listings with embedded prices when dates are supplied, which is helpful, but it is not complete enough to fully understand the tool's behavior in all cases. For a tool of this complexity, more context (e.g., result structure, error conditions) would be expected.

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 61%, so the description carries some burden for parameter meaning. It groups parameters into categories (location, dates, occupancy, filters) and notes that prices are returned 'when dates are supplied,' which adds context for checkIn/checkOut. However, it does not elaborate on individual parameter ranges, formats, or dependencies beyond what schema already provides. Overall, it adds moderate value but does not fully compensate for the uncovered 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 a specific action ('Discover properties') with a clear resource (properties across Vrbo, Booking, Airbnb, and Google Hotels) and scope (by location, dates, occupancy, and filters). It distinguishes itself from sibling tools like get_listing (which retrieves a specific listing) or compare_prices (which compares prices) by focusing on multi-platform search and normalized results.

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: use this tool to search for accommodations across multiple platforms. However, it does not explicitly mention when not to use it or provide alternatives (e.g., 'for a specific listing, use get_listing'). The context is clear but lacks exclusionary guidance or direct comparison with siblings.

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