Loading ToolBench
An MCP server that allows LLMs to search for hotels and destinations using the Booking.com API
This server has two tools with basic definitions, but significant quality gaps prevent a higher score. Both tools have descriptions and some parameters documented, but critical deficiencies in schema completeness, error handling clarity, and output structure documentation pull the score down. Tool naming follows verb_noun convention appropriately (search_destinations, get_hotels), but parameter descriptions lack precision about formats and constraints. No input validation documentation, no explicit output schema definition, and error handling is generic rather than actionable. The server scores at the boundary between 'poor' (50-59) and 'fair' (60-69), staying conservative due to missing schemas and weak error guidance.
Get hotels for a specific destination.
Search for hotel destinations by name.
No documented output schema for either tool. Tools return free-form formatted strings rather than structured objects with typed fields. This requires LLMs to parse unstructured text, wastes tokens, and prevents downstream tool composition.
get_hotels parameter 'adults' has a default of 2, but the description mentions 'default: 2' inline. No minimum/maximum bounds specified for this numeric parameter. LLMs could pass invalid values (0, -1, 1000+) with no validation guidance.
Date format parameters ('checkin_date', 'checkout_date') documented as 'YYYY-MM-DD format' in description text, but not enforced via schema. No validation error guidance if LLM passes wrong format (e.g., 'Jan 15, 2024'). Should use JSON Schema pattern constraint.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Error responses return generic strings: 'Error fetching destinations: {error}' and 'Error fetching hotels: {error}'. These do not tell the LLM what to do next, whether the error is retryable, or how to recover. No error classification or recovery guidance present.
API key (RAPIDAPI_KEY) is injected via environment variable, which is correct. However, no documentation in tool definitions clarifies that this secret is server-managed and not exposed to callers. Tool descriptions should mention secure credential handling for transparency.
get_hotels returns up to 10 hotels (hardcoded limit in code: 'hotels[:10]'). No pagination parameters (page, limit, offset, next_cursor) exposed to the LLM. Tool description does not mention the 10-item limit, so LLM may expect more results than it receives.
Tool descriptions mention what they do but lack guidance on WHEN to use them or dependencies between tools. No note that search_destinations must be called first to obtain destination_id for get_hotels.