Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@travel-mcp-server plan a trip to Tokyo for 5 days under $1500"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An AI-powered travel planner built as a Model Context Protocol (MCP) server. Connect it to Claude and get a full travel assistant — search flights, hotels, weather, and points of interest, generate day-by-day itineraries, and track your trip budget.
A Next.js web UI is included for exploring the tools directly in a browser without a Claude client.
Tool | Description |
| Search flights between two cities by name or IATA code |
| Search hotels with optional price filter |
| Day-by-day weather forecast for a destination |
| Points of interest by category (restaurants, attractions, activities, nightlife, shopping, transport) |
| Generate a complete itinerary with weather, POI, flight & hotel options, and optional budget allocation |
| Create a budget tracker for a trip |
| Record an expense against a budget category |
| Total spent, remaining balance, and per-category breakdown |
Flights: New York ↔ Tokyo / Paris / London / Barcelona / Sydney / Bali · London ↔ Paris / Barcelona / Bali · Sydney ↔ Bali · Paris ↔ Rome
Hotels, weather & POI: Tokyo, Paris, London, Barcelona, Bali, Sydney, Rome, Amsterdam, Dubai
Related MCP server: Triplus MCP Server
Python 3.10+, uv — brew install uv
Node.js 18+ and pnpm (for the web UI) — brew install pnpm
git clone <repo-url> travel-mcp-server
cd travel-mcp-server
uv sync
uv run python -m travel_mcp# Terminal 1 — MCP server in SSE mode
MCP_TRANSPORT=sse uv run python -m travel_mcp
# Terminal 2 — Next.js UI
cd ui && pnpm install && pnpm devOpen http://localhost:3000 to use the browser playground.
npx @modelcontextprotocol/inspector uv run python -m travel_mcpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"travel-planner": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/travel-mcp-server", "python", "-m", "travel_mcp"]
}
}
}Restart Claude Desktop. The 8 travel tools will appear automatically.
# Build
docker build -t travel-mcp-server .
# Run (SSE transport on port 8000)
docker compose upThe server listens on http://localhost:8000 in SSE mode when running via Docker.
The web UI can be pointed at a remote server by setting MCP_SERVER_URL before starting it:
MCP_SERVER_URL=http://your-server:8000 pnpm --prefix ui dev# Deploy
kubectl apply -f k8s/
# Verify
kubectl rollout status deployment/travel-mcp-server -n travel-mcp
# Test locally via port-forward
kubectl port-forward svc/travel-mcp-server 8000:80 -n travel-mcp
# Tear down
kubectl delete -f k8s/Note: The Deployment runs a single replica because budget state is held in memory. Scale to multiple replicas only after adding external storage (Redis, Postgres, etc.).
A Next.js 16 app in ui/ that provides a browser-based playground for all 8 tools. It requires the MCP server to be running in SSE mode (MCP_TRANSPORT=sse).
ui/
├── app/
│ ├── page.tsx # Tabbed playground (Flights, Hotels, Weather, Places, Itinerary, Budget)
│ └── api/tools/[tool]/ # Next.js API route — proxies to MCP server REST endpoints
├── components/ # One component per tool tab + shared UI primitives
└── lib/mcp.ts # Thin fetch wrapper for /api/tools/*The MCP server exposes REST endpoints at /api/tools/<tool_name> (POST, JSON body) alongside the standard SSE transport, so the UI does not need to implement the MCP protocol.
Variable | Default | Description |
|
| Transport mode: |
|
| Bind address (SSE mode only) |
|
| Port (SSE mode only) |
|
| URL the Next.js UI uses to reach the MCP server |
travel-mcp-server/
├── src/travel_mcp/
│ ├── server.py # FastMCP instance, tool registrations, REST API routes
│ ├── tools/ # Business logic (one file per domain)
│ │ ├── flights.py
│ │ ├── hotels.py
│ │ ├── weather.py
│ │ ├── poi.py
│ │ ├── itinerary.py # Composes other tools into a full itinerary
│ │ └── budget.py # In-memory budget tracker
│ └── mock_data/ # Static fixtures — replace query_* functions to wire real APIs
│ ├── flights.py
│ ├── hotels.py
│ ├── weather.py
│ └── poi.py
├── ui/ # Next.js web UI
│ ├── app/ # App Router pages and API routes
│ ├── components/ # Tool tab components
│ └── lib/mcp.ts # MCP server fetch client
├── k8s/ # Kubernetes manifests
├── Dockerfile
└── docker-compose.ymlEach mock_data/ file exposes a single query_* function. Replace just that function with an HTTP call to a real provider and everything else stays the same.
Mock file | Suggested real API |
| |
| |
| |
|
"Plan a 7-day trip to Tokyo from New York in October with a $4,000 budget."
"Find me flights from London to Barcelona for next Friday, 2 passengers."
"What's the weather like in Bali in July?"
"Show me the top attractions in Rome."
"I spent $850 on flights for my Tokyo trip — log it and show my remaining budget."
MIT
Record an expense against a trip budget.
Args: trip_id: The trip identifier used when creating the budget category: Expense category — flights, hotels, food, activities, transport, shopping, or misc amount: Amount spent description: Brief description of the expense (e.g. "ANA flight JFK→NRT")
| Name | Required | Description | Default |
|---|---|---|---|
| trip_id | Yes | ||
| category | Yes | ||
| amount | Yes | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Record an expense', implying mutation, but does not disclose behavior on missing trip_id, error handling, idempotency, or return value. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: a one-line header followed by bullet-pointed args. No redundant words, front-loaded, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required params, no output schema, and no annotations, the description explains parameters adequately but lacks behavioral context (side effects, what happens on failure, success response). There are gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning to all parameters: trip_id (identifier), category (enum list), amount (spent), description (brief with example). It adds value beyond the schema, but could be more detailed (e.g., unit, constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Record an expense against a trip budget', using a specific verb and resource. It distinguishes from siblings like 'create_trip_budget' (which creates the budget) and 'get_budget_summary' (which retrieves summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites (e.g., budget must exist) or exclusions. Usage is implied from context but not provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a budget tracker for a trip.
Args: trip_id: Unique identifier for the trip (e.g. "tokyo-oct-2024") total_budget: Total budget amount currency: Currency code (default: "USD")
| Name | Required | Description | Default |
|---|---|---|---|
| trip_id | Yes | ||
| total_budget | Yes | ||
| currency | No | USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action (create) without revealing side effects (e.g., overwrites existing budget), error handling for invalid trip_id, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and uses a clear bulleted Args list. No wasted words, but it could be slightly more structured (e.g., a brief note on behavior). It is efficient for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 3 parameters and no output schema or annotations, the description covers purpose and parameter meanings but omits return value, idempotency, and error scenarios. It is minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining trip_id as 'Unique identifier for the trip' with an example, total_budget as 'Total budget amount,' and currency as 'Currency code' with default. It provides adequate context beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a budget tracker for a trip,' using a specific verb and resource. It distinguishes from siblings like add_expense (adds an expense) and get_budget_summary (reads a summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to set an initial budget for a trip but lacks explicit guidance on when to use it versus alternatives, prerequisites (e.g., trip must exist), or whether it overwrites existing budgets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full budget summary: total spent, remaining balance, and per-category breakdown.
Args: trip_id: The trip identifier used when creating the budget
| Name | Required | Description | Default |
|---|---|---|---|
| trip_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It does not explicitly state that the operation is read-only or non-destructive, nor does it mention any side effects, authorization requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus an Args section. Every sentence is necessary and there is no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a high-level summary of return values but does not mention what happens if the trip_id is invalid or not found. Given no output schema, more context on error handling would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the trip_id parameter by noting it is 'The trip identifier used when creating the budget', which goes beyond the schema's title-only field. The schema coverage is 0%, so this additional context is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a full budget summary with total spent, remaining balance, and per-category breakdown. It distinguishes from sibling tools like add_expense and create_trip_budget by being a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_weather or search_hotels. There is no mention of context where this tool is appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get day-by-day weather forecast for a destination over a date range.
Args: destination: City name (e.g. "Tokyo", "Bali", "Sydney") date_from: Start date in YYYY-MM-DD format date_to: End date in YYYY-MM-DD format
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | ||
| date_from | Yes | ||
| date_to | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'day-by-day' forecast, indicating granularity, but does not disclose limitations like maximum date range, data sources, update frequency, or output format. Without annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief introductory sentence followed by a clear Args section. Every sentence adds value, with no fluff or repetition. It is well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description covers basic input guidance but does not explain the return value structure (e.g., daily forecasts with details). Additional context like unit system or location validation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have no schema descriptions (0% coverage). The description compensates by providing examples for destination (e.g., 'Tokyo') and specifying date format (YYYY-MM-DD) for both date_from and date_to. However, it does not mention any constraints like valid date ranges or supported cities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get day-by-day weather forecast for a destination over a date range.' It uses a specific verb 'Get' and clearly identifies the resource (weather forecast) and scope (destination, date range). It is distinct from sibling tools like search_flights or search_hotels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for weather forecasts but does not explicitly state when to use this tool versus alternatives. No when-not or alternative tool references are provided, but the purpose is clear enough from the context of sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete day-by-day travel itinerary combining weather, attractions, dining, and travel options.
Args: destination: Travel destination city (e.g. "Tokyo", "Paris") start_date: Trip start date in YYYY-MM-DD format end_date: Trip end date in YYYY-MM-DD format origin: Departure city for flight search (e.g. "New York", "London") total_budget: Total trip budget in USD — enables budget planning and suggested allocation (optional) preferences: Comma-separated interests to tailor the itinerary (e.g. "food, history, beaches")
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | ||
| start_date | Yes | ||
| end_date | Yes | ||
| origin | Yes | ||
| total_budget | No | ||
| preferences | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It describes the tool's function but does not disclose side effects, dependencies, or whether it is read-only. Lacks details on performance or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by a clear Args list. Each sentence adds value, though the Args section is moderately detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers purpose and parameters well. However, it does not describe the output format or any limitations, leaving some gaps about what the agent can expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section explains each parameter with format and examples. Adds significant meaning beyond the schema, especially for optional parameters like total_budget and preferences.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a complete day-by-day travel itinerary combining weather, attractions, dining, and travel options. It uses specific verbs ('generate') and resource ('itinerary'), distinguishing it from sibling tools like get_weather or search_flights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comprehensive trip planning but does not explicitly state when to use this tool versus individual search tools (e.g., search_flights). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available flights between two cities.
Args: origin: Departure city name or airport code (e.g. "New York" or "JFK") destination: Arrival city name or airport code (e.g. "Tokyo" or "NRT") departure_date: Departure date in YYYY-MM-DD format return_date: Return date for round trips in YYYY-MM-DD format (omit for one-way) passengers: Number of passengers (default: 1)
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | ||
| destination | Yes | ||
| departure_date | Yes | ||
| return_date | No | ||
| passengers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It indicates 'Search' implying read-only, but does not disclose other behaviors like rate limits, authentication, pagination, or sorting. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Brief and structured with a main sentence and clear parameter descriptions. No unnecessary information; every line adds value. Front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks any description of the output or return value. Since no output schema exists, the agent has no idea what the response contains (e.g., flight details, pricing). Incomplete for a search tool with siblings that may have similar outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial context: examples for origin/destination, date format YYYY-MM-DD, default passengers=1, and conditional return_date. This significantly compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for available flights between two cities.' It specifies the verb (search), resource (flights), and scope (origin and destination), which distinguishes it from sibling tools like search_hotels or search_poi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., plan_trip, search_hotels). It does not mention prerequisites or exclusion criteria, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available hotels in a destination.
Args: destination: City name (e.g. "Tokyo", "Paris", "London") check_in: Check-in date in YYYY-MM-DD format check_out: Check-out date in YYYY-MM-DD format guests: Number of guests (default: 1) max_price: Maximum price per night in USD (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | ||
| check_in | Yes | ||
| check_out | Yes | ||
| guests | No | ||
| max_price | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes parameters and that it searches for hotels, but does not mention output format, error handling, or whether it is read-only. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-sentence purpose followed by structured parameter details. No wasted words, each line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters well but lacks any information about the output (e.g., what information is returned per hotel, whether results are a list). Since there is no output schema, this omission is a gap for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully explains parameters: destination (city name with examples), dates (YYYY-MM-DD), guests (default 1), max_price (optional, max per night USD). Adds significant meaning beyond the schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for available hotels in a destination.' The verb 'search' and resource 'hotels' are specific, and it distinguishes from siblings like search_flights (flights) and search_poi (points of interest).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description, but there is no explicit guidance on when to use this vs. alternatives like search_flights or plan_trip. No when-not or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for points of interest in a destination.
Args: destination: City name (e.g. "Tokyo", "Barcelona", "Rome") category: Type of place — restaurants, attractions, activities, nightlife, shopping, or transport limit: Maximum number of results to return (default: 5)
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | ||
| category | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, rate limits, pagination behavior, or authentication requirements. Only basic operation is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with an Args block. Every sentence adds value, no fluff. Appropriate length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential information for a 3-param tool without output schema or annotations. Could mention return format but not required. Complete enough for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the schema: destination with city examples, category with enumerated examples, limit with default. Schema coverage is 0%, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action (Search) and resource (points of interest) with destination scope. Easily distinguishable from sibling tools like search_flights and search_hotels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context via Args section with examples and default values. Does not explicitly state when to use vs alternatives, but the function is straightforward and the description implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_expensecreate_trip_budgetget_budget_summaryget_weatherplan_tripsearch_flightssearch_hotelssearch_poiScored across 8 tools
Each tool has a clearly distinct purpose: budgeting (add_expense, create_trip_budget, get_budget_summary), weather, itinerary planning, flight search, hotel search, and POI search. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_expense, create_trip_budget, search_flights). No mixing of conventions.
8 tools cover the essential travel planning domains (budget, weather, itinerary, flights, hotels, POI) without being excessive or sparse. Well-scoped for a focused travel assistant.
Covers core travel planning workflows, but minor gaps exist: no budget update/delete, no transportation other than flights, and no tool to modify generated itineraries. Still fairly complete.
Flight search MCP server providing search, pagination, and itinerary details for AI assistants.
AI marketplace — flights, tours, activities, transport & more via MCP. No auth required.
Skiplagged MCP Server for flight search, hotel booking, and travel planning
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
