Skip to main content
Glama
deenesjakoruzh
mtnrabi

google-flights-mcp

by mtnrabi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
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 Registry에 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 (광고 지원됨: 결과당 공개된 스폰서 카드 하나, fan-out 상한 15개, 그리고 스폰서 카드를 렌더링할 수 없는 클라이언트는 추가로 제한될 수 있습니다.) 광고, 15회 검색 상한, 또는 그러한 클라이언트 제약이 걸림돌이 되면 이곳으로 돌아오세요.

에이전트가 얻는 것

날짜 조회가 아닌 가격 질문에 답하는 두 가지 도구입니다.

  • 열린 질문을 물어보세요. "스리랑카행 가장 저렴한 편도, 10월 언제든", "로마에서 5~7박, 5월 중입니다. 텔아비브 또는 라르나카 출발" — 각 질문은 하나의 도구 호출입니다. 두 도구 모두 출발 날짜 범위, 목적지 공항 목록, 그리고 (왕복일 때) 고정 귀국 날짜 대신에 nights 값을 받아 내부에서 확장됩니다.

  • 가격이 실제로 좋은 가격인지 알 수 있습니다. 모든 결과에는 그 노선과 여행 기간에 대한 Google 자체의 과거 가격 범위가 들어 있습니다 — price_insights_low, price_insights_high, 그리고 low / typical / high로 판정하는 price_range_in_relation_to_other_periods. 덕분에 에이전트는 그냥 숫자만 말하지 않고 "$209는 여기서 평균적인 가격이니 지금 당장 급하지 않습니다"라고 답할 수 있습니다.

  • 예약까지 가능하고, 조회에 그치지 않습니다. 모든 결과에는 Google Flights로 가는 buy_link가 포함됩니다.

  • 무엇을 소비했는지 알 수 있습니다. 모든 응답에는 api_usage — 이 호출이 사용한 요청 수와 호출자 플랜에 남은 사용량이 담깁니다. 지출 보고를 참고하세요.

  • 무엇을 검색했는지 알 수 있습니다. 모든 응답에는 search_coverage가 담겨 있어, 모델이 어떤 날짜와 목적지를 대상으로 한 정료를 답했다고 정직하게 말할 수 있습니다.

결과는 실시간 요금입니다. 몇 분이면 사라됩니다 — 요금을 캐시하거나 이전 결과를 다시 사용하지 마세요; 다시 검색하고 데이터를 각색한 시점을 함께 말하세요.

Related MCP server: Ignav Flights MCP Server

키 받기 (무료 티어 사용 가능)

이 서버는 자체적인 업스트림 인증 정보를 갖지 않습니다. 모든 검색은 사용자의 RapidAPI 구독으로 계정되기 때문에 키가 요청과 함께 전달되는 것입니다.

  1. Google Flights Live API를 구독하세요: https://rapidapi.com/mtnrabi/api/google-flights-live-api

  2. x-rapidapi-key를 복사하세요.

  3. 아래 세 가지 방법 중 하나로 서버에 전달하세요.

키가 없으면 도구는 조용히 실패하지 않고 비용도 지출하지 않습니다. 그냐의 대신 needs_api_key: true와 함께 가입 URL 및 이 안내 문구를 반환하며, 모델이 사용자에게 그대로 읽어 전달할 수 있도록 문장으로 작성됩니다.

키를 전달하는 세 가지 방법

방식

사용법

어떤 때에 사용하는가

헤더 (권장)

--header "x-rapidapi-key: YOUR_RAPIDAPI_KEY"

헤더를 설정할 수 있는 모든 곳. 키가 URL에도, 따라서 프록시 로그나 액세스 로그에도 남지 않습니다.

쿼리 매개변수

https://google-flights-mcp.flightpowers.com/mcp?rapidapi_key=YOUR_RAPIDAPI_KEY

URL만 붙여넣을 수 있는 호스트 — claude.ai의 custom-connector 대화상자가 해당합니다.

클라이언트 API-key 필드

클라이언트의 "API key" 상자에 키를 붙여넣기

authorization: Bearer <key> 또는 x-api-key를 보내는 호스트. Smithery의 저장된 구성을 사용할 때도 config.rapidApiKey= 값이 허용됩니다.

빈 값을 갖는 데이터가 아닌 첫 번째 소스가 이 순서로 적용됩니다. 키는 로그에 남지도, 오류 메시지에 표시되지도, 도구 응답에 절대 포함되지 않습니다.

도구

도구

하는 일

search_oneway_flights

실시간 편도 요금. 입력: 출발지 IATA, 목적지 IATA 또는 목록, 그리고 출발 날짜 하나 또는 날짜 범위. 가격, 항공사, 소요 시간, 경유 수, buy_link, 그리고 Google의 과거 가격 범위를 반환해 요금을 판단할 수 있게 합니다. 편도 질문에 모두 사용합니다. 개방형 질문을 포함해 — 모든 날짜마다가 아닌 범위 한 번아 실행되는 호출 한 번으로 됩니다.

search_roundtrip_flights

실시간 왕복 요금. 매우른 두 개의 구간편으로 가격이 정해지며, 두 개의 별도 편도가 아닏니다. 출발지, 목적지, 출발 날짜 또는 날짜 범위, 그리고 return_date 또는 nights 여행 기간(숫자 또는 [5,6,7] 같은 리스트인)을 인자로 받습니다. 총 가격, 구간별 항공사/경유/소요시간, 그리고 한 항 하여줄 buy_link를 반환합니다.

sort_by는 이 서버가 실행한 검색 결과 전체를 병합한 뒤 이 서버에서 적용되므로, 조합이 몇 개로 확장되는 몇 가지와 무관하게 일관된 결과를 반환합니다.

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,
)

soup_by가 이 서버에서, 서버가 실행한 모든 검색을 병합한 결과를 대상으로 적용되므로, 얼마나 많은 조합으로 확장되는지가 항상 같은 결과를 보장합니다.

실제 예시

사용자: "텔 아비브에 있어요. 로마이나 아테네로 가장 저렴한 1주 여행, 출발도 5월 상반기 중 아무 日환 좋습니다."

한 번의 호출:

{
  "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가 반환되고, 비용은 0이며, 해결 방법이 함께 제공됩니다. RapidAPI 키는 유효하지만 이 API에 구독하지 않은 경우가 가장 많은 원인입니다.

  • 플랜 소진. quota_exhausted: true가 api_usage와 함께 반환되며, 범위를 좁히면 남은 쿼터를 더 오래 사용할 수 있다는 점을 알려줍니다.

지출 보고 (api_usage)

비용은 사용자의 것이기 때문에 미터기가 보여야 합니다. 모든 성공 응답에 다음이 포함됩니다:

필드

의미

requests_used_by_this_call

이번 하나의 도구 호출이 이때씩 사용한 청구 대상 요청 수.

plan_requests_remaining

이번 기간에 사용자의 RapidAPI 플랜에 남은 요청 수.

plan_requests_limit

이번 기간에 할당된 플랜 요청 한도.

note

위 내용을 문단으로 한 번 묶어서, 사용자가 먼저 물어보나 어쨌든 모델이 전달할 수 있는 문구.

plan_requests_remaining과 plan_requests_limit는 업스트림 응답에서 가져온 것이며, 업스트림이 제공하지 않으면 생랍니다. note는 그에 맞춰 조정됩니다. 모델이 말로 전달해야 하는 원칙은 날짜 하나 × 목적지 하나 = 청구 요청 하나입니다.

비용 조절 장치를 효과가 큰 순서대로 나열하면: 호출별 max_searches를 낮추거나(넓은 질문에 더 적게 요청), 날짜 범위를 좁히거나, 목적지 목록을 짧게 하는 것입니다.

한 번의 호출 vs 열 번의 호출

기본 REST API는 호출당 정확히 하나의 (출발지, 목적지, 날짜) 조합만 받습니다. 날짜별로 통과형 호출을 비교하면 "10월 한 달리 스리랑카 어디든 가장 저렴한"은 31번의 개별 도구 호출이 됩니다 — 모델이라 한다.* 31번의 왕복 동작, 31번의 맥락을 놓치를 위험, 그리고 물건 내용은 사용자가 사후에야 발견게 됩니다.

여기서는 한 번의 호출입니다. 확장은 동시에, 한도를 정해 서버 측에서 실행되면서, 전체 범위에서 균등 추출되고, buy_link에서 중복 제거되며, sort_by로 정렬되고, search_coverage와 api_usage로 정확하게 보고됩니다.

비교 항목

이 서버 (유료)

무료 서버

호출당확장

30개 유지(하드 상한 60개; max_searches로 호출별로 조정 가능)

15개

비용

없음

결과당 공개된 스폰서 카드 하나

키

사용자 고유의 RapidAPI API

필요 없음

지출 보고

모든 응답에 api_usage

없음

디렉터리 등록 가능

예

아니오

이 서버에는 전혀 광고가 조시도 없습니다 — 취햟이 아니르제휵식 때문입니다. Anthrustic의 연결터 디렉터리 정책구과 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

같은 방:: 라이언트가 로컬 process를 가리킬 수п드:

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

Config은 example.env에 있습니다. 모든 변수는 친에 문서화되어 있습니다. 중요한 변수들:

변수

기본값

중요성

MAX_SEARCHES_PER_TOOL_CALL

30

호출당 팬아웃 상한. 하드 최대 60으로 제한됩니다.

MAX_CONCURRENT_SEARCHES

10

팬아웃의 동시성.

MAX_HTTP_CONNECTIONS

60

연결 풀 상한. 서버리스 인스턴스는 파일 디스크립터 풀을 공유합니다.

REQUEST_TIMEOUT_SECONDS

105

업스트림 상한과 일치하므로 이쪽이 먼저 타임아웃되지 않습니다.

DEFAULT_RESULT_LIMIT

10

개별 업스트림 검색당 요청되는 결과 수.

SIGNUP_URL

RapidAPI listing

키 없이 접근하는 사용자에게 다시 안내되는 URL.

MCP_PUBLIC_URL

http://localhost:8000/mcp

/health에서 보고됩니다.

RAPIDAPI_KEY

(empty)

프로덕션에서는 비워 두세요. 설정하면 모든 키 없는 호출자가 해당 구독으로 서비스되고 청구됩니다. 서버는 시작 시 경고를 기록하고 /health는 server_side_key_configured를 보고합니다.

METRICS_TOKEN

(empty)

설정하면 /metrics는 x-metrics-token 헤더를 요구합니다.

LOG_PATH

(empty)

비어 있으면 파일 싱크가 비활성화되고 stdout MCP_CALL 라인이 기록으로 남습니다. 서버리스에서 올바른 동작입니다.

운영 라우트: GET /health(공개, 인증 불필요 — 레지스트리가 폴링), GET /metrics, GET /metrics/calls?hours=24.

배포 대상은 api/index.py(FastMCP에 수명 주기와 stateless_http=True를 전달하는 FastAPI 래퍼)를 통한 Vercel입니다. 표준 MCP 경로는 /mcp이며 후행 슬래시가 없습니다.

실제 키를 커밋하지 마세요. example.env는 플레이스홀더와 함께 제공되며 그 상태를 유지하세요.

비제휴 고지

이는 공개적으로 제공되는 항공편 가격을 반환하는 독립 API입니다. 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
NameRequiredDescriptionDefault
adultsNoNumber of adult guests.
childrenNoNumber of children sharing the room.
currencyNoISO currency code for the prices returned, e.g. "usd".
hotel_nameYesThe 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_dateYesFirst night of the stay, "YYYY-MM-DD".
checkout_dateYesDeparture morning, "YYYY-MM-DD". Must be after checkin_date.
price_as_seen_fromNoTwo-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
NameRequiredDescription
messageNo
resultsYesThe itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
api_usageNoWhat 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_urlNoWhere the caller subscribes or changes plan.
result_countNo
needs_api_keyNoTrue 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_filtersNoWhich of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through.
quota_exhaustedNoTrue 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.

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
NameRequiredDescriptionDefault
adultsNoNumber of adult guests. Defaults to the upstream default when omitted.
filtersNoProperty filters to apply, e.g. ["free_cancellation", "breakfast_included"]. An unknown name is rejected with the list of valid ones rather than being ignored.
childrenNoNumber of children sharing the room.
currencyNoISO currency code for the prices returned, e.g. "usd".
destinationYesWhere 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_dateYesFirst night of the stay, "YYYY-MM-DD".
checkout_dateYesDeparture morning, "YYYY-MM-DD". Must be after checkin_date.
budget_per_nightNoOnly return properties at or below this nightly price, in `currency`.
price_as_seen_fromNoTwo-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
NameRequiredDescription
messageNo
resultsYesThe itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
api_usageNoWhat 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_urlNoWhere the caller subscribes or changes plan.
result_countNo
needs_api_keyNoTrue 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_filtersNoWhich of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through.
quota_exhaustedNoTrue 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
NameRequiredDescriptionDefault
limitNoMaximum flights to return, after merging and sorting.
sort_byNo"best", "price", or "duration". Applied across all results.best
currencyNoISO currency code, default "usd".usd
max_priceNoOnly return flights at or below this price.
max_stopsNoMaximum stops per flight. 0 means non-stop only.
seat_typeNo1 economy, 2 premium economy, 3 business, 4 first.
passengersNoPassenger counts as [adults, children, infants].
to_airportYesDestination 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_airportYesOrigin IATA code, e.g. "TLV". One origin per search; a second one is refused rather than searched.
max_searchesNoCap 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_fallbackNoLeave 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_codesNoRestrict to these airline codes, e.g. ["LY"].
departure_dateNoSingle departure date, "YYYY-MM-DD".
arrival_time_maxNoLatest arrival hour, 0-23.
arrival_time_minNoEarliest arrival hour, 0-23.
departure_date_toNoLast date of a departure range.
departure_time_maxNoLatest departure hour, 0-23.
departure_time_minNoEarliest departure hour, 0-23.
departure_date_fromNoFirst date of a departure range.
exclude_airline_codesNoExclude these airline codes.

Output Schema

ParametersJSON Schema
NameRequiredDescription
messageNoPresent 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.
partialNoPresent when some searches failed but others succeeded. Plain text saying how much of the request the results cover.
resultsYesThe itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
api_usageNoWhat 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_urlNoWhere the caller subscribes or changes plan.
result_countNo
needs_api_keyNoTrue 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_statusNoWhether 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_destinationNoOne 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_exhaustedNoTrue when the caller's RapidAPI plan has no requests left for the current period.
search_coverageNoWhat 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.

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
NameRequiredDescriptionDefault
limitNoMaximum trips to return, after merging and sorting.
nightsNoTrip length in nights; a number, or a list like [5, 6, 7]. The return date is derived from each departure date.
sort_byNo"best", "price", or "duration". Applied across all results.best
currencyNoISO currency code, default "usd".usd
max_priceNoOnly return trips at or below this total price.
seat_typeNo1 economy, 2 premium economy, 3 business, 4 first.
passengersNoPassenger counts as [adults, children, infants].
to_airportYesDestination 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_dateNoFixed return date. Use this OR nights, not both.
from_airportYesOrigin IATA code, e.g. "TLV". One origin per search; a second one is refused rather than searched.
max_searchesNoCap 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_fallbackNoLeave 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_dateNoSingle outbound date, "YYYY-MM-DD".
max_return_stopsNoMaximum stops on the return leg.
departure_date_toNoLast date of an outbound range.
departure_date_fromNoFirst date of an outbound range.
max_departure_stopsNoMaximum stops on the outbound leg.
return_airline_codesNoRestrict the return leg to these airlines.
departure_airline_codesNoRestrict the outbound leg to these airlines.

Output Schema

ParametersJSON Schema
NameRequiredDescription
messageNoPresent 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.
partialNoPresent when some searches failed but others succeeded. Plain text saying how much of the request the results cover.
resultsYesThe itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
api_usageNoWhat 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_urlNoWhere the caller subscribes or changes plan.
result_countNo
needs_api_keyNoTrue 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_statusNoWhether 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_destinationNoOne 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_exhaustedNoTrue when the caller's RapidAPI plan has no requests left for the current period.
search_coverageNoWhat 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.

  1. 4 tool updatesv1.0.0
    • 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 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

Related MCP Connectors

Related MCP Servers

  • SkyOdyssey MCP

    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.
    MIT

  • Google Flights MCP

    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.
    1
    MIT