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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the day-by-day granularity and single-platform constraint, but says nothing about rate limits, failure behavior for invalid ids, or response shape.

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 with no filler; every clause (day-by-day, known listings, one platform, date range) constrains the call meaningfully.

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, multi-platform tool with no output schema and platform-specific edge cases handled only in the schema, the description is thin: it omits the search-then-check workflow and any notion of what a result looks like.

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 88%, so the schema itself carries the parameter meaning, including the platform-specific rules for listingIds. The description only echoes 'known listing(s)' and 'one platform', adding no syntax or format detail beyond the schema, matching the baseline 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?

States a specific verb+resource ('Day-by-day availability') with scope qualifiers (known listing(s), one platform, date range). The word 'known' implicitly routes discovery to search_stays, but it never names that sibling, so differentiation is partial.

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?

'Known listing(s)' implies this runs after a search and not for discovery, which is a useful hint. However, it never states the alternative explicitly (search_stays) nor the prerequisite that listingId/platformListingId must come from a prior search.

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 readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds almost nothing beyond that — no note on quote freshness, expiry, rate limits, or volatility of pricing, which are the behavioral traits that actually matter for a pricing call.

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?

It is a single telegraphic fragment with zero padding, so nothing is wasted. However, for a 9-parameter pricing tool the brevity crosses into under-specification rather than tight editing.

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 9 parameters, two required, no output schema, and only 56% schema coverage, the description is far too thin. An agent cannot tell from it that dates are effectively mandatory for a meaningful quote, nor what the response contains or how pricing is scoped.

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 56%, leaving checkIn, checkOut, currency, and platform undocumented. The description only vaguely gestures at 'specific dates + occupancy' and supplies no date format, currency convention, or explanation of how occupancy fields interact, so it does not compensate for the coverage gap.

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 concrete verb+resource (price quote) and scopes it to a single listing, with the two dimensions that drive the result (dates and occupancy) named upfront. It is clearly separable from siblings like compare_prices and check_availability, though it never names an alternative directly.

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?

There is no explicit when-to-use, when-not-to-use, or alternative routing guidance. An agent must infer that this is the single-listing price lookup versus compare_prices purely from the tool name and the phrase 'for one listing'.

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 cover readOnly, idempotent and openWorld, so the description's job is to add pagination semantics — and it does, disclosing that one call returns one page and cap is 100 (a constraint the schema's `limit` does not encode). It stops short of explaining how to advance to the next page, which matters given no cursor/offset parameter exists.

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

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

Two sentences, front-loaded with what is returned and immediately followed by the paging constraint. No filler or restatement of the title.

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 25% schema coverage and no output schema, the description omits how to identify a listing (url vs listingId vs platform), how to iterate pages, and what a normalized review contains. It answers the paging-size question but leaves most invocation-critical detail to guesswork.

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 25% across 8 params, so the description carries heavy burden, yet it clarifies only the effective limit cap. It never explains the url-vs-listingId relationship, sort enum effects, minRating, or the booking-specific country hint — all of which remain ambiguous.

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?

States a specific verb and resource ('Normalized reviews') and narrows scope to 'one listing on one platform', which is more precise than the title. It is clearly distinct from siblings like get_listing or get_price, but never names those siblings explicitly.

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 only implied: the tool fetches reviews for a given listing+platform, so an agent can infer it needs an identifier. There is no explicit when-to-use / when-not-to-use guidance, no mention of prerequisites (listingId vs url, country hint for booking), and no routing versus get_listing.

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 readOnly, idempotent, openWorld, and non-destructive, so the safety bar is low. The description still adds real value by describing the return shape (normalized listings across platforms) and the conditional price embedding when dates are given, which matters because no output schema exists.

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 with zero filler; the primary action comes first and the return-shape qualifier follows after the semicolon.

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 17-parameter, no-output-schema tool, the description covers the search dimensions and explicitly states what comes back, closing the biggest gap. What remains missing is sibling routing and any note that results are per-platform and paginated.

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?

At 65% schema description coverage across 17 parameters, the schema carries most of the semantics (defaults, enum values, date formats, child-age coupling). The description only names the high-level filter dimensions (location, dates, occupancy, filters) without adding syntax or constraints 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?

States a specific verb (Discover) and resource (properties/stays) plus the four upstream platforms it federates over, which is concrete and readable. It does not, however, distinguish itself from siblings like compare_prices, check_availability, or get_listing, so the agent must infer the boundary.

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

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

No guidance on when to prefer this over the six sibling tools, nor any exclusions or prerequisites. The only conditional hint is that prices appear when dates are supplied, which is behavioral rather than a usage rule.

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