Loading ToolBench
TripAdvisor MCP Server for searching locations, getting nearby places, and planning vacations using TripAdvisor data
The TripAdvisor MCP server has 4 tools with visible definitions in server.py. All tools have descriptions and input schemas with type information. However, the descriptions lack depth and actionable context for LLM selection. Parameter descriptions are present but minimal. Output schemas are not explicitly documented. Error handling is weak, API errors return raw JSON without recovery guidance. The plan_vacation tool has an empty input schema and does not compose with other tools in a meaningful way. Overall, the server meets basic definition standards but falls short of production-grade quality. Per-tool averages range from 48 (plan_vacation) to 62 (search_locations).
Get essential details about a location by ID for trip planning Args: location_id: TripAdvisor location ID
Find locations near a specific latitude and longitude Args: latitude: Latitude coordinate longitude: Longitude coordinate category: Optional category filter (e.g., "hotels", "restaurants", "attractions")
Initiates the vacation planning process using the structured prompt. This should be used whenever a user wants to plan a trip or vacation. Returns: A message confirming the vacation planning process has started
Search for locations on TripAdvisor Args: query: Search term (e.g., "hotels in Paris") category: Optional category filter (e.g., "hotels", "restaurants", "attractions")
plan_vacation has empty input schema ({}). Tool does not validate composition with search/location tools.
Tool names lack clarity on parameter requirements. get_location_details_tool uses 'tool' suffix which is non-standard. Should be get_location_details.
Descriptions under 100 characters with no recovery guidance. E.g., search_locations lacks: when to use vs get_nearby_locations, what fields are returned, how to extract location_id for chaining to get_location_details.
Output schemas not documented. tripadvisor_api_request returns raw JSON (response.json()). No type hints on what fields search_locations, get_location_details_tool, or get_nearby_locations return. LLM cannot plan downstream calls without knowing result structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Error handling does not guide recovery. tripadvisor_api_request returns {'error': 'HTTP error occurred: ...'} with no actionable next step. Per pattern, errors should state 'User not found. Try search_users() first', not just the error code.
plan_vacation is not composable with the query tools. It returns a static message and initiates a prompt, but does not accept a destination, duration, or priority from the user as parameters. It should accept required parameters to tie into the vacation planning workflow.
API key is injected via environment variable but not validated at tool invocation. If TRIPADVISOR_API_KEY is missing, tools return {'error': 'API key not configured'} after making the call. Should validate at server startup.
Result limits not enforced or documented in tool descriptions. Resources cap at 10 results (['data'][:10]), but tools do not mention this limit. Per mxe baseline, limits should be explicit in descriptions so LLM knows when to paginate.