Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

hotels_rates

Fetch live per-night and per-stay Hotels.com rates and availability for one property by numeric property ID and check-in/check-out dates.

Instructions

Get Hotels.com rates for one property. Returns one Hotels.com property's date-bound rates and availability: the same property card Search returns, with the live per-night and per-stay prices Hotels.com shows for the requested dates. property_id is the numeric global property id from a Search response's properties[].id; it is distinct from the legacy /ho/ URL id.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "request": "<request>"
    },
    "name": "hotels_rates"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestYesRates request

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / request / properties
      Added value: +{
+  "adults": {
+    "type": "integer"
+  },
+  "check_in": {
+    "type": "string"
+  },
+  "check_out": {
+    "type": "string"
+  },
+  "currency": {
+    "type": "string"
+  },
+  "locale": {
+    "type": "string"
+  },
+  "property_id": {
+    "type": "string"
+  }
+}
    • addedInput schema / properties / request / required
      Added value: +[
+  "check_in",
+  "check_out",
+  "property_id"
+]
  2. Addedv1.16.2

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that prices are live and date-bound and what the return contains, but says nothing about side effects (read-only), auth/permissions, rate limits, or failure behavior, leaving real gaps for a no-annotation tool.

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

Conciseness4/5

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

Three sentences, front-loaded with purpose, then return shape, then id provenance. No filler, though the second sentence is dense and could be tightened.

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

Completeness3/5

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

There is no output schema or annotations, so the description must cover everything; it does explain the return (per-night/per-stay prices and availability) and id source well. However it omits the date format expected for check_in/check_out and the effect of locale/currency, which are real gaps for a nested-request tool.

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 description coverage is reported at 100%, so the baseline is 3; the description adds genuine value by defining property_id as the numeric global id from Search's properties[].id and explicitly warning it differs from the legacy /ho<id>/ URL id. It implies check_in/check_out bound the returned rates but gives no date format or locale/currency semantics.

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?

States a specific verb and resource ('Get Hotels.com rates for one property') and immediately scopes it as date-bound per-night/per-stay pricing plus availability. It also distinguishes the resource from the search flow by noting this returns 'the same property card Search returns', so an agent can tell it apart from hotels_search or hotels_property without opening a schema.

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?

Gives clear preconditions for use: property_id must come from a Search response's properties[].id, and dates are required for the rate lookup. It does not name alternative tools (e.g., offers, reviews, property detail) or state when-not to use this, so it stops short of full routing guidance.

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

Deploy Server

Other Tools