A multi-service travel planning MCP server that provides flight search, hotel booking, weather forecasts, tourism recommendations, and utility tools for travel planning via FastMCP
This server exhibits significant quality gaps across naming, description clarity, and schema completeness. While 21 tools are defined with some structure, most lack the rigor expected of production tools. Math utilities (add, subtract, multiply, etc.) are generic and add noise to a travel-focused MCP. Critical travel tools like search_flights and search_hotels have sparse parameter descriptions. Parameter validation guidance is minimal. Output schemas are not documented. Error handling strategies are absent. The server reads as a proof-of-concept rather than a hardened tool suite.
Return the sum of two numbers.
Builds a travel itinerary for a given destination, duration, and budget using all MCP tools.
Calculates the approximate distance between two cities in kilometers.
Convert temperature from Fahrenheit to Celsius.
Converts a time from one timezone to another.
Convert between distance, temperature (C/F), and weight units.
Return the quotient of two numbers.
Estimate total trip cost using MCP tools to fetch real hotel data, weather (optional context), and tourism spots (optional context).
Math utilities (add, subtract, multiply, divide, power, modulus, root) are generic number operations unrelated to travel planning. They pollute the tool namespace, increase agent reasoning overhead, and dilute the MCP's domain focus. A travel assistant needs travel-specific tools, not a calculator library.
Parameter descriptions are minimal. 'Origin location', 'Destination location', 'Departure date' lack guidance on format, constraints, or examples. LLMs cannot infer whether 'origin' expects 'LAX', 'Los Angeles', 'Los Angeles International', or IATA codes. No format hints prevent invalid input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Converts an amount from one currency to another.
Get the cheapest flight between two locations using the Amadeus Cheapest Flight API.
Returns the difference between two times in hours.
Returns the current local time in a city.
Get weather forecast for a location.
Return the modulus of two numbers.
Return the product of two numbers.
Return the base raised to the exponent power.
Return the nth root of a number.
Search for flights using the Amadeus Flight Offers API.
Search for hotels using the Booking.com API and return a recommendation of hotels for a specific location.
Search for top tourism destinations using the Foursquare Places API and return recommendations.
Return the difference of two numbers.
No output schemas are documented. Tools return data but the shape, fields, and structure are not specified. LLMs cannot plan downstream tool calls or extract chaining IDs (e.g. hotel_id, flight_id) without documented response fields. This breaks tool composition.
search_hotels parameter list is verbose (14 params) with many defaults. Parameters like 'children_ages' have cryptic defaults ('5,0' instead of empty/null). No validation guidance on what happens if invalid dates, negative counts, or out-of-range page_num are passed. This invites hallucinated inputs from LLMs.
No error handling guidance. Tools do not document failure modes, recovery strategies, or actionable error messages. When search_flights fails due to invalid airport code, the tool returns nothing to guide the agent. No pattern for 'retryable vs fatal' classification.
Tool naming lacks verb-noun consistency. 'convert_fahrenheit_to_celsius', 'exchange_currency', and 'convert_timezone' use verb-object patterns that are clear, but 'build_itinerary' and 'estimate_trip_cost' use generic 'build' and 'estimate' that do not distinguish them from similar tools. 'build' is particularly vague, does it also search, book, or just organize?
API credentials (AMADEUS_API_KEY, AMADEUS_API_SECRET, RAPID_API_KEY) are loaded in flights_mcp.py and potentially exposed if parameters or responses leak them. No evidence of server-side secret injection isolation. If an agent traces or logs this module's execution, credentials risk exposure.
Multi-purpose tools 'build_itinerary' and 'estimate_trip_cost' combine multiple responsibilities: searching flights, hotels, tourism spots, and calculating costs. These should be split into narrower tools so agents can compose them independently. A user may want flight + hotel without itinerary building.
No pagination or result limiting documented. search_hotels, search_flights, and search_tourism_destinations may return large result sets that explode token usage. No mention of limit params (other than page_num in search_hotels) or capping strategies. LLM context window exhaustion risk.