Loading ToolBench
Google Hotels MCP server and Python library — reverse-engineered batchexecute client with FastMCP tools
Three well-named tools with comprehensive parameter schemas and detailed descriptions. search_hotels and search_hotels_with_details have excellent LLM-optimized descriptions (200+ chars) with clear usage guidance and filter trigger examples. All parameters include type definitions and descriptions. However, output schemas are not documented in the visible code, only input schemas are defined. Tool descriptions exceed the 1024-char guideline (search_hotels description is ~450 chars, acceptable; but guidance text is verbose). Error handling and recovery paths are not visible in the provided source. No tool annotations (readOnlyHint) despite all three being read-only operations.
Deep detail for ONE hotel. Requires entity_key from search_hotels. Returns rooms, per-OTA rate plans with prices, and cancellation policies. One RPC. For multi-hotel deep comparison use search_hotels_with_details instead.
Fast list-view hotel search. USE THIS FIRST to discover hotels. Returns name, price, rating, star class, amenities, check-in/out times, and an entity_key for each hotel. Prefer this over search_hotels_with_details unless the user explicitly asks for room/rate/cancellation detail. One RPC. entity_key values here are inputs to get_hotel_details. Common filter triggers: - 'free cancellation' / 'refundable' → free_cancellation=True - 'budget' / 'cheap' → sort_by='LOWEST_PRICE' or price_max=N - 'luxury' / '5-star' → hotel_class=[5] - 'family' / 'kid-friendly' → amenities=['KID_FRIENDLY'] - 'pet-friendly' / 'dogs allowed' → amenities=['PET_FRIENDLY'] - 'pool' → amenities=['POOL'] or ['INDOOR_POOL'] or ['OUTDOOR_POOL'] - 'wheelchair' / 'accessible' → amenities=['WHEELCHAIR_ACCESSIBLE'] - 'eco' / 'sustainable' → eco_certified=True
Search + parallel detail-fetch for top N hotels in one call. Combines search_hotels + get_hotel_details for the top-N results. Returns full room/rate/cancellation detail for each hotel. Slower than search_hotels alone but useful for multi-hotel comparison when the user explicitly asks for detailed information. Hard cap on max_hotels to prevent runaway parallelism.
Output schemas not documented. Tool descriptions explain inputs but do not specify what fields are returned (e.g., does search_hotels return price, rating, amenities for each hotel?). LLMs cannot plan downstream calls or extract data without knowing response structure.
Tool annotations missing. All three tools are read-only (Risk: READ_ONLY noted in metadata), but readOnlyHint is not applied in the tool definitions. This prevents clients from optimizing caching and retry logic.
Error handling and recovery guidance not visible. No evidence of error categorization (retryable vs. user-fixable vs. fatal) or actionable error messages. E.g., if a hotel entity_key is invalid, what should the LLM do?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Parameter descriptions include example values (e.g., 'e.g. WIFI, POOL, GYM'). LLMs tend to reuse examples literally. Use enum constraints instead.
Pagination not visible. search_hotels accepts max_results (1-25) but no offset/cursor or total_count. Large result sets may be truncated silently without the LLM knowing.