Skip to main content
Glama
jidehen

Travel Server MCP

by jidehen

Travel Server MCP

A modular MCP server for searching flights using the Duffel API. Built for extensibility, maintainability, and clarity.

Step-by-Step Tutorial

If you want a guided walkthrough on how this server was created from scratch, check out the Step-by-Step Tutorial.

Related MCP server: Find Flights MCP Server

Features

  • Search for flights between any two airports using the Duffel API

  • Granular, well-documented codebase with clear separation of concerns

  • Detailed debug logging returned with every search

  • Easily extensible for new tools, models, or providers

Project Structure

travelserver/
├── main.py                # Entrypoint: sets up and runs the MCP server
├── duffel_client.py       # Duffel API HTTP logic (search_flights)
├── models/
│   ├── __init__.py
│   ├── flight_search_params.py
│   └── flight_offer.py
├── tools/
│   └── flight_tools.py    # MCP tool for flight search
├── .env                   # (not committed) Your Duffel API key
├── pyproject.toml         # Project dependencies
└── ...

Setup

  1. Clone the repository

    git clone https://github.com/kidehen/mcp-travel-server.git
    cd mcp-travel-server
  2. Create and activate a virtual environment with uv:

    uv venv
    source .venv/bin/activate
  3. Install dependencies with uv:

    uv pip install -e .
  4. Create a .env file in the project root:

    DUFFEL_ACCESS_TOKEN=your_duffel_api_key_here

Running the Server

Run the server using uv:

uv run main.py

Claude Desktop MCP Server Configuration

{
  "mcpServers": {
    "travel-server": {
      "command": "/opt/homebrew/bin/uv",
      "args": [
        "--directory",
        "/Users/jidehen/Documents/Projects/mcp-servers/travelserver",
        "run",
        "main.py"
      ]
    }
  }
}

Usage

  • The MCP server exposes a get_flights tool for searching flights.

  • You can connect this server to an MCP-compatible client (e.g., Claude Desktop).

  • When a user asks about flights, the client will call the get_flights tool with the appropriate parameters.

  • The server returns a list of flight offers and a detailed debug log for troubleshooting.

Environment Variables

  • DUFFEL_ACCESS_TOKEN: Your Duffel API key (required, set in .env)

Extending the Project

  • Add new models to models/ (one per file)

  • Add new tools to tools/

  • Add new API integrations to their own directories (e.g., duffel/, amadeus/)

  • Keep configuration in config/ as needed

FAQ

  • How does the MCP client know how to interact with the Duffel API?

    The MCP client never talks to Duffel directly. It calls this MCP server's tool, which handles all Duffel API logic internally and returns results to the client.

  • How does the MCP client know to trigger this server for flight queries?

    The MCP client discovers all available MCP servers and their tools. When a user asks about flights, the client uses natural language understanding to match the user's intent to the get_flights tool, and then calls it.

License

MIT

Available Tools

get-flights

Search for available flights between two locations.

Parameters:

  • origin: Origin airport code (e.g., 'LHR')

  • destination: Destination airport code (e.g., 'JFK')

  • departure_date: Departure date in YYYY-MM-DD format

  • return_date (optional): Return date in YYYY-MM-DD format

  • passengers (optional): Number of adult passengers (default: 1)

  • cabin_class (optional): Cabin class (economy, business, first) (default: economy)

Example response:

[
  {
    "airline": "British Airways",
    "flight_number": "BA178",
    "departure_time": "2024-03-20T10:00:00",
    "arrival_time": "2024-03-20T13:00:00",
    "price": 299.99,
    "currency": "USD",
    "stops": 0
  }
]

Available Tools

1 tool
get_flightsC

MCP tool for searching available flights between two locations. Returns both results and debug logs.

ParametersJSON Schema
NameRequiredDescriptionDefault
originYes
destinationYes
departure_dateYes
return_dateNo
passengersNo
cabin_classNoeconomy

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions returning results and debug logs, which is useful, but fails to disclose if the operation is read-only, any side effects, or rate limits. The agent cannot infer safety or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise at two sentences, but it under-specifies critical information. While front-loaded, the brevity comes at the cost of missing essential details, making it merely adequate rather than effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters and no output schema, the description is incomplete. It does not explain return value structure beyond 'results and debug logs', and fails to cover data formats, constraints, or edge cases. The tool needs significantly more context to be usable.

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?

Schema description coverage is 0%, and the description does not explain any of the 6 parameters (origin, destination, date, passengers, cabin class). The agent gets no guidance on how to fill in these fields, such as date format, allowed values, or passenger limits.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches available flights between two locations, with a specific verb and resource. It also mentions returning results and debug logs, adding context. However, it lacks differentiation from potential sibling tools, though none are provided.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, or any prerequisites. The description only states the basic function without context about appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

TDQS

C2.7/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or ambiguity between tools.

Naming Consistency5/5

With only one tool, the naming is trivially consistent and follows a clear verb_noun pattern.

Tool Count2/5

A single tool for a travel server is too few; typically such a server would require multiple operations beyond just searching flights.

Completeness1/5

The tool covers only flight search, missing essential operations like booking, cancellation, or itinerary management, leaving the surface severely incomplete.

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/jidehen/mcp-travel-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server