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 — tarifas en tiempo real que tu agente puede buscar en todo un rango de fechas, sin anuncios

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

Alojado. Nada que clonar, nada que compilar. Listado en el Registro oficial de MCP como com.flightpowers/google-flights-mcp. Comprobación de salud: /health.

¿Necesitas una clave? Suscríbete a la API de Google Flights Live en RapidAPI — plan gratuito disponible — y copia tu x-rapidapi-key: https://rapidapi.com/mtnrabi/api/google-flights-live-api

¿Aún no tienes clave? Empieza con el servidor gratuito — la misma búsqueda, sin registro: claude mcp add --transport http google-flights-free https://google-flights-lulu.flightpowers.com/mcp (con anuncios: una tarjeta patrocinada revelada por resultado, fan-out limitado a 15, y los clientes que no pueden mostrar la tarjeta patrocinada pueden verse limitados aún más.) Vuelve aquí cuando los anuncios, el límite de 15 búsquedas o esas restricciones de cliente te estorben.

Lo que obtiene tu agente

Dos herramientas que responden a una pregunta de tarifa, no a una consulta de fecha.

Haz preguntas abiertas. "Vuelo de ida más barato a Sri Lanka en cualquier día de octubre", "5 a 7 noches en Roma en algún momento de mayo, desde Tel Aviv o Larnaca" — cada una es una llamada de herramienta. Ambas herramientas aceptan un rango de fechas de salida, una lista de aeropuertos de destino y (en ida y vuelta) un valor nights en lugar de una fecha de regreso fija, y los expanden internamente.
Di si un precio es realmente bueno. Cada resultado incluye el rango histórico de Google para esa ruta y período — price_insights_low, price_insights_high, y un veredicto price_range_in_relation_to_other_periods de low / typical / high. Eso es lo que permite a un agente responder "$209 es típico aquí, no te apresures" en lugar de solo citar un número.
Reserva, no solo navegues. Cada resultado incluye un buy_link a Google Flights.
Sabe cuánto gastó. Cada respuesta incluye api_usage — solicitudes usadas por esta llamada y lo que queda en el plan del llamante. Ver Informe de gastos.
Sabe qué buscó. Cada respuesta incluye search_coverage, para que el modelo pueda decir honestamente en qué fechas y destinos se basa la respuesta.

Los resultados son tarifas en vivo. Se vuelven obsoletos en minutos: nunca guardes en caché una tarifa ni reutilices un resultado anterior; vuelve a buscar e indica cuándo se obtuvieron los datos.

Related MCP server: Ignav Flights MCP Server

Obtén una clave (plan gratuito disponible)

El servidor no posee ninguna credencial ascendente propia. Cada búsqueda se factura a tu suscripción de RapidAPI, por eso la clave viaja con la solicitud.

Suscríbete a la API de Google Flights Live: https://rapidapi.com/mtnrabi/api/google-flights-live-api
Copia tu x-rapidapi-key.
Pásala al servidor de cualquiera de las tres formas siguientes.

Si falta una clave, las herramientas no fallan en silencio ni gastan nada — devuelven needs_api_key: true con la URL de registro y estas instrucciones, redactadas para que el modelo te las lea.

Tres formas de pasar tu clave

Forma	Cómo	Cuándo usarla
Encabezado (preferido)	`--header "x-rapidapi-key: YOUR_RAPIDAPI_KEY"`	Cualquier cosa que te permita establecer encabezados. Las claves se mantienen fuera de las URL y, por tanto, fuera de los registros de proxy y acceso.
Parámetro de consulta	`https://google-flights-mcp.flightpowers.com/mcp?rapidapi_key=YOUR_RAPIDAPI_KEY`	Hosts que solo te permiten pegar una URL — el diálogo de conector personalizado de claude.ai es el caso que importa.
Campo de clave API del cliente	Pega la clave en el cuadro "API key" del propio cliente	Hosts que envían `authorization: Bearer <key>` o `x-api-key`. También se acepta el formulario de configuración guardada de Smithery (`config.rapidApiKey=`).

La primera fuente no vacía gana, en ese orden. La clave nunca se registra, nunca se repite en un mensaje de error y nunca se devuelve en una respuesta de herramienta.

Herramientas

Herramienta	Qué hace
`search_oneway_flights`	Tarifas de ida en tiempo real. Entrada: IATA de origen, IATA de destino o una lista, y ya sea una fecha de salida o un rango de fechas. Devuelve precio, aerolínea, duración, escalas, `buy_link` y el rango de precios histórico de Google para que puedas juzgar la tarifa. Úsala para cualquier pregunta de ida, incluidas las abiertas: una llamada con un rango, nunca una llamada por fecha.
`search_roundtrip_flights`	Tarifas de ida y vuelta en tiempo real, valoradas como tramos emparejados, no como dos idas. Entrada: origen, destino(s), una fecha de salida o rango, y ya sea un `return_date` o una duración de viaje en `nights` (un número o una lista como `[5,6,7]`). Devuelve el precio total, aerolínea/escalas/duración por tramo y un `buy_link` para el viaje.

`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 lo aplica este servidor sobre el conjunto de resultados combinado de cada búsqueda que ejecutó, por lo que es predecible sin importar cuántas combinaciones se expandieron.

Un ejemplo práctico

Usuario: "Estoy en Tel Aviv. Viaje de una semana más barato a Roma o Atenas, saliendo cualquier día de la primera mitad de mayo."

Una llamada:

{
  "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
  }
}

Eso se expande a 15 fechas × 2 destinos = 30 combinaciones, que es exactamente el límite por llamada. La forma de la respuesta (los nombres de los campos son reales; los valores a continuación son ilustrativos, no una cotización — ejecuta la llamada para obtener tarifas en vivo):

{
  "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."
  }
}

Otras formas de respuesta que puedes esperar, todas normales:

No hay vuelos en esas fechas. results: [] con un message — Google Flights realmente no devuelve nada para algunas combinaciones de ruta/fecha. No es un error. Prueba fechas cercanas, un aeropuerto cercano o use_fallback: true.
Algunas búsquedas fallaron. Un campo partial indica cuántas de las búsquedas ejecutadas fallaron, y los resultados cubren el resto.
Rango demasiado amplio. search_coverage.truncated: true más un note. El rango se muestrea uniformemente en toda la ventana (se conservan el primero y el último), no se corta — así que la muestra es representativa, no los primeros N días. Aumenta max_searches o reduce el rango para una cobertura más completa.
Sin clave / clave rechazada. needs_api_key: true, gasto cero, con la solución. Una clave de RapidAPI válida que no esté suscrita a esta API es la causa más común.
Plan agotado. quota_exhausted: true con api_usage, más un recordatorio de que reducir el rango hace que la cuota restante rinda más.

Informe de gastos (`api_usage`)

El dinero es tuyo, así que el contador es visible. Cada respuesta exitosa incluye:

Campo	Significado
`requests_used_by_this_call`	Solicitudes ascendentes facturadas que consumió esta llamada de herramienta.
`plan_requests_remaining`	Lo que queda en tu plan de RapidAPI este período.
`plan_requests_limit`	El límite de tu plan para el período.
`note`	Lo mismo en una frase, para que el modelo pueda transmitírtelo antes de que preguntes.

plan_requests_remaining y plan_requests_limit provienen de la respuesta ascendente y se omiten cuando el ascendente no los informa; el note se adapta. La regla que el modelo debe decir en voz alta: una fecha × un destino = una solicitud facturada.

Controles de coste, en orden de contundencia: max_searches por llamada (bájalo para gastar menos en una pregunta amplia), un rango de fechas más estrecho, una lista de destinos más corta.

Una llamada contra treinta

La API REST subyacente toma exactamente una tupla (origin, destination, date) por llamada. Frente a un paso directo de una fecha por llamada, "lo más barato a Sri Lanka en cualquier día de octubre" son 31 llamadas de herramienta separadas — 31 viajes de ida y vuelta a través del modelo, 31 oportunidades de perder el hilo y una factura que el usuario solo descubre después.

Aquí es una llamada de herramienta. La expansión ocurre en el servidor, de forma concurrente, limitada, muestreada uniformemente, deduplicada en buy_link, combinada, ordenada por tu sort_by y reportada honestamente en search_coverage y api_usage.

	Este servidor (de pago)	Servidor gratuito
Expansión por llamada	30 (máximo duro 60; sube o baja por llamada con `max_searches`)	15
Anuncios	ninguno	una tarjeta patrocinada revelada por resultado
Clave	tu propia clave de RapidAPI	no se necesita
Informe de gastos	`api_usage` en cada respuesta	n/a
Listable en directorio	sí	no

Este servidor no lleva anuncios en absoluto — no por gusto sino por restricción: la política de directorio de conectores de Anthropic y las pautas de aplicaciones de OpenAI prohíben la publicidad y el contenido patrocinado en los resultados de herramientas, por lo que un servidor con anuncios nunca puede aparecer allí y este sí puede.

Desarrollo local

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

Apunta un cliente al proceso local de la misma manera:

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

Pruebas (124 aprobadas, verificadas):

.venv/bin/python -m pytest -q

La configuración vive en example.env; cada variable está documentada allí. Las que importan:

Variable	Default	Why it matters
`MAX_SEARCHES_PER_TOOL_CALL`	`30`	Límite de fan-out por llamada. Limitado a un máximo estricto de 60.
`MAX_CONCURRENT_SEARCHES`	`10`	Concurrencia del fan-out.
`MAX_HTTP_CONNECTIONS`	`60`	Techo del pool de conexiones; las instancias serverless comparten un pool de descriptores de archivo.
`REQUEST_TIMEOUT_SECONDS`	`105`	Coincide con el techo del proveedor ascendente, para que este lado nunca agote el tiempo de espera primero.
`DEFAULT_RESULT_LIMIT`	`10`	Resultados solicitados por cada búsqueda ascendente individual.
`SIGNUP_URL`	Listado de RapidAPI	Se muestra a los usuarios que llegan sin clave.
`MCP_PUBLIC_URL`	`http://localhost:8000/mcp`	Informado por `/health`.
`RAPIDAPI_KEY`	(vacío)	Déjalo vacío en producción. Si se establece, cada llamante sin clave se atiende — y se factura — a esa suscripción. El servidor registra una advertencia al inicio y `/health` informa `server_side_key_configured`.
`METRICS_TOKEN`	(vacío)	Cuando se establece, `/metrics` requiere una cabecera `x-metrics-token`.
`LOG_PATH`	(vacío)	Vacío desactiva el sumidero de archivos; las líneas `MCP_CALL` de stdout siguen siendo el registro. Correcto en serverless.

Rutas operativas: GET /health (pública, sin autenticación — los registros la consultan), GET /metrics, GET /metrics/calls?hours=24.

El destino de despliegue es Vercel mediante api/index.py (envoltorio FastAPI que proporciona a FastMCP su ciclo de vida, stateless_http=True). La ruta MCP canónica es /mcp, sin barra final.

Nunca confirmes una clave real. example.env se distribuye con marcadores de posición; mantenlo así.

No afiliación

Esta es una API independiente que devuelve precios de vuelos disponibles públicamente. No está afiliada, respaldada ni patrocinada por Google. "Google Flights" se utiliza únicamente para describir la fuente de datos pública. Las tarifas las proporciona el proveedor ascendente, cambian constantemente y no están garantizadas — confirma siempre el precio en el sitio de la aerolínea o de reserva antes de comprar.

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 — tarifas en tiempo real que tu agente puede buscar en todo un rango de fechas, sin anuncios

Lo que obtiene tu agente

Obtén una clave (plan gratuito disponible)

Tres formas de pasar tu clave

Herramientas

search_oneway_flights

search_roundtrip_flights

Un ejemplo práctico

Informe de gastos (api_usage)

Una llamada contra treinta

Desarrollo local

No afiliación

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`

Informe de gastos (`api_usage`)