Loading ToolBench
Global hotel search and booking MCP server providing worldwide hotel search, detailed pricing, and tag-based filtering capabilities.
The server provides three well-named, domain-specific tools with comprehensive parameter documentation and clear descriptions. All tools follow the verb_noun naming convention (search, get). Parameter schemas are well-structured with Pydantic models and include type definitions, defaults, and descriptions. However, output schemas are not explicitly documented in the tool definitions, only implied through the API client calls. Error handling exists but lacks structured recovery guidance. Tool compositions are appropriate and follow a logical workflow (search → detail → tags), though field chaining could be optimized.
Query real-time room types and pricing for a single hotel (room types, price and tax, availability, cancellation policy, etc.). Used for a second price check after the user has selected a specific hotel.
Retrieve hotel search tag metadata (AI cache), including the list of available tags. Suitable for local caching followed by user-intent parsing, then passing the structured tags into `searchHotels.hotelTags`.
Search hotels worldwide. Returns a candidate hotel list with the lowest price for each, based on the location and structured filters (dates, nights, guests, star rating, distance, tags, brands, budget). Used for initial hotel screening and comparison.
Output schemas not documented in tool definitions. Tool descriptions explain what is returned informally ('room types, price and tax, availability, cancellation policy'), but no structured schema is provided for LLM consumption. LLMs cannot plan downstream calls or extract fields without explicit output schemas.
getHotelSearchTags has a vague description ('Retrieve hotel search tag metadata (AI cache)'). It lacks clear guidance on WHEN to call this tool, what tags are available, or how the results should be used downstream. The description does not answer: What are these tags? When should I call this vs. just passing tags directly to searchHotels?
Error handling in client.py (request_api) logs upstream errors server-side but raises generic 'HTTP request failed (status X)' exceptions. These give the LLM no actionable recovery guidance (retry? upstream API is down? invalid credentials?). Missing error classification and recovery hints per pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
Parameter occupancyParam.childAgeDetails in getHotelDetail lacks clear validation constraint description. The annotation says 'e.g. [3,5]; length should match childCount' but does not state the valid age range or what happens if the array length does not match. LLM cannot validate before calling.
searchHotels.filterOptions.distanceInMeter description states 'Defaults to 2000 when a POI is used' but this is conditional logic not enforced by the schema. If place is a city, is distanceInMeter ignored? This undocumented dependency could cause misuse.
searchHotels returns 'a candidate hotel list' but size parameter caps at 20. No mention of whether results are ranked, paginated, or if there's a next_cursor for continuation. Without pagination metadata, agents cannot reliably fetch more results.