Skip to main content
Glama

Tineo

by ai.tineo.api
OverviewDiscussionsAdmin

Search Hotels & Lodging

search_hotels
Read-onlyIdempotent

Search for hotels and accommodations. Ordinary searches use the text query. Dated radius searches use a geographic bounding box and exact distance filter; SearchAPI does not apply the text query or style preferences within the radius. Provider coverage may be incomplete and prices may change. A hotel_place_id without radius_meters searches by the resolved hotel name; with radius_meters it searches nearby. Only a unique identity match retains its offer links.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of hotel results to return (max 10).
queryNoSearch query or destination city (e.g. 'hotels in Tokyo'). Required for ordinary hotel search. Google Hotels can mix in properties from nearby towns or districts; cards outside the searched place carry outsideRequestedArea and distanceFromAreaKm, and areaNote says how many. When the user wants a specific neighbourhood, get its coordinates or center_place_id from places_search and use a radius search. Radius search ignores this text in provider selection and filters by geography only. For hotel_place_id without radius_meters, the resolved property name is used for provider search and identity matching.
trip_idNoOptional Tineo trip ID (from trips_list) this request is for. Used only to default the currency to that trip's currency when currency is omitted and the user has no preferred currency; ignored if the trip is not found or not accessible to the user.
check_inNoCheck-in date in YYYY-MM-DD format (alias: checkIn).
currencyNoOptional ISO-style three-letter currency code. Omit to use the user's preferred currency, then the currency of the trip given by trip_id, then USD.
latitudeNoRadius center latitude. Supply together with longitude instead of a place ID. Query may be omitted for a coordinate-only radius search.
check_outNoCheck-out date in YYYY-MM-DD format (alias: checkOut).
longitudeNoRadius center longitude. Supply together with latitude instead of a place ID. Query may be omitted for a coordinate-only radius search.
adult_countNoNumber of adults (alias: adults).
radius_metersNoGeographic search radius, default 1000 meters when center_place_id or coordinates are given. Requires stay dates and a center. Text query and style preferences are not applied to radius provider selection.
hotel_place_idNoOptional specific hotel place ID. Searches priced inventory by hotel name, or nearby when radius_meters is supplied. Retains offer links only if identity is uniquely verified. Requires check_in and check_out.
center_place_idNoOptional place ID for the radius center, from places_search. Requires check_in and check_out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Search query or destination city (e.g. 'hotels in Tokyo'). Required for ordinary hotel search. Radius search ignores this text in provider selection and filters by geography only. For hotel_place_id without radius_meters, the resolved property name is used for provider search and identity matching."New value: +"Search query or destination city (e.g. 'hotels in Tokyo'). Required for ordinary hotel search. Google Hotels can mix in properties from nearby towns or districts; cards outside the searched place carry outsideRequestedArea and distanceFromAreaKm, and areaNote says how many. When the user wants a specific neighbourhood, get its coordinates or center_place_id from places_search and use a radius search. Radius search ignores this text in provider selection and filters by geography only. For hotel_place_id without radius_meters, the resolved property name is used for provider search and identity matching."
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the bar is lower. The description adds non-obvious behavior beyond them: provider coverage may be incomplete, prices may change, style/text preferences are dropped inside a radius, and offer links survive only on a unique identity match.

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?

Content is front-loaded with purpose, then modes, then caveats, and no sentence is wasted. Some clauses (e.g. 'Only a unique identity match retains its offer links') are terse enough to require a second read, keeping it from a 5.

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 12-parameter read-only search with full schema coverage and annotations covering safety, the description supplies the mode semantics and limitations an agent needs. It never sketches the response shape, but with no output schema this is a minor gap rather than a blocker.

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 already 100%, so baseline is 3. The description goes further by explaining the interaction between hotel_place_id and radius_meters and how provider search and identity matching use the resolved name, adding interpretation the schema alone doesn't convey.

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?

The opening sentence gives a concrete verb+resource (search hotels/accommodations) that is clearly distinct from siblings like search_attractions, search_tours, and search_airport_lounges. It does not explicitly name or contrast those siblings, so it stops short of a 5.

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?

The description lays out the operating modes well: ordinary text-query search, dated radius search, and hotel_place_id lookups with/without radius_meters, including the caveat that the text query is ignored within a radius. It does not, however, route the agent toward or away from alternative sibling tools.

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

All Tineo toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources