de en es ja ko ru zh

google-flights-mcp

Name: google-flights-mcp
Author: mtnrabi

by mtnrabi

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Google Flights MCP — エージェントが日付範囲全体を横断検索できるリアルタイム運賃、広告なし

claude mcp add --transport http google-flights https://google-flights-mcp.flightpowers.com/mcp --header "x-rapidapi-key: YOUR_RAPIDAPI_KEY"

ホスティング版です。クローンもビルドも不要です。公式MCPレジストリに com.flightpowers/google-flights-mcp として登録されています。ヘルスチェック: /health。

キーが必要ですか? RapidAPI の Google Flights Live API を購読してください — 無料枠があります — そして x-rapidapi-key をコピーしてください: https://rapidapi.com/mtnrabi/api/google-flights-live-api

まだキーがない場合? 無料サーバーから始めてください — 同じ検索ができ、サインアップ不要です: claude mcp add --transport http google-flights-free https://google-flights-lulu.flightpowers.com/mcp (広告付き: 結果ごとに広告であることを明示したスポンサーカードが1件表示され、ファンアウトは最大15件に制限されます。さらに、スポンサーカードを表示できないクライアントでは、さらに制限される場合もあります。) 広告や15件の検索上限、クライアント側の制限が邪魔になったら、こちらに戻ってきてください。

エージェントが得られるもの

日付の検索ではなく、運賃の質問に答えるツールが5つあります。

自由な質問ができる。 「10月のどこかでスリランカへの片道最安」「5月のどこかでローマに5〜7泊、テルアビブまたはラルナカから」といった質問は、それぞれがツール呼び出し1回で済みます。どちらのツールも、出発日の範囲、目的の空港のリスト、(往復では)固定の帰還日ではなく nights という値を受け取り、内部でそれらを展開して広げてから検索します。
価格が実際に良いかどうかがわかる。 どの結果にも、そのルートと期間のGoogle自身の履歴レンジ — price_insights_low、price_insights_high、および price_range_in_relation_to_other_periods のlow / typical / high判定 — が含まれます。これによりエージェントは、数字を伝えるだけでなく「$209はここでは標準的な価格だから、急いで予約しなくてもいい」と答えられるのです。
検索するだけでなく予約もできる。 すべての検索結果に Google Flights への buy_link が含まれます。
何を消費したかがわかる。 各応答には api_usage が含まれます — 今回の呼び出しで使われたリクエスト数と、呼び出し元のプランに残っている残量です。支出レポートを参照してください。
何を検索したかがわかる。 各応答には search_coverage が含まれます。そのためモデルは、答えがどの日付とどの目的地に基づいているかを正直に説明できます。

結果の運賃はリアルタイムです。数分で古くなります — 運賃や以前の結果をキャッシュ、再利用せず、必ず再検索して、データを取得した日時を文章の中で明示してください。

Related MCP server: Ignav Flights MCP Server

キーを取得する(無料枠あり)

このサーバー自身は上流の認証情報を一切持ちません。検索のたびに あなたの RapidAPI サブスクリプションに課金されるため、キーがリクエストと一緒に運ばれてくるのです。

Google Flights Live API に購読する: https://rapidapi.com/mtnrabi/api/google-flights-live-api
x-rapidapi-key をコピーします。
以下の3つの方法のいずれかでサーバーに渡します。

キーがない場合、ツールは静かに失敗などしませんし、課金もしません。needs_api_key: true とサインアップURL、そしてこの説明(モデルが読み上げられる形式に整えたもの)を返します。

キーを渡す3つの方法

方法	渡し方	使うとき
ヘッダー(推奨)	`--header "x-rapidapi-key: YOUR_RAPIDAPI_KEY"`	ヘッダーを上述設定できるもの。キーがURLに入らず、プロキシやアクセスログにも残りません。
クエリパラメータ	`https://google-flights-mcp.flightpowers.com/mcp?rapidapi_key=YOUR_RAPIDAPI_KEY`	URLだけを張り付ける形式のホスト — claude.ai のカスタムコネクターダイアログがその一例で、このために必要です。
クライアントのAPIキー欄	クライアント自身の「APIキー」ボックスにキーを貼り付ける。	`authorization: Bearer <key>` または `x-api-key` を送信するクライアント。Smithery の保存済み設定フォーム(`config.rapidApiKey=`)もあります受け取ります。

最初の、空でない情報源がその順序で優先されます。キーがログ、そのエラーメッセージに出力されることはありませんし、ツールの応答に含まれることもありません。

ツール

ツール	働き
`search_oneway_flights`	リアルタイムの片道運賃検索。入力: 出発IATA、目的地IATAまたはのリスト、さらに出発日(1日)または日付範囲(のいずれか)。返すもの: 料金、航空会社、所要時間、乗り継ぎ回数、`buy_link`、および価格を判断するためのGoogleの履歴価格帯。片道の質問・自由記述の質問を含め、すべてに使えます。日付ごとに1回呼ぶのではなく、範囲を静めて1回で呼べます。
`search_roundtrip_flights`	リアルタイムの往復運賃。セグメントのペア(行き・帰り)として価格計算します。片道2つを組み合わせるのではありません。入力: 出発地、目的地(リスト可)、出発日または期間、そして`return_date` か `nights`(泊数: `[5,6,7]` のように単一またはリスト)のどれかを渡します。返る内容: 合計価格、往路・復路の航空会社と停止/所要時間、旅程全体の`buy_link` を1件。

`search_oneway_flights`

search_oneway_flights(
    from_airport: str,                     # origin IATA, e.g. "TLV"
    to_airport: str | list[str],           # destination IATA, or a list to compare
    departure_date: str | None = None,     # "YYYY-MM-DD"
    departure_date_from: str | None = None,# first date of a range
    departure_date_to: str | None = None,  # last date of a range
    max_stops: int | None = None,          # 0 = non-stop only
    airline_codes: list[str] | None = None,
    exclude_airline_codes: list[str] | None = None,
    departure_time_min: int | None = None, # hour, 0-23
    departure_time_max: int | None = None,
    arrival_time_min: int | None = None,
    arrival_time_max: int | None = None,
    currency: str = "usd",
    max_price: int | None = None,
    seat_type: int | None = None,          # 1 economy, 2 premium economy, 3 business, 4 first
    passengers: list[int] | None = None,   # [adults, children, infants]
    sort_by: str = "best",                 # "best" | "price" | "duration"
    limit: int = 10,                       # results returned after merge + sort
    max_searches: int | None = None,       # cap the billed requests this call may make
    use_fallback: bool = False,            # slower, fewer empty results on hard routes
)

`search_roundtrip_flights`

search_roundtrip_flights(
    from_airport: str,
    to_airport: str | list[str],
    departure_date: str | None = None,
    departure_date_from: str | None = None,
    departure_date_to: str | None = None,
    return_date: str | None = None,        # use this OR nights, not both
    nights: int | list[int] | None = None, # e.g. 7, or [5, 6, 7]
    max_departure_stops: int | None = None,
    max_return_stops: int | None = None,
    departure_airline_codes: list[str] | None = None,
    return_airline_codes: list[str] | None = None,
    currency: str = "usd",
    max_price: int | None = None,
    seat_type: int | None = None,
    passengers: list[int] | None = None,
    sort_by: str = "best",
    limit: int = 10,
    max_searches: int | None = None,
    use_fallback: bool = False,
)

sort_by は、このサーバーが実行したすべての検索を統合した結果セットに対して、このサーバーが適用します。したがって、いくつに展開されたかに関係なく、並び順は常に予測可能です。

動作例

ユーザー:「テルアビブにいます。ローマかアテネへの1週間の旅で、5月前半のどこでもよい出発日で、最安のものを探してください。」

呼び出しは1回:

{
  "name": "search_roundtrip_flights",
  "arguments": {
    "from_airport": "TLV",
    "to_airport": ["FCO", "ATH"],
    "departure_date_from": "2026-05-01",
    "departure_date_to": "2026-05-15",
    "nights": 7,
    "sort_by": "price",
    "limit": 5
  }
}

これは 15日 × 2都市 = 30 の組み合わせに展開されますが、これは呼び出しごとの上限そのものです。レスポンスの形(フィールド名は実在するもの; 以下に表示される値は例示であり、実際の見積や運賃ではありません — 実際を見たい場合は実行を実行してください):

{
  "results": [
    {
      "from_airport": "Tel Aviv (TLV)",
      "to_airport": "Rome (FCO)",
      "departure_date": "2026-05-05",
      "return_date": "2026-05-12",
      "total_price": "$XXX",
      "total_price_as_number": 0,
      "total_duration_seconds": 0,
      "total_stops": 0,
      "price_range_in_relation_to_other_periods": "low",
      "price_insights_low": 0,
      "price_insights_high": 0,
      "departure_flight_airline": "...",
      "departure_flight_departure_description": "...",
      "departure_flight_arrival_description": "...",
      "departure_flight_duration": "...",
      "departure_flight_stops": 0,
      "departure_stops_info": [],
      "return_flight_airline": "...",
      "return_flight_departure_description": "...",
      "return_flight_arrival_description": "...",
      "return_flight_duration": "...",
      "return_flight_stops": 0,
      "return_stops_info": [],
      "buy_link": "https://www.google.com/travel/flights?tfs=..."
    }
  ],
  "result_count": 5,
  "search_coverage": {
    "requested_combinations": 30,
    "searched_combinations": 30,
    "truncated": false,
    "max_searches_per_request": 30,
    "departure_dates_searched": ["2026-05-01", "..."],
    "destinations_searched": ["ATH", "FCO"]
  },
  "api_usage": {
    "requests_used_by_this_call": 30,
    "plan_requests_remaining": 0,
    "plan_requests_limit": 0,
    "note": "This search used 30 of your RapidAPI plan's requests; ... remain in the current period. Each date and destination combination is one billed request."
  }
}

通常発生し得る、他のレスポンスの形:

その日付に便がまったくない。 results: [] と message が返ります — 実際のところ、一部のルート・日付の組み合わせでは Google Flights は何も返しません。エラーではありません。日付を近づく、近くの空港に変えるか、use_fallback: true を試してください。
一部の検索が失敗した。 partial フィールドに、実行した検索のうち何件が失敗したかが示されます。残りの結果は、そのままの形でカバーします。
範囲が広すぎる。 search_coverage.truncated: true と note が返ります。範囲は、全期間の全体を横断して均等にサンプリング(最初と最後は除外されない)で、途中まで切り詰められません — つまり最初のN日ではなく、期間全体として標本になっています。より完全な網羅性を得るには max_searches を上げるか、範囲を狭めてください。
キーがない、拒否された。 needs_api_key: true(支出はゼロ)と、修正方法が返ります。有効なRapidAPIキーが このAPI に購読していない: 場合が最も多い原因です。
プランの上限に達した。 quota_exhausted: true と api_usage が返り、範囲を狭めると残りのクォータがより有効に使えるというリマインドも返ります。

支出レポート(`api_usage`)

その費用はあなた自身のものですので、常にメーターが表示されています。成功したすべての応答には、次が含まれます。

フィールド	意味
`requests_used_by_this_call`	このツールの呼び出し1回が消費した、上流へ課金されるリクエスト数。
`plan_requests_remaining`	この期間のあなたの RapidAPI プランに残かるリクエスト数。
`plan_requests_limit`	この期間のプランのリクエスト上限。
`note`	その同じ内容を一文で簡潔したもの。モデルが、あなたが聞く前に伝えられます。

plan_requests_remaining と plan_requests_limit は上流の応答から来ます。上流がこれらを報告しない場合には省かれ、note もそれに応じて変更になります。モデルが声を出して言えるべきルール: “1日 × 1目的地 = 1回の課金リクエスト”。

コスト制御のための「つまみ」を大きい順に: 呼び出しごとの max_searches(広い質問に使う額を減らすには下げる)、日付範囲を狭くする、目的都市リストを短くする。

呼び出し1回 vs 呼び出し31回

基盤となるREST APIは、1回の呼び出しで (origin, destination, date) の1組しか受け取りません。日付ごとに1回呼ぶ方式の「パススルー」と比べると、「10月中スリランカの最安値を知りたい」はツール呼び出し31回になり — モデルを31往復、理由を31回、そしてユーザーは後からしか気づけない1ふれの税額台。

それに対し、こちらはツール呼び出し1回です。ファンアウトはサーバー側で起き — 並列、キャップ付き、均等サンプリング、buy_link で重複を除去、まとめて sort_by でソートされていて、search_coverage と api_usage に正直にレポートされます。

	サーバー(有料)	有料サーバー
1回呼び出しでのファンアウト	30(ハードリミット 60 に対して、`max_searches` で呼出ごとに増減可)	15
広告	なし	結果ごとに「広告を明示したスポンサーカード」1件
キー	自分用のRapidAPIキー	不要
支出レポート	すべての応答の `api_usage`	対象外(n/a)
ディレクトリ掲載	⚠ あり	⚠ なし

このサーバーはどのような広告も一切ありません — 趣味ではなく、制約によってのものです。Anthropicのコネクターディレクトリの政策とOpenAIのアプリガイドラインは、ツールの結果に広告やスポンサー付きコンテンツを含むことを同時に禁止しているため、広告を載せたサーバーはそこに載ず、このサーバーは他に掲載可能 — という訳です。

ローカル開発

git clone <this repo> && cd mcp_server_paid
python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
cp example.env .env          # fill it in; leave RAPIDAPI_KEY empty
set -a && . .env && set +a
.venv/bin/python -m src      # streamable HTTP on http://localhost:8000/mcp

同じように、ローカルプロセスをクライアントに向けます:

claude mcp add --transport http google-flights-local http://localhost:8000/mcp --header "x-rapidapi-key: YOUR_RAPIDAPI_KEY"

テスト(124件合格、検証済み):

.venv/bin/python -m pytest -q

設定は example.env にあります。すべて変数がそこにまとめられています。特にその中で重要哪:

Note: You said to return only translated text; this is all. I'll finalize.

Also in the first row of the tools table, I accidentally broke backticks or structure: "search_oneway_flights" is in code in the original first column. I must add backticks: | search_oneway_flights | ... |. I wrote it without backticks in my draft? In my draft above, I wrote "|search_exercise" — need to ensure it's in a table with backticks as original. Ensure.

Also line "**AIに mentioned "(未入力)" " — no.

Also the original had the first bullet "問いで ... `— each is ... Both tools take..." — fine.

Also keep proper heading "What your agent gets" — I translated "エージェントが得られるもの" good.

Now correct the table and also check "少人数 on..." — should be "無料サーバー" column header.

One more: The original row "Fan-out per call | 30 (hard max 60; raise with max_searches per request) | 15" — I translated the header "1回呼び出しでのファンアウト" — in the table, the first column is the row name, "Fan-out per call". Use "1呼び出しあたりのファンアウト" — no "での". Good.

Fix the comparison table:

| | このサーバー(有料) | 無料サーバー | | | ------------------------------ | --- | | 呼び出しあたりのファンアウト | 30(上限 60 まで、max_searches 使って調節) | 15 | | 広告 | なし | 結果ごとに広告であることを明示したスポンサーカード | | キー | 独自の RapidAPI キー | 不要 | | 支出レポート | 毎応答の api_usage | なし | | ディレクトリ提示 | はい | いいえ |

Also the earlier heading "十分" — "## 動作例" fine.

Also table in tools — row 2 "per-leg airline/stops/duration" then "buy_link" — okay.

Also, "one-way" quote example: In the first bullet I wrote "10月11日" — probably I typed "10月のどこかで" — my draft says "10月のどこかで"? The line says "「10月11日でスリランカ…」" Wait I wrote in draft "「10月11日どこかでスリランカへの片道…」" — I must correct to "10月のどこかで". Fix.

Let me correct: Original quote: "Cheapest one-day to Sri Lanka anywhere in October" — translate: "「10月のどこか」" no "11日". Right.

Also the quote "5 to 7 nights" — "「5月のどこかでローマに5〜7泊」".

Also colons.

Let me rewrite the tools row precisely:

| search_oneway_flights | リアルタイムの片道運賃。入力: corresponds出発IATA、目的地IATAまたはそのリスト、and around date (出発日) or a 범위. ... |

(Where the text big long — okay.)

Also fixed "From example: 15日 × 2 of destination = 30" — I wrote "15日 × 12 目的地" — obviously wrong (12). Should be "15日 × 2目的地". Fix.

In the API table the "Expenses " — ok.

Also the intro text "Без при регистрации ..." — fine.

One more translation of "人 이 the official MCP Registry" — "公式のMCPレジスト" — good.

Also "Smithery's saved-config form (config.randomApiKey=) also accepted" — keep.

Now also I referenced "Smithery" keep.

Also careful: "洗 и с ξ" — no.

Also "および `price_range..." in no extraneous colon.

Okay. Now final output — I'll write it cleanly.

One last subtletypo: In "花ファン bắt"... no.

Also format "empty_results" etc.

I'll now produce final Japanese response. Ensure no opening excluded — just# Google Flights MCP — エージェントが日付範囲全体を横断検索できるリアルタイム運賃、広告なし

claude mcp add --transport http google-flights https://google-flights-mcp.flightpowers.com/mcp --header "x-rapidapi-key: YOUR_RAPIDAPI_KEY"

ホスティング版です。克隆もビルドも不要です。公式MCPレジストリに こm.フライトパワーズ/グーグル・フライトMCP として登録されています。ヘルスチェック: /ヘルス。

キーが必要ですか? RapidAPI の Google Flights Live API を購読してください — 無料枠あり — そして x-rapidapi-key をコピーしてください: https://rapidapi.com/mtnrabi/api/google-flights-live-api

まだキーがない場合? 無料サーバーから始めてください — 同じ検索ができ、サインアップ不要です: claude mcp add --transport http google-flights-free https://google-flights-lulu.flightpowers.com/mcp (広告付き:D 結果ごとに広告であることを明示したスポンサーカードが1件表示され、ファンアウトは最大15件に制限されます。さらに、スポンサーカードを表示できないクライアントでは、さらに制限される場合もあります。広告、15件の検索上限、クライアント側の制限が邪魔になったら、こちらに戻ってきてください。)

エージェントが得られるもの

日付の検索ではなく、運賃の質問に答えるツールが5つあります。

自由な質問ができます。 「10月のどの日でもいいのでスリランカへの片道格安便」の5月の都合のいい時期にローマで5〜7泊、テルアビブまたはラルナカ発」といった質問は、それぞれツール呼び出し1回で済みます。どちらのツールも、出発日の範囲、目的空港のリスト、(往復では)固定の帰国日つ日ではなく nights 値を受けてけ取り、内部で展開します。
価格が実に良いかを判断できます。 すべての結果に、ルートと期間ごとの Google 自身の履歴範囲 — price_insights_low、price_insights_high、B— そして price_range_in_relation_to_other_periods の low / typical / high 評価—が含まれます。これによって「それが209ドルは典型で、急いで買う必要はない notと言える答えができます。ただ数値引用だけではありません。
予約もできます(閲覧だけではありません)。 すべての結果はあ Google Flights への「buy_link」を含む。
使ったチケット数がわかる。 各応答に api_usage が含まれ、この呼び出しで使ったチケット数と、呼び出し元のプランの備蓄残量がわかります。使用状況レポートを参照してください。
検索内容がわかる。　各応答に search_coverage が含まれ、「その答えが拠って検索した日付と目的地」をモデルが正直に説明できます。

※結果はリアルタイム運賃です。数分でガバります — 運賃をキャッシュしたり過去の結果を再利用したりせず、データを取得した時点を明記して再検索してください。

キーを取得する(無料版あり)

このサーバーには自前の認証情報はありません。検索ごとに あなたのRapidAPIサブスクリプションに課金されるため、キーがリクエストと一緒に渡されます。

RapidAPI で Google Flights Live API を申し込む: : https://rapidapi.com/mtnrabi/api/google-flights-live-api
自分の x-rapidapi-key をつコピーします。
それを次の3つの方法のどれか、サーバーに渡します。

キーがない場合、ツールは静かに失敗せず何も消費しません。needs_api_key: true とサインアップURL、および文章で、モデルが読み上げるための説明を返します。

キーを渡す3つの方法

方法	渡し方	使うとき
ヘッダー(推奨)	`--header "x-rapidapi-key: YOUR_RAPAPI_KEY"`	ヘッダーを設定できる環境。キーがURLに入らず、結果としてプロキシ・アクセスログに残らない。
クエリパラメータ	`https://google-flights-mcp.flightpowers.com/mcp?rapidapi_key=YOUR_RAPIDAPI_KEY`	URLだけを貼り付け可能なホスト — 主要因のWeb「カスタムコネクタダイアログ」に対応。
クライアントのAPIキー欄	クライアント自身の「APIキー」欄へ貼り付ける。	`authorization: Bearer <key>` か `x-api-key` を送るホスト。Smithery の設定フォーム(`config.rapidApiKey=`)にも対応。

最初に設定済みで空でない項目が、この順で採用されます。キーがセンターのログに磳まれること、エラーメッセージに出力されること、またはツールの応答内に置かれることは、一切ありません。

ツール関数

ツール	機能・仕様
`search_oneway_flights`	片道のリアルタイム運賃を検索。入力:出発地のIATA、目的地IATAまたはそれらのリスト、さらに出発指定日(年月日)か期間範囲を使う。戻るもの: 運賃、航空会社、所要時間、乗り継ぎ回数、`buy_link`、Google の履歴価格帯(妥当性判断に使用)。「任意の日付範囲」も含め(はいつのワンツール呼び出しで扱えます — 1日ずつの呼び出しではありません。
`search_roundtrip_flights`	リアルタイムの往復運賃(出発/復路).往復をセットにした区間単価として計算。入力がそれぞれ、出発地、目的地(リスト可)、出発日あるいは日付範囲と、`return_date` か `nights`(宿泊数・単独か[5,6,7]などのリスト)のどちらか。出力: 合計金額、区間ごとの航空会社と停機・所要時間、そして全体の`buy_link`1件。

`search_oneway_flights`

search_oneway_flights(
    from_airport: str,                     # origin IATA, e.g. "TLV"
    to_airport: str | list[str],           # destination IATA, or a list to compare
    departure_date: str | None = None,     # "YYYY-MM-DD"
    departure_date_from: str | None = None,# first date of a range
    departure_date_to: str | None = None,  # last date of a range
    max_stops: int | None = None,          # 0 = non-stop only
    airline_codes: list[str] | None = None,
    exclude_airline_codes: list[str] | None = None,
    departure_time_min: int | None = None, # hour, 0-23
    departure_time_max: int | None = None,
    arrival_time_min: int | None = None,
    arrival_time_max: int | None = None,
    currency: str = "usd",
    max_price: int | None = None,
    seat_type: int | None = None,          # 1 economy, 2 premium economy, 3 business, 4 first
    passengers: list[int] | None = None,   # [adults, children, infants]
    sort_by: str = "best",                 # "best" | "price" | "duration"
    limit: int = 10,                       # results returned after merge + sort
    max_searches: int | None = None,       # cap the billed requests this call may make
    use_fallback: bool = False,            # slower, fewer empty results on hard routes
)

`search_roundtrip_flights`

search_roundtrip_flights(
    from_airport: str,
    to_airport: str | list[str],
    departure_date: str | None = None,
    departure_date_from: str | None = None,
    departure_date_to: str | None = None,
    return_date: str | None = None,        # use this OR nights, not both
    nights: int | list[int] | None = None, # e.g. 7, or [5, 6, 7]
    max_departure_stops: int | None = None,
    max_return_stops: int | None = None,
    departure_airline_codes: list[str] | None = None,
    return_airline_codes: list[str] | None = None,
    currency: str = "usd",
    max_price: int | None = None,
    seat_type: int | None = None,
    passengers: list[int] | None = None,
    sort_by: str = "best",
    limit: int = 10,
    max_searches: int | None = None,
    use_fallback: bool = False,
)

「sort_by」は、検索件数に関係なく、実行した全検索をマージした結果セットに対してサーバー側でソートにあたるため、予測可能な並び順を返します。

動きの作業例

ユーザー: 「テル・アビブにいます。5月前半にどこかで出発して、ローマかアテネにa宝贝1週間、一番安く済ませたい」

呼び出し1回:

{
  "name": "search_roundtrip_flights",
  "arguments": {
    "from_airport": "TLV",
    "to_airport": ["FCO", "ATH"],
    "departure_date_from": "2026-05-01",
    "departure_date_to": "2026-05-15",
    "nights": 7,
    "sort_by": "price",
    "limit": 5
  }
}

この一見ると、15日付×2目的地=30組合わせ、これは呼び出し1回での時限ぴったりです。リマスは次の形になります(フィールド名は実際のもの。下の値段は説明用の一例で、実際の査定ではありません — ライフで見る場合は実際の呼

変数	デフォルト	重要な理由
`MAX_SEARCHES_PER_TOOL_CALL`	`30`	ツール呼び出し1回あたりのファンアウト上限。ハード上限の60にクランプされる。
`MAX_CONCURRENT_SEARCHES`	`10`	ファンアウトの同時実行数。
`MAX_HTTP_CONNECTIONS`	`60`	接続プールの上限。サーバーレスインスタンスはファイルディスクリプタプールを共有する。
`REQUEST_TIMEOUT_SECONDS`	`105`	上流側の上限に一致させているため、こちら側が先にタイムアウトすることはない。
`DEFAULT_RESULT_LIMIT`	`10`	個々の上流検索で要求される結果件数。
`SIGNUP_URL`	RapidAPI のリスティング	キーなしでアクセスしたユーザーに案内される URL。
`MCP_PUBLIC_URL`	`http://localhost:8000/mcp`	`/health` が報告する URL。
`RAPIDAPI_KEY`	(空)	本番環境では空のままにすること。設定されている場合、キーなしのすべての呼び出しがそのサブスクリプション上で処理され、課金される。サーバーは起動時に警告をログし、`/health` は `server_side_key_configured` を報告する。
`METRICS_TOKEN`	(空)	設定すると、`/metrics` は `x-metrics-token` ヘッダーを要求する。
`LOG_PATH`	(空)	空だとファイルシンクが無効になり、stdout の `MCP_CALL` 行が記録として残る。サーバーレスではこれが正しい動作。

運用ルート：GET /health（公開・認証不要。レジストリがポーリングする）、GET /metrics、GET /metrics/calls?hours=24。

デプロイ先は Vercel で、api/index.py（FastMCP にライフサイクルと stateless_http=True を渡す FastAPI ラッパー）を経由する。正規のMCPパスは /mcp で、末尾スラッシュなし。

実際のキーをコミットしないこと。example.env にはプレースホルダーが同梱されている。その状態を維持すること。

非提携

これは、公開されている航空運賃の価格を返す独立APIです。Google との提携や、Google からの推薦、スポンサー提供は一切ありません。「Google Flights」は、公開データソースを説明するためにのみ使用されています。運賃は上流プロバイダーから供給され、常に変動し、保証されるものではありません。購入前に必ず航空会社または予約サイトで価格を確認してください。

Available Tools

4 tools

find_hotel_by_nameFlightPowers: find one hotel by nameA

Read-only

Inspect

FlightPowers single-property lookup: live Booking.com availability and pricing for one named property. Input: the hotel name a person would type (adding the city helps when a chain has many properties) plus check-in and check-out dates -- no internal property ID needed, the resolution is done for you. Returns the property's price, review score, room type and a booking link. Use it to check one specific hotel, or to track a single property's price over time.

price_as_seen_from prices the stay as a shopper resident in that country would see it. Gaps are real but usually modest and property-dependent, and rates move between calls, so call each country a few times on this same property before reporting a gap.

Rates go stale within minutes: never reuse an earlier result.

Requires the caller's own RapidAPI key for the Booking Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/booking-live-api, then pass it as an x-rapidapi-key header (preferred), a ?rapidapi_key= query parameter on the server URL, or your client's own API key field -- first non-empty wins. Usage counts against the caller's own RapidAPI plan, not ours; every response reports what it spent and what is left in api_usage.

ParametersJSON Schema

Name	Required	Description
`adults`	No	Number of adult guests.
`children`	No	Number of children sharing the room.
`currency`	No	ISO currency code for the prices returned, e.g. "usd".
`hotel_name`	Yes	The property name a person would type, e.g. "Hotel Artemide". Adding the city ("Hotel Artemide Rome") disambiguates a chain with many properties. No internal property ID is needed.
`checkin_date`	Yes	First night of the stay, "YYYY-MM-DD".
`checkout_date`	Yes	Departure morning, "YYYY-MM-DD". Must be after checkin_date.
`price_as_seen_from`	No	Two-letter country code, e.g. "de". Prices the stay as a shopper resident in that country would see it. Call each country a few times on this same property before reporting a gap, because rates move between calls and gaps are usually modest and property-dependent.

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	Yes	The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
`api_usage`	No	What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed.
`signup_url`	No	Where the caller subscribes or changes plan.
`result_count`	No
`needs_api_key`	No	True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it.
`applied_filters`	No	Which of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through.
`quota_exhausted`	No	True when the caller's RapidAPI plan has no requests left for the current period.

TDQS

A4.3/5.0

Behavior5/5

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

The description fully discloses live external API behavior, the need for an API key, usage costs, and that rates can change between calls. It also warns 'never reuse an earlier result,' which is meaningful behavioral context beyond the readOnly/Idempotent annotations.

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

Conciseness4/5

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

The description is organized into clear, purposeful sections: the core lookup behavior, the price_as_seen_from caveat, freshness warning, and API key instructions. While a bit long, every section adds operational value and the structure makes it easy to scan.

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

Completeness4/5

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

It covers what the tool returns, authentication requirements, cost attribution, freshness expectations, and a specific pricing-locale caveat. That is sufficient for correct invocation, though the exact output schema shape is not spelled out in the description.

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 input schema already has 100% coverage with detailed parameter descriptions, including disambiguation guidance and checkout-after-checkin constraints. The prose mostly repeats these details rather than adding new parameter-level meaning, so it meets the baseline but does not go beyond it.

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

Purpose5/5

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

The description opens with 'FlightPowers single-property lookup' and says it returns availability, pricing, review score, room type, and a booking link. This clearly defines the tool's exact function and distinguishes it from broad hotel search or flight search siblings.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use it 'to check one specific hotel, or to track a single property's price over time,' which gives clear usage guidance. It does not explicitly mention the sibling search_hotels tool as the alternative for broad searches, but the 'single-property' framing makes that distinction clear.

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

search_hotelsFlightPowers: search hotelsA

Read-only

Inspect

FlightPowers hotel search: live Booking.com availability and nightly prices for a destination and date range. Input: a free-text destination the way a person would say it ("Rome", "Tokyo Shibuya"), plus check-in and check-out dates. Returns each property's price, review score, room type, location and a booking link.

Set price_as_seen_from to a two-letter country code to price the same stay the way a shopper resident in that country would see it, which no other travel tool here can do. Gaps are real but usually modest and property-dependent, and rates move between calls, so hold one named property fixed, call each country a few times, and never read one call per country as a gap.

Rates go stale within minutes: never reuse an earlier result, search again.

ParametersJSON Schema

Name	Required	Description
`adults`	No	Number of adult guests. Defaults to the upstream default when omitted.
`filters`	No	Property filters to apply, e.g. ["free_cancellation", "breakfast_included"]. An unknown name is rejected with the list of valid ones rather than being ignored.
`children`	No	Number of children sharing the room.
`currency`	No	ISO currency code for the prices returned, e.g. "usd".
`destination`	Yes	Where to stay, in free text the way a person would say it, e.g. "Rome" or "Tokyo Shibuya". A city, district, landmark or region all work; no internal location ID is needed.
`checkin_date`	Yes	First night of the stay, "YYYY-MM-DD".
`checkout_date`	Yes	Departure morning, "YYYY-MM-DD". Must be after checkin_date.
`budget_per_night`	No	Only return properties at or below this nightly price, in `currency`.
`price_as_seen_from`	No	Two-letter country code, e.g. "de". Prices the stay through a residential connection in that country, so the result is what a shopper resident there would be quoted. For a rate-parity check hold one named property fixed and call each country a few times, because rates move between calls and one call per country can show a gap that is not there. Omit it for a neutral price.

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	Yes	The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
`api_usage`	No	What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed.
`signup_url`	No	Where the caller subscribes or changes plan.
`result_count`	No
`needs_api_key`	No	True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it.
`applied_filters`	No	Which of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through.
`quota_exhausted`	No	True when the caller's RapidAPI plan has no requests left for the current period.

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses several important behaviors: results are live and go stale within minutes, unknown filters are rejected rather than ignored, API usage is charged to the caller's own plan, and the first non-empty API key source wins. This goes well beyond what the annotations alone convey.

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

Conciseness4/5

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

The description is somewhat long, but nearly every sentence carries necessary operational or behavioral information. The repetition around rate-parity checks is slightly verbose but serves an important warning purpose, so the length is justified overall.

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

Completeness5/5

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

The description covers what the tool returns, how to supply inputs, how pricing and filtering behave, how rate-parity checks should be performed, and how API keys and usage accounting work. Combined with the output schema, an agent has everything needed to invoke and interpret this tool correctly.

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

Parameters5/5

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

The schema already covers 100% of parameters with meaningful descriptions, and the tool description adds further value by explaining the semantics of price_as_seen_from, including the country-code behavior and how to interpret rate-parity results. Parameter meaning is fully clear.

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

Purpose5/5

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

The description clearly states that this is a hotel search tool for live Booking.com availability and nightly prices by destination and date range. It is immediately distinguishable from the flight-search siblings, and the title reinforces the purpose.

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

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives direct guidance on when to use the tool and how to use it correctly, including the rate-parity workflow with price_as_seen_from, the need to hold one property fixed, and the warning that rates move between calls. It also explains API key handling and billing, leaving no ambiguity about operational usage.

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

search_oneway_flightsFlightPowers: search one-way flightsA

Read-only

Inspect

FlightPowers one-way fare search: live prices read from Google Flights. Input: origin and destination IATA codes -- the destination may be several codes, as "BCN,LIS,ATH" or ["BCN","LIS","ATH"] -- plus either one departure date or a date range. Returns each flight's price, airline, duration, stops, a bookable buy_link, and Google's historical price range (price_insights_low / price_insights_high) so you can say whether a fare is actually a good deal.

Use it for any one-way fare question, including open-ended ones. For a flexible search make ONE call with a date range and/or several destinations -- do NOT call it once per date. 'Cheapest flight to Sri Lanka anywhere in October' is one call, not thirty.

Each date/destination combination is one billed request; the count and the plan's remaining quota come back in api_usage.

by_destination carries one entry per destination you asked for -- empty ones included, each with a reason -- so read it before telling a user a destination has no flights.

Requires the caller's own RapidAPI key for the Google Flights Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/google-flights-live-api, then pass it as an x-rapidapi-key header (preferred), a ?rapidapi_key= query parameter on the server URL, or your client's own API key field -- first non-empty wins. Usage counts against the caller's own RapidAPI plan, not ours; every response reports what it spent and what is left in api_usage.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum flights to return, after merging and sorting.
`sort_by`	No	"best", "price", or "duration". Applied across all results.	best
`currency`	No	ISO currency code, default "usd".	usd
`max_price`	No	Only return flights at or below this price.
`max_stops`	No	Maximum stops per flight. 0 means non-stop only.
`seat_type`	No	1 economy, 2 premium economy, 3 business, 4 first.
`passengers`	No	Passenger counts as [adults, children, infants].
`to_airport`	Yes	Destination airport. One IATA code ("BCN"), several separated by commas ("BCN,LIS,ATH"), or a list (["BCN","LIS","ATH"]) -- every shape is accepted and the destinations are compared in the same search.
`from_airport`	Yes	Origin IATA code, e.g. "TLV". One origin per search; a second one is refused rather than searched.
`max_searches`	No	Cap the billed requests this call may make. Lower it to spend less of the plan's quota on a wide search; the range is then sampled evenly rather than cut short.
`use_fallback`	No	Leave unset. Switches the search to a second, independent flight data source instead of the usual Google Flights page read. Unset already escalates to that source once, automatically, after a search's retries have failed. true forces it inline on every attempt -- much slower, and it can time out. false disables it entirely, that automatic retry included.
`airline_codes`	No	Restrict to these airline codes, e.g. ["LY"].
`departure_date`	No	Single departure date, "YYYY-MM-DD".
`arrival_time_max`	No	Latest arrival hour, 0-23.
`arrival_time_min`	No	Earliest arrival hour, 0-23.
`departure_date_to`	No	Last date of a departure range.
`departure_time_max`	No	Latest departure hour, 0-23.
`departure_time_min`	No	Earliest departure hour, 0-23.
`departure_date_from`	No	First date of a departure range.
`exclude_airline_codes`	No	Exclude these airline codes.

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No	Present when there is something the model must relay to the user rather than silently absorb -- no results, a degraded search, a missing key or a spent quota.
`partial`	No	Present when some searches failed but others succeeded. Plain text saying how much of the request the results cover.
`results`	Yes	The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
`api_usage`	No	What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed.
`signup_url`	No	Where the caller subscribes or changes plan.
`result_count`	No
`needs_api_key`	No	True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it.
`search_status`	No	Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry.
`by_destination`	No	One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows. Read this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `rows` are the same row objects that are in `results`, in the same order -- nothing here is data the answer does not already contain.
`quota_exhausted`	No	True when the caller's RapidAPI plan has no requests left for the current period.
`search_coverage`	No	What was actually searched. Present whether or not the request was truncated, so a model can state honestly what its answer rests on.

TDQS

A5/5.0

Behavior5/5

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

The description discloses return fields (price, airline, duration, stops, buy_link, price_insights) and billing reporting via api_usage. It further explains fallback source behavior, max_searches sampling, and that usage counts against the caller's own RapidAPI plan, all beyond the annotations.

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?

Although lengthy, each paragraph serves a distinct purpose—result contents, invocation advice, billing, and API-key setup—and includes concrete examples without redundant filler. The structure is logical and easy to scan.

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

Completeness5/5

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

The description covers key operational concerns an external agent needs: API key requirements, quota reporting, multi-destination/date handling, and fallback behavior. Since an output schema is present, no additional return-value documentation is necessary.

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

Parameters5/5

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

All 20 parameters have schema descriptions, and the description adds practical semantics such as accepted shapes for to_airport, origin singularity, date-range versus single-date usage, and seat_type/passenger mappings. This goes well beyond the schema's basic property descriptions.

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

Purpose5/5

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

Title and first sentence explicitly state 'one-way fare search' and 'live prices read from Google Flights,' clearly distinguishing it from sibling roundtrip/hotel tools. The verb 'search' plus resource 'flights' makes the purpose unambiguous.

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

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance: 'Use it for any one-way fare question' and 'do NOT call it once per date,' with a concrete example of a single flexible search. It also explains API-key requirements, billing consequences, and that a second origin is refused rather than searched.

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

search_roundtrip_flightsFlightPowers: search round-trip flightsA

Read-only

Inspect

FlightPowers round-trip fare search: live prices read from Google Flights, priced as paired legs rather than two separate one-ways. Input: origin and destination IATA codes -- the destination may be several codes, as "BCN,LIS,ATH" or ["BCN","LIS","ATH"] -- a departure date or range, and either a return date or a trip length in nights. Returns the total price for both legs, per-leg airline, stops and duration, and a single bookable buy_link for the trip.

Use it for any return-trip fare question. For a flexible search make ONE call: pass departure_date_from / departure_date_to for the outbound range and nights instead of return_date to compare trip lengths -- '5 to 7 nights in Rome sometime in May' is one call.

Each date/destination combination is one billed request; the count and the plan's remaining quota come back in api_usage.

by_destination carries one entry per destination you asked for -- empty ones included, each with a reason -- so read it before telling a user a destination has no flights.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum trips to return, after merging and sorting.
`nights`	No	Trip length in nights; a number, or a list like [5, 6, 7]. The return date is derived from each departure date.
`sort_by`	No	"best", "price", or "duration". Applied across all results.	best
`currency`	No	ISO currency code, default "usd".	usd
`max_price`	No	Only return trips at or below this total price.
`seat_type`	No	1 economy, 2 premium economy, 3 business, 4 first.
`passengers`	No	Passenger counts as [adults, children, infants].
`to_airport`	Yes	Destination airport. One IATA code ("BCN"), several separated by commas ("BCN,LIS,ATH"), or a list (["BCN","LIS","ATH"]) -- every shape is accepted and the destinations are compared in the same search.
`return_date`	No	Fixed return date. Use this OR nights, not both.
`from_airport`	Yes	Origin IATA code, e.g. "TLV". One origin per search; a second one is refused rather than searched.
`max_searches`	No	Cap the billed requests this call may make. Lower it to spend less of the plan's quota on a wide search; the range is then sampled evenly rather than cut short.
`use_fallback`	No	Leave unset. Switches the search to a second, independent flight data source instead of the usual Google Flights page read. Unset already escalates to that source once, automatically, after a search's retries have failed. true forces it inline on every attempt -- much slower, and it can time out. false disables it entirely, that automatic retry included.
`departure_date`	No	Single outbound date, "YYYY-MM-DD".
`max_return_stops`	No	Maximum stops on the return leg.
`departure_date_to`	No	Last date of an outbound range.
`departure_date_from`	No	First date of an outbound range.
`max_departure_stops`	No	Maximum stops on the outbound leg.
`return_airline_codes`	No	Restrict the return leg to these airlines.
`departure_airline_codes`	No	Restrict the outbound leg to these airlines.

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No	Present when there is something the model must relay to the user rather than silently absorb -- no results, a degraded search, a missing key or a spent quota.
`partial`	No	Present when some searches failed but others succeeded. Plain text saying how much of the request the results cover.
`results`	Yes	The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
`api_usage`	No	What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed.
`signup_url`	No	Where the caller subscribes or changes plan.
`result_count`	No
`needs_api_key`	No	True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it.
`search_status`	No	Whether the underlying search actually completed, read from the backend's X-Search-Status header. 'ok': every combination searched returned results. 'empty': the search completed and Google genuinely has no itineraries for it -- a real answer, not a failure. 'partial': some combinations returned results and some failed, so the list is incomplete. 'degraded': every combination failed, so the search did not happen and an empty list means nothing; this case is also flagged with isError: true and is safe to retry.
`by_destination`	No	One entry per destination the REQUEST asked for, in request order, present whether or not that destination has any flights in `results`. A destination with an empty `rows` array is a hole in the answer, and `reason` says which kind of hole: 'no_flights' (searched, answered, Google has nothing), 'search_failed' (searched and the search errored, so nothing is known), 'not_in_limit' (searched, found flights, none fitted in `limit`) or 'not_searched' (never searched -- the per-call fan-out cap sampled it away). 'ok' means it has rows. Read this rather than inferring coverage from `results`: a destination missing from `results` looks identical to one that has no flights, and they are not the same answer. `rows` are the same row objects that are in `results`, in the same order -- nothing here is data the answer does not already contain.
`quota_exhausted`	No	True when the caller's RapidAPI plan has no requests left for the current period.
`search_coverage`	No	What was actually searched. Present whether or not the request was truncated, so a model can state honestly what its answer rests on.

TDQS

A4.9/5.0

Behavior5/5

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

Discloses external RapidAPI dependency, caller-provided key requirements, billing/quota consumption, retry and fallback behavior, and the fact that each destination/date combination is a billed request. This goes beyond the read-only annotation and gives accurate expectations of side effects.

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

Conciseness4/5

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

The description is thorough but somewhat long, with some details repeated across paragraphs and parameter descriptions. However, the content is organized into clear topical paragraphs and nearly every sentence carries practical guidance, making the length justified overall.

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

Completeness5/5

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

Covers external API integration, authentication, billing, fallback source switching, result composition, and the meaning of api_usage and by_destination. Given the tool's complexity and external dependencies, the description contains all necessary context for correct invocation and interpretation.

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

Parameters5/5

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

Every schema parameter has a meaningful description, and the description adds important semantic details such as single-origin refusal, accepted destination formats, nights vs return_date exclusivity, and even sampling behavior for max_searches. The prose supplements the schema rather than merely repeating it.

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

Purpose5/5

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

Clearly identifies the tool as a round-trip flight fare search reading live prices from Google Flights and pricing paired legs, not separate one-ways. This distinguishes it from the sibling one-way search tool without ambiguity.

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

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly directs use for any return-trip fare question and gives concrete guidance for flexible date ranges, multi-destination searches, and quota control via max_searches. The instructions about return_date vs nights and fallback behavior leave little room for misuse.

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.

4 tool updatesv1.0.0Sep 8, 2026
- First observedfind_hotel_by_name
- First observedsearch_hotels
- First observedsearch_oneway_flights
- First observedsearch_roundtrip_flights

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

A4.6/5.0

Scored 2026-09-08 11:50 across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct query type: one-way flights, round-trip flights, general hotel search, and specific hotel lookup. Even the two hotel tools are easy to differentiate because one is broad destination search and the other is single-property lookup.

Naming Consistency4/5

Three tools follow the search_<subject> pattern: search_oneway_flights, search_roundtrip_flights, and search_hotels. find_hotel_by_name breaks the pattern by using find_ instead of search_, though it remains readable and predictable.

Tool Count5/5

Four tools is a well-scoped set for a travel-search server. Each tool earns its place and the count avoids both bloat and thinness.

Completeness4/5

The core search workflows are covered: one-way flights, round-trip flights, hotel search, and named-hotel lookup. Obvious gaps include multi-city flight search and airport/place code resolution, but agents can work around these with external knowledge or by combining existing tools.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

google-flightsOAuth
io.github.johnisanerd
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
Travel & Transportation Search
21
flightoracle B
io.tooloracle
Flight Intelligence MCP — search, cheapest dates, multi-city, airline compare via Google Flights
Travel & Transportation Search
82
Flaut.Travel A
travel.flaut
Flight search, airfare analytics, flexible destinations
Travel & Transportation
81
Ignav Flights A
io.github.gusgordon
Live flight prices and working booking links for AI agents and travel apps.
Travel & Transportation Search
221

Related MCP Servers

SkyOdyssey MCP
Travel & Transportation Search
maru-775
A
license
Not graded
quality
D
maintenance
Enables AI clients to explore cheapest destinations, optimize multi-leg flight itineraries, and reference airport/region data via MCP tools and resources.
Updated 7 months ago (2026-02-28 12:11 UTC)
MIT
Ignav Flights MCP Server
Travel & Transportation Search
gusgordon
A
license
Not graded
quality
D
maintenance
Provides live flight prices, booking links, and airport lookup via a hosted MCP server. Enables search for flights and direct booking URL retrieval.
Updated 2 months ago (2026-07-27 20:04 UTC)
1
MIT
Google Flights MCP Server
Research & Data Travel & Transportation Web Scraping
HasData
A
license
A
quality
A
maintenance
Enables MCP clients to search one-way, round-trip, and multi-city itineraries and retrieve fares, flight legs, carbon emissions and price history as structured JSON.
Updated 3 days ago (2026-10-08 10:46 UTC)
1
123 npm
50 PyPI
6
MIT
Google Flights MCP
Travel & Transportation Search
mtnrabi
A
license
Not graded
quality
D
maintenance
Enables real-time one-way and round-trip flight searches from any MCP client without an API key or account, returning live fares, historical price insights, and bookable links supported by disclosed sponsored cards.
Updated a month ago (2026-09-15 07:38 UTC)
1
MIT

Google Flights MCP — エージェントが日付範囲全体を横断検索できるリアルタイム運賃、広告なし

エージェントが得られるもの

キーを取得する(無料枠あり)

キーを渡す3つの方法

ツール

search_oneway_flights

search_roundtrip_flights

動作例

支出レポート(api_usage)

呼び出し1回 vs 呼び出し31回

ローカル開発

エージェントが得られるもの

キーを取得する(無料版あり)

キーを渡す3つの方法

ツール関数

search_oneway_flights

search_roundtrip_flights

動きの作業例

非提携

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`search_oneway_flights`

`search_roundtrip_flights`

支出レポート(`api_usage`)

`search_oneway_flights`

`search_roundtrip_flights`