Skip to main content
Glama

search_hotels

Read-only

Compare hotel cash and points rates side by side. See cents-per-point value and deal scores to recommend the best value for any location and dates.

Instructions

Search for hotels by location and dates with cash AND points pricing.

Returns hotels with side-by-side cash vs points rates, cents-per-point (CPP) valuation,
and deal scores so you can recommend the best value. This is Gondola's unique advantage —
no other travel search shows both cash and points rates together.

Args:
    location: City name, address, or area to search (e.g. "Tokyo", "Manhattan, New York", "near LAX airport").
    checkin: Check-in date in YYYY-MM-DD format (e.g. "2026-04-15").
    checkout: Check-out date in YYYY-MM-DD format (e.g. "2026-04-20").
    num_adults: Number of adult guests. Defaults to 2.
    chain_name: Optional hotel chain to filter by (e.g. "marriott", "hilton", "hyatt", "ihg").
        Case-insensitive substring match against each result's chain. If nothing matches, the
        unfiltered results are returned with an explicit note so you don't keep retrying.
    loyalty_programs: Optional list of the user's loyalty programs (e.g. ["hilton_honors", "marriott_bonvoy"]).
        When provided, results include personalized earnings and tier benefits like 5th night free.
    loyalty_points: Optional dict of program name to points balance (e.g. {"hilton_honors": 250000}).
        When provided, results indicate whether the user can afford each hotel with points.
    limit: Max number of hotels to return (default 20). The response notes how many more exist
        and how to narrow; raise this only when the user explicitly wants a longer list.

Returns:
    Formatted list of hotels with cash rates, points rates, CPP valuation, and deal recommendations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
checkinYes
checkoutYes
locationYes
chain_nameNo
num_adultsNo
loyalty_pointsNo
loyalty_programsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

The description adds behavioral context beyond annotations: it explains return format (cash vs points rates, CPP, deal scores), chain_name fallback, and limit behavior. No contradiction with readOnly/readOnly/world/destructive hints. The annotations already cover the read-only safety, so the description supplements well.

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?

The description is well-structured with an introductory paragraph and bullet-like Args section. Every sentence adds value, from the unique selling point to detailed parameter semantics. It is concise yet thorough, with no redundant information.

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?

Given 8 parameters and an existing output schema, the description covers all necessary information: parameters, return summary, edge cases, and usage guidelines. It is self-contained and leaves no ambiguity for an AI agent.

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

Parameters5/5

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

Schema description coverage is 0%, but the description's Args section provides comprehensive parameter explanations including examples, defaults, and conditional behaviors (e.g., chain_name case-insensitive match, loyalty_points affordability check). This fully compensates for the lack of schema-level 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 clearly states the tool searches hotels by location and dates with cash and points pricing, and explicitly highlights its unique advantage over other travel searches, distinguishing it from siblings like get_hotel_details or book_hotel.

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 provides detailed guidance on parameter usage, defaults, and edge cases (e.g., chain_name fallback behavior, limit usage advice). However, it lacks explicit when-to-use versus alternative tools, though the uniqueness statement partially addresses this.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gondola-ai/gondola-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server