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 Booking MCP Server Search flights from BLR to DEL on 2026-08-15"
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.
A simple MCP (Model Context Protocol) server that lets an AI assistant like Claude search for flights, book them, check booking status, and cancel bookings — using mock flight data, so it runs with zero API keys or signups.
MCP is a standard that lets AI models call external tools. This project exposes 4 tools an AI assistant can call directly in conversation:
Tool | What it does |
| Search flights between two airports on a given date |
| Book a specific flight for a passenger |
| Look up an existing booking by its ID |
| Cancel an existing booking |
Flight data is generated by mock_data.py — deterministic fake flights
(same query always returns the same results), so you can build and
test without a real flight API. A real-API version (amadeus_client.py)
is included as a reference but is disabled by default — see the note
near the bottom.
Related MCP server: Google Flights MCP Server
Python 3.10+
uv — used to manage dependencies and the virtual environment
Node.js (only needed if you want to test with MCP Inspector, step 3 below)
An MCP-compatible client, e.g. Claude Desktop
Clone the repo
git clone https://github.com/YOUR-USERNAME/flight-booking-mcp.git
cd flight-booking-mcpInstall dependencies
uv syncThis creates a .venv and installs everything listed in pyproject.toml.
(Optional) Test it standalone first
uv run python -c "import main; print(main.search_flights('BLR','DEL','2026-08-15'))"You should see a list of 3 fake flight offers printed as JSON — this confirms the code itself works, before wiring up any MCP client.
(Optional) Test it as a real MCP server with the Inspector
npx @modelcontextprotocol/inspector uv run main.pyThis opens a browser UI where you can call each tool manually and see the JSON response — the fastest way to confirm everything works before connecting a real client.
Open your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add this entry, replacing the path with the absolute path to where you cloned the repo:
{
"mcpServers": {
"flight-booking": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/flight-booking-mcp",
"run",
"main.py"
]
}
}
}Restart Claude Desktop completely (quit fully, don't just close the window). You should see "flight-booking" listed as a connected tool.
Ask your AI assistant things like:
Search flights from BLR to DEL on 2026-08-15Book the IndiGo flight (IN855-2) for passenger Jane Doe, email jane@example.comWhat's the status of booking BK1000?Cancel booking BK1000flight-booking-mcp/
├── main.py # the MCP server — defines the 4 tools
├── mock_data.py # fake flight data generator + in-memory bookings (default backend)
├── amadeus_client.py # real flight API backend (Amadeus) — disabled by default, see note below
├── pyproject.toml # project + dependency config (used by uv)
├── uv.lock # exact locked dependency versions
├── .env.example # template for real-API credentials
├── .gitignore
└── README.mdHow the mock/real switch works: main.py picks a backend based on
the USE_REAL_API environment variable (defaults to false). Every
tool calls a generic flight_backend.search_flights(...) etc., rather
than naming mock_data directly — so swapping data sources never
requires touching the tool definitions themselves.
amadeus_client.py shows how to wire this up to Amadeus's real
sandbox API (OAuth2 token handling, normalizing their nested JSON into
the same shape mock_data.py returns). However, Amadeus's Self-Service
developer portal was decommissioned in July 2026, so new signups
currently aren't possible. The file is kept as a reference pattern for
integrating any real flight API later — the mock backend is fully
sufficient for using and understanding this project as-is.
| Name | Required | Description | Default |
|---|---|---|---|
| flight_id | Yes | ||
| passenger_name | Yes | ||
| passenger_email | Yes |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| origin | Yes | ||
| destination | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0book_flightcancel_bookingget_booking_statussearch_flightsEach tool has a distinct purpose: searching, booking, canceling, and checking status. No overlap.
All tools follow a consistent verb_noun pattern (e.g., search_flights, book_flight).
4 tools is appropriate for a flight booking server, covering core operations without being over- or under-scoped.
Covers essential operations (search, book, cancel, status). Missing update booking or other advanced features, but fine for basic usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Flight search & booking for AI agents. 400+ airlines, $20-50 cheaper than OTAs.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Live flight prices and working booking links for AI agents and travel apps.
Flight search MCP server providing search, pagination, and itinerary details for AI assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DhanyaHegdek/Flight_Booking_MCP_Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
