Skip to main content
Glama

Crawlora MCP

by net.crawlora
OverviewDiscussionsAdmin

hotels_search

Read-only

Returns a page of date-bound Hotels.com hotel search results for either a free-text destination or a numeric Hotels.com region_id: normalized property cards with per-night and per-stay prices, review score and count, location, thumbnail, amenities, and promotional badges. Provide exactly one of query or region_id; region_id skips destination typeahead resolution. Prices are the live rates Hotels.com shows for the requested check-in and check-out dates. Use hotels_property to get Hotels.com property details.

Input Schema

NameRequiredDescriptionDefault
pageNoOne-based result page, default 1.
queryNoFree-text destination to resolve when region_id is not supplied. Provide query or region_id.
roomsNoRooms requested, 1-8; omitted or zero uses the default 1.
adultsNoAdult guests, 1-9; omitted or zero uses the default 2.
localeNoLanguage/country locale, default en_US.
check_inNoRequired check-in date in YYYY-MM-DD format.
currencyNoPrice currency code, default USD.
check_outNoRequired check-out date in YYYY-MM-DD format, after check_in.
page_sizeNoProperties per page, default 20, maximum 50.
region_idNoResolved Hotels.com region identifier; use hotels_autocomplete to discover it. Takes precedence over query.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / adults / description
      Previous value: -"Adult guests, 1-9; default 2."New value: +"Adult guests, 1-9; omitted or zero uses the default 2."
    • changedInput schema / properties / rooms / description
      Previous value: -"Rooms requested, 1-8; default 1."New value: +"Rooms requested, 1-8; omitted or zero uses the default 1."
  2. Changed10 schema fields changed
    • addedInput schema / properties / adults / description
      Added value: +"Adult guests, 1-9; default 2."
    • addedInput schema / properties / check_in / description
      Added value: +"Required check-in date in YYYY-MM-DD format."
    • addedInput schema / properties / check_out / description
      Added value: +"Required check-out date in YYYY-MM-DD format, after check_in."
    • addedInput schema / properties / currency / description
      Added value: +"Price currency code, default USD."
    • addedInput schema / properties / locale / description
      Added value: +"Language/country locale, default en_US."
    • addedInput schema / properties / page / description
      Added value: +"One-based result page, default 1."
    • addedInput schema / properties / page_size / description
      Added value: +"Properties per page, default 20, maximum 50."
    • addedInput schema / properties / query / description
      Added value: +"Free-text destination to resolve when region_id is not supplied. Provide query or region_id."
    • addedInput schema / properties / region_id / description
      Added value: +"Resolved Hotels.com region identifier; use hotels_autocomplete to discover it. Takes precedence over query."
    • addedInput schema / properties / rooms / description
      Added value: +"Rooms requested, 1-8; default 1."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, and the description usefully adds that prices are live rates bound to the requested check-in/check-out dates and that results are normalized property cards with promotional badges. It still doesn't disclose pagination limits or how an unresolved region behaves, but the added context is meaningful.

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

Conciseness5/5

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

Four sentences, each earning its place, with the core purpose and the query/region_id rule front-loaded and the sibling pointer last. No filler or repetition.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, yet the description still summarizes the card shape as a convenience. Combined with the coverage of the query/region_id choice and date-bound pricing, nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: the mutually exclusive query/region_id contract and the fact that region_id skips destination typeahead resolution. This meaningfully clarifies parameter interaction beyond the per-field descriptions.

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

Purpose5/5

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

The description states a specific verb and resource ("Returns a page of ... Hotels.com hotel search results") and enumerates the returned fields (per-night/per-stay prices, review score, amenities, badges). It also distinguishes itself from the get-details sibling by pointing to hotels_property, so an agent can differentiate without opening schemas.

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

Usage Guidelines4/5

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

It gives a clear rule for the two entry paths ("Provide exactly one of query or region_id") and routes detail lookups to hotels_property. It stops short of contrasting against the other hotels_* siblings (offers, rates, reviews), so usage context is clear but not exhaustively scoped.

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

All Crawlora MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources