Skip to main content
Glama
clockworked247

Flight + Stay Search MCP

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

  1. Install dependencies:

    npm install
  2. Build the project:

    npm run build
  3. Start the server:

    npm start

Environment Variables

Create a .env file with:

DUFFEL_API_KEY=your_duffel_api_key

You 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 publish

To 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:

  1. search_flights - Search for one-way, round-trip, or multi-city flights

  2. get_offer_details - Get detailed information about a specific flight offer

  3. search_multi_city - A specialized tool for multi-city flight searches

  4. search_stays - Search for travel stays (hotels/accommodations)

  5. 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 stays

  • check_in_date (string): Check-in date (YYYY-MM-DD)

  • check_out_date (string): Check-out date (YYYY-MM-DD)

  • guests (number): Number of guests

  • rooms (number, optional): Number of rooms

  • radius_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 dev

License

MIT

Available Tools

5 tools
get_offer_detailsD
ParametersJSON Schema
NameRequiredDescriptionDefault
offerIdYesUnique identifier for the flight offer

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
stay_idYesDuffel stay/hotel ID (e.g., acc_0000AWr2VsUNIF1Vl91xg0)
afterNoPagination cursor: after
beforeNoPagination cursor: before
limitNoMax reviews to return (1-200)

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesType of flight
originYesOrigin airport or city IATA code (e.g., SFO, NYC)
destinationYesDestination airport or city IATA code (e.g., LAX, LHR)
departureDateYesDeparture date in YYYY-MM-DD format
returnDateNoReturn date in YYYY-MM-DD format (required for round-trip)
departureTimeNoPreferred departure time window
arrivalTimeNoPreferred arrival time window
cabinClassYesCabin class
adultsNoNumber of adult passengers
maxConnectionsNoMaximum number of connections
additionalStopsNoAdditional stops for multi-city flights

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
segmentsYesFlight segments for multi-city trip
cabinClassYesCabin class
adultsNoNumber of adult passengers
maxConnectionsNoMaximum number of connections

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesCity, airport code, or area to search for stays
check_in_dateYesCheck-in date (YYYY-MM-DD)
check_out_dateYesCheck-out date (YYYY-MM-DD)
guestsYesNumber of guests
roomsNoNumber of rooms
radius_kmNoSearch radius in kilometers

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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

C2/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

Latest Blog Posts

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