Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

expedia_properties_reviews

Fetch a short set of Expedia hotel guest reviews and overall rating for one property by providing property ID, check-in, and check-out dates.

Instructions

Expedia Stays property guest reviews. Returns the overall rating and a short set of guest reviews, typically around six, for one Expedia hotel. property_id, check_in and check_out (YYYY-MM-DD) are required in the JSON body; adults (1-9, default 2), currency and locale are optional. Each review has the reviewer name, date, rating label, message and verified flag. It is not the full review archive.

Input Schema

NameRequiredDescriptionDefault
optionYesProperty reviews payload

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / option / 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 / option / required
      Added value: +[
      +  "check_in",
      +  "check_out",
      +  "property_id"
      +]
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations the description carries the burden, and it does meaningful work: it discloses the return shape (overall rating plus reviewer name, date, rating label, message, verified flag) and an important limitation ('typically around six', 'not the full review archive'). It stops short of covering auth, errors, or rate limits, so not a 5.

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?

Front-loaded with what the tool returns, then required/optional params with formats, then the per-review fields, then the scope caveat. Every sentence adds information; nothing is redundant.

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

Completeness4/5

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

No output schema exists, so the description usefully covers the return fields and cardinality; params and formats are documented. It is nearly complete for a single-argument lookup, missing only operational details like auth requirements or error behavior.

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% (baseline 3), but the description adds constraints the schema lacks: check_in/check_out are YYYY-MM-DD, adults is 1-9 with default 2, and currency/locale are optional. These defaults and ranges are not expressed anywhere in the schema, so this is above baseline.

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+resource ('Expedia Stays property guest reviews') and scopes it precisely: 'Returns the overall rating and a short set of guest reviews ... for one Expedia hotel.' The closing line 'It is not the full review archive' separates it from an archive-style sibling, so an agent can tell what it is without opening the schema.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: you call it when you have a property_id and want that hotel's reviews. The 'not the full review archive' note hints at a boundary but never names the alternative tool or gives an explicit when-to-use/when-not-to-use rule.

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