waysway

search_hotels

Search and recommend hotels.

USE THIS TOOL FOR:
- city-based hotel search
- main search intent
- direct numeric search constraints such as price_min / price_max
- explicit room or amenity filters

IMPORTANT:
- city MUST be passed here, not inside user_profile
- user_profile is for stable preferences, not for search location
- if dates are known, call update_stay_dates first
- if profile preferences are known, call update_user_profile_from_model first

RECOMMENDED ORDER:
1. start_session
2. update_user_profile_from_model (optional)
3. update_stay_dates (optional)
4. search_hotels(city=..., ...)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`city`	Yes
`limit`	No
`suitable`	No
`amenities`	No
`price_max`	No
`price_min`	No
`room_type`	No
`rating_min`	No
`session_id`	Yes
`surroundings`	No
`main_interest`	Yes
`user_specific`	No
`non_refundable`	No
`hotel_class_stars`	No
`exclude_hotel_codes`	No
`required_name_terms`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedMay 6, 2026

addedInput schema / properties / hotel_class_stars

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        3,
+        4,
+        5
+      ],
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Hotel Class Stars"
+}

First observedApr 27, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose that the tool depends on session state and profile (via the recommended order), but it does not explicitly state whether the tool is read-only, mutates session state, or has any side effects. It also does not mention failure modes or prerequisites beyond the order. This is moderate transparency for a search-like tool.

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?

The description is well-organized with clear sections: opening purpose, 'USE THIS TOOL FOR', 'IMPORTANT', and 'RECOMMENDED ORDER'. It front-loads the core purpose. However, there is some redundancy, such as repeating the same order details in 'IMPORTANT' and 'RECOMMENDED ORDER', and 'main search intent' is vague. Overall, it is efficient and scannable.

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

Completeness2/5

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

Despite an output schema, the tool has 16 parameters, no annotations, and 0% schema description coverage. The description covers only a few key constraints (city placement, date/profile pre-setup) and does not explain the majority of parameters. It does not address how this tool relates to alternatives like search_homestays_in_city beyond the implied hotel focus. The workflow guidance is helpful but insufficient for a tool of this complexity.

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

Parameters2/5

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

The schema has 0% description coverage, so the description must compensate. It names price_min/price_max and room/amenity filters, but these are only broad hints. The remaining 13 parameters (e.g., suitable, surroundings, non_refundable, exclude_hotel_codes, required_name_terms, user_specific) are completely unexplained. The description provides little value in clarifying parameter semantics for a 16-parameter tool.

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 opens with 'Search and recommend hotels' which clearly states the verb and resource. It further specifies 'city-based hotel search' and 'main search intent', distinguishing it from sibling tools like search_homestays_in_city, search_restaurants_near_hotel, and search_activities_in_city. The resource (hotels) 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 Guidelines5/5

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

The 'USE THIS TOOL FOR' bullet list explicitly states when to use this tool. The 'IMPORTANT' section provides clear exclusions, such as 'city MUST be passed here, not inside user_profile' and 'user_profile is for stable preferences, not for search location'. The 'RECOMMENDED ORDER' gives step-by-step prerequisites, including calling update_stay_dates and update_user_profile_from_model first, which tells the agent when to use this tool relative to others.

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

All waysway 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

B3.4/5.0

Disambiguation4/5

Most tools have clear distinct purposes, though 'update_user_profile' and 'update_user_profile_from_model' serve similar functions with different input methods, which could cause confusion. Overall, the boundaries are generally clear.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as 'search_hotels', 'update_stay_dates', and 'get_hotel_details'. No naming style mixing or irregularities.

Tool Count5/5

With 20 tools covering hotels, homestays, flights, activities, restaurants, profile management, and session handling, the count is well-scoped for a travel assistant server. Each tool serves a distinct function without bloat.

Completeness4/5

The tool set covers core travel planning needs: search, details, offers, and profile management. However, it lacks a tool to actually confirm or book an offer, which is a noticeable gap for a complete booking flow.

Resources

Need Help?