1stay

Search Hotels

search_hotels

Read-only

Search hotels by location and dates for exactly one room, with check-in up to 340 days from today. Returns available properties with nightly rates across major brands, boutique, and independent hotels.

The first 1Stay release supports one room per search and reservation. Guest pays the hotel directly. Hotel's own confirmation number. Loyalty points apply.

Input Schema

TableJSON Schema

Name	Required	Description
`rooms`	No	Number of rooms. 1Stay currently supports exactly one room per search and reservation; omit this field or set it to 1.
`cursor`	No	Pagination cursor from previous search response
`radius`	No	Search radius in miles (default 25, max 100)
`check_in`	Yes	Check-in date in YYYY-MM-DD format (e.g. 2026-05-06). Must be today through 340 days from today.
`currency`	No	Currency code (default USD)
`latitude`	No	Latitude — must be provided together with longitude
`location`	No	City, address, venue, or landmark (e.g. 'Nashville, TN' or 'Times Square, NYC'). Required unless latitude and longitude are both provided.
`check_out`	Yes	Check-out date in YYYY-MM-DD format (e.g. 2026-05-07). Must be after check_in.
`longitude`	No	Longitude — must be provided together with latitude
`search_id`	No	Search ID paired with a pagination cursor from previous results
`max_results`	No	Max hotels to return, max 15 (default 4)
`guests_per_room`	No	Guests per room (default 2)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rooms`	No
`cursor`	Yes
`results`	Yes
`has_more`	Yes
`search_id`	No
`total_results`	Yes
`guests_per_room`	No
`resolution_type`	No
`resolved_location`	No
`conversion_applied`	No
`requested_currency`	No
`returned_currencies`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond annotations: nightly rates, hotel categories, one-room limitation, direct payment, and loyalty points. No contradictions.

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?

Two short paragraphs with the core function front-loaded. The second paragraph efficiently conveys key constraints, though a few points are redundant with schema descriptions.

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?

Given the rich input schema, output schema, and annotations, the description is largely complete for agent decision-making. Pagination is not explicitly explained, but cursor/search_id are schema-documented and an output schema exists.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of 'exactly one room' and '340 days' is already reflected in the schema, adding little new parameter-level meaning.

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 description opens with 'Search hotels by location and dates,' a specific verb and resource, and clarifies scope (exactly one room, 340-day window). It does not explicitly differentiate from siblings like get_hotel_details, 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?

Provides clear product context—first release supports one room per search, direct payment, hotel confirmation, loyalty points—which helps an agent understand constraints. It does not explicitly mention alternatives or when-not-to-use, so it lacks the explicit routing of a 5.

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

All 1stay tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

The tools mostly map to clear stages: search_hotels, get_hotel_details, book_hotel, cancel_booking, resend_confirmation, and search_tools are all distinct. The only close pair is get_booking and lookup_booking, but their documented distinction (token/confirmation-required details vs identity-based summary lookup) prevents actual confusion.

Naming Consistency5/5

All tools use a consistent verb_noun pattern in snake_case: search_hotels, book_hotel, cancel_booking, get_booking, lookup_booking. No mixed casing or vague names appear.

Tool Count5/5

Eight tools is well-scoped for a otel booking MCP: the functional surface covers the guest journey from search to confirmation resending, and search_tools is a useful mettool. The count is neither too thin nor bloated.

Completeness4/5

The core lifecycle is present: search, rate/details, book, lookup, view details, resend confirmation, and a cancellation handoff. Missing an explicit modify/change-booking operation and cancellation requires an external page, but these are present as product constraints rather than obvious coverage gaps.

Search Hotels

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources