Skip to main content
Glama
enesjakozh
ravinahp

Find Flights MCP Server

by ravinahp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

フライト検索 MCP サーバーオプション1

鍛冶屋のバッジ Duffel API を使用してフライト情報を検索および取得するための MCP サーバー。

仕組み

フライト

Related MCP server: Flight + Stay Search MCP

ビデオデモ

https://github.com/user-attachments/assets/c111aa4c-9559-4d74-a2f6-60e322c273d4

なぜこれが役立つのか

Googleフライトのようなツールは単純な旅行には最適ですが、このツールは複雑な旅行計画を扱う際に真価を発揮します。その理由は次のとおりです。

  • コンテキストメモリ：Claudeはチャットで以前のすべてのフライト検索を記憶しているので、価格を比較するために複数のタブを開いたままにする必要はありません。

  • 柔軟な日付検索: 複数の日付を簡単に検索して、各日付を手動で確認することなく、最良の価格を見つけることができます。

  • 複雑な旅程: 複数都市への旅行、乗り継ぎ便、またはさまざまなルート オプションを比較する必要がある場合に最適です。

  • 自然な会話: 探しているものを説明するだけです。カレンダー インターフェイスをクリックしたり、都市名、日付、時刻を解析するための検索パラメータを調整したりする必要はありません。

話し合った内容をすべて記憶し、日付やルートを瞬時に検索できる旅行代理店がチャットにいるようなものだと考えてください。

特徴

  • 複数の目的地間のフライトを検索

  • 片道、往復、複数都市のフライト検索をサポート

  • 詳細なフライトオファー情報

  • 柔軟な検索パラメータ（出発時刻、客室クラス、乗客数）

  • フライト接続の自動処理

  • 複数日以内のフライトを検索して、旅行に最適なフライトを見つけます（遅い）

前提条件

  • Python 3.x

  • ダッフル API ライブキー

ダッフルAPIキーの取得

Duffel ではアカウントの確認と支払い情報の設定が必要ですが、この MCP サーバーはフライトの検索にのみ API を使用します。実際の予約やアカウントへの請求は行われません。

まずはduffel_testを使って、このツールの威力を実感してみてください。気に入ったら、以下の検証プロセスを経てライブキーをご利用ください。

まずテストモード（推奨）

完全な検証プロセスを実行する前に、テスト API キー ( duffel_test ) を使用して、シミュレートされたデータで機能を試すことができます。

  1. ダッフルの登録ページをご覧ください

  2. アカウントを作成します（会社名には「個人使用」を選択できます）

  3. [詳細] > [開発者] に移動して、テスト API キーを見つけます (すでに提供されています)

ライブAPIキーの取得

実際の飛行データにアクセスするには、次の手順に従います。

  1. ダッフルダッシュボードの左上隅にある「テストモード」をオフにします。

  2. 検証プロセスには複数の手順が必要であり、テスト モードを繰り返しオフに切り替える必要があります。

    • 最初のトグル: メールアドレスを確認する

    • もう一度切り替える: 会社情報を入力します（個人使用でも問題ありません）

    • もう一度切り替える: 支払い情報を追加します (Duffel では必須ですが、この MCP サーバーでは料金は発生しません)

    • もう一度切り替える: 残りの検証手順を完了します

    • 最終切り替え:「同意して送信」をクリックした後、ライブモードにアクセスします

  3. 完全に検証されたら、「その他」>「開発者」>「ライブトークンの作成」に進みます。

  4. ライブAPIキーをコピーする

💡ヒント：検証手順を完了するたびに、次のステップに進むためにテストモードをオフにする必要があります。すべての要件を完了するまで、テストモードをオフに切り替え続けてください。

⚠️ 重要事項:

  • お支払い情報はDuffelによって直接処理され、MCPサーバーによってアクセスまたは保存されることはありません。

  • このMCPサーバーは読み取り専用です。フライトの検索はできますが、予約はできません。

  • この統合により、お支払い方法に料金は発生しません。

  • すべての機密情報（APIキーを含む）はローカルマシンに保持されます

  • テストAPIキー（ duffel_test ）から始めて機能を評価できます。

  • 検証プロセスには時間がかかる場合があります。これはダッフルの標準的な要件です。

セキュリティに関する注意事項

このMCPサーバーはDuffelの検索エンドポイントのみを使用し、予約や課金を行うことはできません。お支払い情報はDuffelの認証プロセスのみに使用され、MCPサーバーがアクセスしたり共有したりすることはありません。

API使用制限に関する注意事項

  • ダッフルの現在の価格と使用制限を確認する

  • お客様の要件に応じてさまざまなレベルをご用意

  • ウェブサイトで現在の価格を確認することをお勧めします

インストール

Smithery経由でインストール

Smithery経由で Claude Desktop の Find Flights を自動的にインストールするには:

npx -y @smithery/cli install @ravinahp/travel-mcp --client claude

手動インストール

リポジトリをクローンします。

git clone https://github.com/ravinahp/flights-mcp
cd flights-mcp

uv を使用して依存関係をインストールします。

uv sync

注: プロジェクトでは依存関係の管理に pyproject.toml を使用しているため、pip ではなく uv を使用します。

MCPサーバーとして構成する

このツールを MCP サーバーとして追加するには、Claude デスクトップ構成ファイルを変更します。

構成ファイルの場所:

  • MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%/Claude/claude_desktop_config.json

次の構成を JSON ファイルに追加します。

{
    "flights-mcp": {
        "command": "uv",
        "args": [
            "--directory",
            "/Users/YOUR_USERNAME/Code/flights-mcp",
            "run",
            "flights-mcp"
        ],
        "env": {
            "DUFFEL_API_KEY_LIVE": "your_duffel_live_api_key_here"
        }
    }
}

⚠️ 重要:

  • YOUR_USERNAME実際のシステムユーザー名に置き換えます

  • your_duffel_live_api_key_hereを実際の Duffel Live API キーに置き換えます。

  • ディレクトリパスがローカルインストールと一致していることを確認してください

展開

建物

パッケージを準備します。

# Sync dependencies and update lockfile
uv sync

# Build package
uv build

これにより、 dist/ディレクトリにディストリビューションが作成されます。

デバッグ

最適なデバッグ エクスペリエンスを得るには、MCP インスペクターを使用します。

npx @modelcontextprotocol/inspector uv --directory /path/to/find-flights-mcp run find-flights-mcp

検査官は以下を提供します:

  • リアルタイムのリクエスト/レスポンス監視

  • 入力/出力検証

  • エラー追跡

  • パフォーマンスメトリック

利用可能なツール

1. フライトを検索

@mcp.tool()
async def search_flights(params: FlightSearch) -> str:
    """Search for flights based on parameters."""

3 つの飛行タイプをサポートします:

  • 片道便

  • 往復航空券

  • 複数都市へのフライト

パラメータには次のものが含まれます。

  • type : フライトの種類（'one_way'、'round_trip'、'multi_city'）

  • origin : 出発空港コード

  • destination : 目的地空港コード

  • departure_date :出発日(YYYY-MM-DD)

  • オプションパラメータ:

    • return_date : 往復の帰国日

    • adults ：大人の乗客数

    • cabin_class : 希望するキャビンクラス

    • departure_time : 特定の出発時間の範囲

    • arrival_time : 特定の到着時間の範囲

    • max_connections : 最大接続数

2. オファーの詳細を取得する

@mcp.tool()
async def get_offer_details(params: OfferDetails) -> str:
    """Get detailed information about a specific flight offer."""

一意の ID を使用して、特定のフライト オファーの包括的な詳細を取得します。

3. 複数都市間のフライトを検索

@mcp.tool(name="search_multi_city")
async def search_multi_city(params: MultiCityRequest) -> str:
    """Search for multi-city flights."""

複雑な複数都市のフライト旅程に特化したツールです。

パラメータには次のものが含まれます。

  • segments ：飛行セグメントのリスト

  • adults ：大人の乗客数

  • cabin_class : 希望するキャビンクラス

  • max_connections : 最大接続数

ユースケース

いくつかの例（でも、自分で試してみてください！）

以下のツールを使用して、さまざまな複雑さのフライトを見つけることができます。

  • 「1月7日のサンフランシスコ発ニューヨーク行きビジネスクラス大人2名分の片道航空券を検索」

  • 「1月8日出発、1月15日帰着のロサンゼルス国際空港発ロンドン行き往復航空券を検索」

  • 「1月7日にニューヨークからパリへ、1月10日にローマへ、そして1月15日にニューヨークに戻る複数都市の旅行を計画してください」

  • 「1 月 7 日から 1 月 15 日までの SFO から LAX へのエコノミークラス大人 2 名向けの最も安いフライトはどれですか？」

  • 複数日にわたるフライトを検索して、ご旅行に最適なフライトを見つけることもできます。現時点では、片道または往復のフライトのみを検索することをお勧めします。例：「1月7日から1月10日までのサンフランシスコ発ロサンゼルス行きのエコノミークラス大人2名様の最安値のフライトを検索」

応答フォーマット

ツールは、次の内容を含む JSON 形式の応答を返します。

  • フライトオファーの詳細

  • 価格情報

  • スライス（ルート）の詳細

  • キャリア情報

  • 接続の詳細

エラー処理

このサービスには、次のような堅牢なエラー処理が含まれています。

  • APIリクエストの失敗

  • 無効な空港コード

  • APIキーが見つからないか無効です

  • ネットワークタイムアウト

  • 無効な検索パラメータ

貢献

[該当する場合は、投稿のガイドラインを追加します]

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。

パフォーマンスノート

  • 検索は片道/往復航空券50件までに制限されています

  • 複数都市の検索は10件のオファーに制限されます

  • サプライヤーのタイムアウトは、検索タイプに応じて15～30秒に設定されます。

客室クラス

利用可能な客室クラス:

  • economy ：標準エコノミークラス

  • premium_economy : プレミアムエコノミークラス

  • business ：ビジネスクラス

  • first ：ファーストクラス

キャビンクラスのリクエスト例:

{
  "params": {
    "type": "one_way",
    "adults": 1,
    "origin": "SFO",
    "destination": "LAX",
    "departure_date": "2025-01-12",
    "cabin_class": "business"  // Specify desired cabin class
  }
}

Available Tools

3 tools
get_offer_detailsB

Get detailed information about a specific flight offer.

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states it's a read operation ('Get'), implying it's non-destructive, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what 'detailed information' entails beyond the input schema. This leaves significant gaps for an agent to understand how to use it effectively.

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

Conciseness5/5

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

The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness3/5

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

Given the tool has an output schema (which likely defines the return structure), the description doesn't need to explain return values. However, with no annotations, 0% schema description coverage, and one parameter, the description is minimal. It covers the basic purpose but lacks usage guidelines and behavioral details, making it incomplete for optimal agent use despite the output schema's support.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'a specific flight offer', which aligns with the 'offer_id' parameter in the input schema. However, schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal semantics by implying the parameter identifies an offer, but doesn't explain format, source, or constraints, offering only basic compensation for the low coverage.

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 the verb 'Get' and the resource 'detailed information about a specific flight offer', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_flights' or 'search_multi_city', which appear to be search operations rather than detail retrieval for a specific offer.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an offer ID from a previous search, or clarify that it's for retrieving details of a single, pre-identified offer rather than searching for new ones.

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

search_flightsD

Search for flights based on parameters.

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1.9/5.0
Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't indicate whether this is a read-only operation, whether it requires authentication, what rate limits might apply, what format results are returned in, or any other behavioral characteristics. For a search tool that likely interacts with external APIs, this lack of transparency is a significant gap that leaves the agent guessing about important operational aspects.

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

Conciseness5/5

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

The description is maximally concise at just 6 words. While this conciseness comes at the expense of completeness, every word earns its place - 'Search' indicates the action, 'for flights' specifies the resource, and 'based on parameters' acknowledges the input requirements. There's no wasted verbiage or redundant phrasing, making it efficiently front-loaded despite its brevity.

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?

Given the complexity of flight search (11 parameters with nested objects, multiple flight types, and sibling tools), the description is woefully incomplete. While the presence of an output schema means the description doesn't need to explain return values, it fails to provide context about the tool's scope, limitations, or relationship to other tools. With no annotations and minimal description, the agent lacks crucial information needed to use this tool effectively in context with 'search_multi_city' and 'get_offer_details'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description states 'based on parameters' but provides zero information about what those parameters are or their semantics. With schema description coverage at 0% (the schema has descriptions but they're not counted in coverage), the description fails to compensate by explaining any of the 11 parameters documented in the schema. The agent must rely entirely on the schema to understand parameters like 'type', 'origin', 'destination', 'departure_date', etc., with no high-level guidance from the description.

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

Purpose2/5

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

The description 'Search for flights based on parameters' is tautological - it essentially restates the tool name 'search_flights' with minimal elaboration. While it indicates the general action (search) and resource (flights), it lacks specificity about what kind of search this performs or how it differs from sibling tools like 'search_multi_city'. The description doesn't provide meaningful differentiation from what the name already conveys.

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?

The description provides absolutely no guidance about when to use this tool versus alternatives. With sibling tools like 'search_multi_city' and 'get_offer_details' available, the agent receives no indication whether this is the primary search tool, whether it's for simple searches while 'search_multi_city' handles complex itineraries, or any prerequisites or constraints. The description offers zero contextual usage information.

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

search_multi_cityC

Search for multi-city flights.

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'search' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, pagination, error handling, or what the search returns (e.g., flight options, prices). For a complex search tool with no annotations, this is a significant gap.

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

Conciseness5/5

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

Extremely concise with a single sentence ('Search for multi-city flights.'). It's front-loaded and wastes no words, though this conciseness comes at the cost of completeness. Every word earns its place by stating the core function.

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?

Given the tool's complexity (multi-city flight search with 1 parameter containing nested objects), no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It lacks context on usage, behavior, and doesn't leverage the output schema to clarify purpose. For a search tool with rich schema but no annotations, more guidance is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the input schema has detailed descriptions for all parameters (e.g., 'Flight segments', 'Departure date (YYYY-MM-DD)'). The description adds no parameter information beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting, though the description doesn't compensate for the 0% coverage with any additional context.

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

Purpose3/5

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

The description 'Search for multi-city flights' states the basic action (search) and resource (multi-city flights), but it's vague about scope and doesn't distinguish from sibling 'search_flights'. It doesn't specify what 'search' entails (e.g., finding available flights, prices, routes) or how multi-city differs from other flight types.

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 'search_flights' or 'get_offer_details'. The description implies usage for multi-city flights but doesn't specify prerequisites, constraints (e.g., minimum segments), or alternatives. Without explicit when/when-not instructions, the agent lacks context for tool selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedget_offer_details
    • First observedsearch_flights
    • First observedsearch_multi_city
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_offer_details retrieves details for a specific offer, search_flights handles standard flight searches, and search_multi_city handles multi-city itineraries. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: get_offer_details, search_flights, and search_multi_city. The naming is predictable and readable throughout.

Tool Count3/5

With only 3 tools, the set feels thin for a flight search domain. While the core search functions are covered, typical operations like booking, managing reservations, or checking availability are missing, making the scope borderline minimal.

Completeness2/5

The toolset is significantly incomplete for flight operations. It lacks essential actions such as booking flights, canceling reservations, checking seat availability, or managing user profiles, which are critical for a functional flight service. Agents will face dead ends in common workflows.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches