Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

tripadvisor_search

Search TripAdvisor hotels, restaurants, and attractions by geo ID and listing type. Filter by price, amenities, availability, and sort to retrieve ratings, reviews, and ranks.

Instructions

Search TripAdvisor places. Searches TripAdvisor places in the area given by the required geo_id, for the required type: hotel, restaurant, attraction, all, or an attraction category type from /tripadvisor/enums. Hotel and restaurant filters, offset, limit, locale, currency and sort are optional. Each result has title, URL, rating, review count, rank, price and location. Unsupported entity-only types return a validation error.

Input Schema

NameRequiredDescriptionDefault
sortNoSort value
typeYesListing type
classNoHotel class filter
limitNoMaximum results
geo_idYesTripAdvisor geo id
localeNoTripAdvisor locale
offsetNoZero-based result offset
currencyNoCurrency code
amenitiesNoHotel amenity filter ids
filter_idNoOptional hotel filter id
price_maxNoMaximum hotel price filter
price_minNoMinimum hotel price filter
pricing_modeNoHotel pricing mode
online_optionsNoRestaurant online option ids
restaurant_dateNoRestaurant availability date
restaurant_timeNoRestaurant availability time
travelers_choiceNoFilter Travelers' Choice hotels
restaurant_guestsNoRestaurant guest count
establishment_typesNoRestaurant establishment type ids
travelers_choice_botbNoFilter Best of the Best hotels

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.17.5
    • addedInput schema / properties / amenities / items
      Added value: +{
+  "type": "integer"
+}
    • addedInput schema / properties / establishment_types / items
      Added value: +{
+  "type": "integer"
+}
    • addedInput schema / properties / online_options / items
      Added value: +{
+  "type": "integer"
+}
  2. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the result shape (title, URL, rating, review count, rank, price, location) and the failure mode for unsupported types. It stops short of describing pagination behavior of offset/limit or any auth/rate-limit constraints.

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?

Front-loaded with the purpose and organized logically: scope, type values, optional filters, result fields, error case. The opening 'Search TripAdvisor places' is slightly redundant with the following sentence, but overall it is tight for a 20-parameter tool.

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?

For a 20-param tool with no output schema and no annotations, the description covers types, optional filter groups, result fields and the validation-error case, and points at the enums endpoint for category types. The notable gap is how to source a geo_id, which the sibling tripadvisor_autocomplete presumably provides.

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 real value the terse schema descriptions ('Listing type', 'Sort value') do not: it enumerates the legal type values and groups which optional params are hotel vs restaurant filters, clarifying the purpose of many of the 20 params.

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

Purpose4/5

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

States a specific verb+resource ('Search TripAdvisor places') and scopes it to an area given by geo_id, enumerating valid type values. It does not explicitly differentiate itself from siblings like tripadvisor_hotels or tripadvisor_reviews, so an agent must infer the boundary, but the core purpose is unambiguous.

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: pick a geo_id and a type, and optionally narrow with filters. It even flags that unsupported entity-only types return a validation error, which is useful. However, it never says when to prefer this over tripadvisor_hotels, tripadvisor_place or tripadvisor_reviews, nor how to obtain a geo_id.

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