MCP server giving Claude live access to Google Flights and Google Hotels — search trips and compare dates in plain English
Trip-search-mcp has 11 well-named tools with consistent verb_noun patterns (search_*, get_*, watch_*, list_*, cancel_*). All tools have descriptions (avg ~150 chars, within 10-1024 baseline). Input schemas are present and typed for all tools. However, output schemas are NOT documented, the server returns results but does not specify the structure of flight objects, stay details, activity cards, etc. This forces LLMs to infer response structure. Parameter descriptions are present but some lack format/constraint details (e.g., 'cabin_class' lists enum values in description but not as formal enum constraint). Error handling is minimal, no recovery guidance or categorization. The server_instructions block is a positive signal for behavioral guidance, but tool-level error responses are not visible in the code sample.
Cancel an active flight price watch by its watch ID.
Convert an amount from one currency to another using current exchange rates.
Retrieve detailed information about a specific accommodation property, including booking partner links, reviews, amenities, and nearby places.
Get weather forecast for a location up to 7 days in advance, including temperature, precipitation, and conditions.
List all active flight price watches with their current status and latest price information.
Search for things to do and bookable activities at a destination, including tours, attractions, and experiences.
Output schemas not documented. Tools return flight objects, stay details, activity cards, etc., but the response structure is not specified in tool definitions. LLMs cannot plan downstream calls or extract fields reliably.
Enum constraints not formalized in schema. Parameters like 'cabin_class' (ECONOMY, PREMIUM_ECONOMY, BUSINESS, FIRST) and 'category' (all, hotels, vacation_rentals, airbnb) list values in descriptions but lack formal enum constraints in JSON Schema. LLMs may hallucinate invalid values.
Error handling and recovery guidance absent. No visible error responses, categorization (retryable vs fatal), or actionable recovery hints. If a flight search fails or an API key is missing, the LLM has no guidance on next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | <=2025-11-25 | v2 |
Find the cheapest dates to fly within a date range. Searches across a range of departure dates and optionally return dates to identify the lowest-priced options.
Search for time-bound events such as concerts, festivals, and shows at a destination within a date range.
Search for flights with flexible parameters including origin, destination, dates, passengers, cabin class, stops, and airlines. Returns a list of flight options with prices and details.
Search for accommodations including hotels, vacation rentals, and Airbnb listings. Supports filtering by category, location, check-in/check-out dates, and guest count.
Set up a persistent price watch for a specific flight route and date combination. Returns a watch ID for tracking.
Destructive operations (watch_flight_price, cancel_watch) lack confirmation or dry-run support. Agents can set or cancel price watches without a confirmation step, risking unintended state changes.
Parameter format constraints underspecified. Date parameters (departure_date, check_in_date, etc.) state 'YYYY-MM-DD format' in descriptions but lack formal pattern constraints in schema. Numeric ranges (days 1-7, max_results) lack min/max bounds in schema.