Loading ToolBench
MCP server for travel data - flights, hotels, weather with MongoDB caching
The Travel MCP Server defines 3 tools with reasonable structure but has notable gaps in parameter documentation and output schemas. All tools have proper names starting with action verbs (get_), descriptions are present and moderately detailed (80-160 chars each), and input schemas are well-formed with type definitions. However, parameter descriptions are inconsistent in detail and precision. The server lacks documented output schemas, error handling guidance, and pagination support for potentially large result sets. No security annotations or permission gates are evident. Database caching is mentioned but integration details are opaque to the LLM.
Search for real-time flight information including prices, times, and availability
Search for hotel availability, prices, ratings, and reviews from Booking.com
Get weather forecasts for travel planning including temperature, precipitation, and conditions
Output schemas are not documented. Tools return TextContent via call_tool() but the structure of flight, hotel, and weather data is not declared. LLMs cannot plan downstream chains without knowing what fields are available.
No pagination support declared. get_latest_flight_data and get_latest_hotel_data accept max_results but do not specify whether pagination/cursors are supported. Large result sets could exhaust context window.
Parameter descriptions lack constraint details. E.g., date format is stated as 'YYYY-MM-DD' but no validation bounds or timezone behavior are documented. max_results defaults to 10 but no minimum/maximum bounds are specified.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Error handling in call_tool() is generic. All exceptions return 'Error: {str(e)}', no recovery guidance, retryability classification, or actionable next steps. LLMs cannot decide whether to retry or escalate.
No tool annotations (readOnlyHint, idempotentHint). All three tools are read-only but this is not declared in the tool schema, preventing clients from applying optimizations or caching strategies.
date parameter is listed as optional in get_latest_flight_data but the handler code (line: 'date = args.get("date", default_date())') silently applies a 7-day-forward default when omitted. This behavior is not documented in the schema, risking unexpected results.
get_latest_hotel_data requires 'city' but check_in_date and check_out_date are optional, yet the handler likely needs both for a meaningful search. The schema does not clarify the dependency or consequences of omitting them.
Sample data fallback is used when live APIs fail (referenced in docstring but not fully visible in excerpt), but this fallback behavior is not documented to the LLM. The LLM may believe it always receives live data.