Flight + Stay Search MCP
Click on "Install 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., "@Flight + Stay Search MCPfind flights from NYC to Paris for 2 adults in business class next week"
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.
Flight + Stay Search MCP (TypeScript)
A TypeScript implementation of a flight & Stay search MCP server that uses the Duffel API to search for flights. This MCP server provides tools to search for one-way, round-trip, and multi-city flights.
Features
Search for one-way, round-trip, and multi-city flights
Get detailed information about specific flight offers
Specify cabin class, number of passengers, and connection preferences
Filter by departure and arrival time windows
Search for travel stays (hotels/accommodations)
Get guest reviews for a specific stay/hotel
Related MCP server: Find Flights MCP Server
Setup
Install dependencies:
npm installBuild the project:
npm run buildStart the server:
npm start
Environment Variables
Create a .env file with:
DUFFEL_API_KEY=your_duffel_api_keyYou can start with a test API key (duffel_test) to try the functionality.
Using with Smithery
To publish this MCP to Smithery:
npx @smithery/cli publishTo run the published MCP:
npx @smithery/cli run @your-username/flights-mcp-ts --config "{\"duffelApiKey\":\"your_duffel_api_key\"}"Available Tools
This MCP provides the following tools:
search_flights- Search for one-way, round-trip, or multi-city flightsget_offer_details- Get detailed information about a specific flight offersearch_multi_city- A specialized tool for multi-city flight searchessearch_stays- Search for travel stays (hotels/accommodations)get_stay_reviews- Get guest reviews for a specific stay/hotel
Example Queries
"Find flights from SFO to NYC on May 15, 2025"
"Search for a round-trip flight from LAX to LHR departing June 10 and returning June 20"
"Find business class flights from Tokyo to Paris for 2 adults"
"Get details for flight offer [offer_id]"
"Find hotels in London for 2 guests from 2025-06-10 to 2025-06-12"
"Get reviews for stay [hotel_id]"
Stays/Hotel Search and Reviews
1. Search for Stays (search_stays)
Parameters:
location(string): City, airport code, or area to search for stayscheck_in_date(string): Check-in date (YYYY-MM-DD)check_out_date(string): Check-out date (YYYY-MM-DD)guests(number): Number of guestsrooms(number, optional): Number of roomsradius_km(number, optional): Search radius in kilometers
Example Request:
{
"location": "London",
"check_in_date": "2025-06-10",
"check_out_date": "2025-06-12",
"guests": 2
}Example Response:
{
"offers": [
{
"offer_id": "off_123",
"hotel_id": "acc_0000AWr2VsUNIF1Vl91xg0",
"hotel_name": "The Grand Hotel",
"address": "1 Main St, London",
"price": { "amount": "350.00", "currency": "GBP" },
"room_type": "Deluxe Suite",
"cancellation_policy": "Free cancellation until 24h before check-in"
}
]
}Note: Use the hotel_id from the search results as the stay_id for reviews.
2. Get Stay Reviews (get_stay_reviews)
Parameters:
stay_id(string): The unique Duffel stay/hotel ID (from the search_stays result)after(string, optional): Pagination cursor (after)before(string, optional): Pagination cursor (before)limit(number, optional): Max reviews to return (1-200)
Example Request:
{
"stay_id": "acc_0000AWr2VsUNIF1Vl91xg0"
}Example Response:
{
"meta": { "limit": 50, "after": "..." },
"reviews": [
{
"text": "Excellent facilities. Polite staff.\nAir conditioning could use some maintenance.\n",
"score": 8.4,
"reviewer_name": "Bessie Coleman",
"created_at": "2025-01-01"
}
]
}Local Development
For development with automatic reloading:
npm run devLicense
MIT
Available Tools
5 toolsget_offer_detailsD
| Name | Required | Description | Default |
|---|---|---|---|
| offerId | Yes | Unique identifier for the flight offer |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stay_reviewsD
| Name | Required | Description | Default |
|---|---|---|---|
| stay_id | Yes | Duffel stay/hotel ID (e.g., acc_0000AWr2VsUNIF1Vl91xg0) | |
| after | No | Pagination cursor: after | |
| before | No | Pagination cursor: before | |
| limit | No | Max reviews to return (1-200) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_flightsD
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of flight | |
| origin | Yes | Origin airport or city IATA code (e.g., SFO, NYC) | |
| destination | Yes | Destination airport or city IATA code (e.g., LAX, LHR) | |
| departureDate | Yes | Departure date in YYYY-MM-DD format | |
| returnDate | No | Return date in YYYY-MM-DD format (required for round-trip) | |
| departureTime | No | Preferred departure time window | |
| arrivalTime | No | Preferred arrival time window | |
| cabinClass | Yes | Cabin class | |
| adults | No | Number of adult passengers | |
| maxConnections | No | Maximum number of connections | |
| additionalStops | No | Additional stops for multi-city flights |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_multi_cityD
| Name | Required | Description | Default |
|---|---|---|---|
| segments | Yes | Flight segments for multi-city trip | |
| cabinClass | Yes | Cabin class | |
| adults | No | Number of adult passengers | |
| maxConnections | No | Maximum number of connections |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_staysD
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | City, airport code, or area to search for stays | |
| check_in_date | Yes | Check-in date (YYYY-MM-DD) | |
| check_out_date | Yes | Check-out date (YYYY-MM-DD) | |
| guests | Yes | Number of guests | |
| rooms | No | Number of rooms | |
| radius_km | No | Search radius in kilometers |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose: get_offer_details retrieves specific offer information, get_stay_reviews fetches reviews for accommodations, search_flights finds flights, search_multi_city handles multi-city flight searches, and search_stays finds accommodations. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern using snake_case: get_offer_details, get_stay_reviews, search_flights, search_multi_city, and search_stays. This uniformity makes the tool set predictable and easy to understand.
With 5 tools, the count is reasonable for a flight and stay search server, covering core search and retrieval functions. It is slightly lean but appropriate, as it includes essential operations without being overwhelming or too sparse for the domain.
The tool set covers search and retrieval for flights and stays, including multi-city flights and stay reviews, but lacks obvious CRUD operations like booking, updating, or canceling reservations. This creates minor gaps that agents might need to work around for full lifecycle management.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Personal AI travel agent. Points optimization, live flight/hotel/award search, trip planning.
Search MCP servers, agent skills and APIs for travel: hotel ID mapping, rates, rooms.
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables searching and retrieving detailed flight information using the Duffel API, supporting various flight types and flexible search parameters for efficient travel planning.3222MIT
- -licenseNot gradedqualityNot gradedmaintenanceEnables searching and retrieving flight information using Duffel API, supporting one-way, round-trip, and multi-city queries with flexible search parameters.
- FlicenseCqualityCmaintenanceEnables searching for flights (one-way, round-trip, multi-city) and hotels using the Duffel API, with support for filtering by cabin class, passengers, dates, and viewing accommodation reviews.5
- FlicenseAqualityNot gradedmaintenanceEnables LLMs to search and book flights across 300+ airlines, manage travel orders, and search airports through the Duffel API with support for real-time pricing, multi-city trips, and flexible cabin classes.6
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/clockworked247/flights-mcp-ts'
If you have feedback or need assistance with the MCP directory API, please join our Discord server