Google Flights MCP

Búsqueda de vuelos en tiempo real: tarifas de ida y vuelta en rangos de fechas, con veredictos de precios.

Documentación

Habilidades para Agentes de Viajes

Habilidades de agente para precios de vuelos y hoteles en vivo. Ocho habilidades (fechas más baratas, seguimiento de tarifas, planificación de viajes, comparación de destinos, búsqueda de hoteles, monitoreo de paridad de tarifas y más) que enseñan a Claude, Cursor o cualquier agente compatible con MCP a responder preguntas sobre precios de viajes con tarifas en tiempo real de Google Flights y tarifas de Booking.com. Cada tarifa incluye el veredicto propio de Google low | typical | high y un enlace de reserva, para que el agente pueda decirle a alguien si un precio vale la pena, no solo cuál es el precio. Funciona a través de MCP o REST simple.

Creado por FlightPowers, una API de datos de viajes para desarrolladores y agentes de IA.

Dónde obtener una clave: no necesitas una para empezar; el servidor gratuito a continuación está respaldado por anuncios (inicia sesión con Google, 50 búsquedas al día). Sin anuncios con tu propia clave de RapidAPI: Google Flights Live API y Booking Live API, un paquete gratuito de 10 búsquedas al mes, luego PRO cuesta $10 por 2,500 búsquedas de vuelos o 2,000 búsquedas de hoteles.

Enlaces rápidos

Página principal: flightpowers.com
Google Flights Live API: rapidapi.com/mtnrabi/api/google-flights-live-api
Booking Live API: rapidapi.com/mtnrabi/api/booking-live-api
GitHub: github.com/mtnrabi/travel-agent-skills

Instalación en 60 segundos

Gratis, sin clave de API, inicia sesión con Google cuando tu cliente lo solicite:

claude mcp add --transport http flightpowers https://free-trial.flightpowers.com/mcp

Eso coloca cuatro herramientas en tu agente: vuelos de ida, vuelos de ida y vuelta, búsqueda de hoteles y un hotel por nombre, y puedes hacerle una pregunta real de inmediato. El servidor gratuito está respaldado por anuncios: cada respuesta incluye una tarjeta patrocinada divulgada. Servidores sin anuncios a continuación.

Qué devuelve

Haz una pregunta flexible y es una llamada, no una por fecha:

Cheapest way from Berlin to Paris in the middle of September?

$49   Wed Sep 16   easyJet · non-stop · 1 hr 50 min · 6:05 AM → 7:55 AM    low
$49   Thu Sep 17   easyJet · non-stop · 1 hr 50 min · 6:00 AM → 7:50 AM    low
$53   Tue Sep 15   easyJet · non-stop · 1 hr 50 min · 6:15 AM → 8:05 AM    typical

Google's historical band for this route and period: $50–$125
Dates searched: Sep 14, 15, 16, 17, 18  ·  one call, five dates
Every row carries a buy_link into Google Flights for that exact itinerary.

Esa es una respuesta real del servidor gratuito, capturada el 2026-08-25 (BER → CDG, departure_date_from / departure_date_to abarcando cinco días). Es una búsqueda real, no un punto de referencia: las tarifas cambian constantemente, y las tuyas serán diferentes.

La columna low / typical es la parte que la mayoría de las APIs de vuelos no tienen. Proviene de price_range_in_relation_to_other_periods, junto con price_insights_low y price_insights_high: la banda de precios propia de Google para esa ruta y período. Es la diferencia entre un agente que dice "$49" y uno que dice "$49 es bajo para esta ruta: resérvalo, no esperes".

Las herramientas que recibe tu agente

Escritas para el modelo que debe elegir entre ellas. Los nombres de parámetros a continuación son los reales de los esquemas de las herramientas.

`search_oneway_flights`

Úsala para cualquier pregunta de tarifa de un solo sentido, incluidas las abiertas. El destino puede ser una lista de códigos IATA y las fechas pueden ser un rango (departure_date_from / departure_date_to): el servidor expande ambos internamente. "Vuelo más barato a Sri Lanka en cualquier fecha de octubre" es una llamada, no treinta. No hagas un bucle con esta herramienta sobre fechas.

No la uses cuando el viajero regresa: search_roundtrip_flights cotiza el par junto, que no es el mismo número que dos idas sumadas.

Recibes una fila por itinerario: price / price_as_number, airline, duration / duration_seconds, stops y stops_info[] (cada aeropuerto de escala y su duración), departure_description / arrival_description, un buy_link con enlace profundo a ese itinerario exacto, y los tres campos de información de precios. Junto a ellos, search_coverage nombra cada fecha realmente buscada.

Lee search_coverage antes de concluir algo. En el servidor gratuito, una llamada busca como máximo 15 combinaciones de fecha × destino; una solicitud más amplia no se rechaza, se muestrea uniformemente en el rango y regresa con truncated: true. Una fecha que falta en departure_dates_searched nunca se buscó, lo cual no es lo mismo que no tener vuelos.

`search_roundtrip_flights`

Úsala siempre que el viaje regrese, y especialmente cuando el usuario sepa la duración del viaje pero no las fechas: pasa nights (un número, o una lista como [5,6,7]) en lugar de return_date, con departure_date_from / departure_date_to para la ventana de salida. "De 5 a 7 noches en Roma en algún momento de mayo" es una llamada.

Recibes total_price / total_price_as_number para ambas piernas juntas, total_duration_seconds, total_stops, las piernas de salida y regreso ya emparejadas: departure_flight_airline, return_flight_airline, escalas, duraciones y horarios por pierna, y un solo buy_link que cubre todo el viaje. Mismo límite del nivel gratuito y mismo search_coverage, contado sobre combinaciones de fecha de salida × noches.

`search_hotels`

Úsala cuando el usuario quiera opciones en un lugar. destination es texto libre como lo diría una persona: "Rome", "Tokyo Shibuya", no un ID ni una coordenada, además de checkin_date y checkout_date. budget_per_night filtra antes de que recibas la lista.

No la uses cuando ya hayan nombrado la propiedad; eso es find_hotel_by_name.

Recibes por propiedad: name, price_string y price, review_score y review_count, room_type, location, y un link de reserva.

`find_hotel_by_name`

Úsala cuando el usuario nombre una propiedad específica — "¿está libre el Hilton Paris Opera esa semana?" — o cuando estés rastreando el precio de un solo hotel a lo largo del tiempo. hotel_name es el nombre que una persona escribiría; agregar la ciudad ayuda cuando una cadena tiene muchas propiedades. No se necesita un ID de propiedad interno; la resolución se hace por ti.

Recibes el precio de esa propiedad, review_score, room_type y el link de reserva. Una propiedad sin disponibilidad para esas fechas regresa como no disponible: eso es una respuesta, no un error, y volver a llamar no lo cambiará.

Las cuatro: las tarifas y los precios se vuelven obsoletos en minutos. Nunca reutilices un resultado de una parte anterior de la conversación; busca de nuevo y sella la respuesta con la hora en que se obtuvo.

Las ocho habilidades

Las herramientas le dan a tu agente los datos. Las habilidades son lo que hacen que use los datos bien: una llamada para todo un rango de fechas en lugar de treinta, el veredicto en lugar de un número simple, y una búsqueda fresca cada vez.

Un centro central contiene autenticación, hosts, cada endpoint, cada nombre de campo de respuesta y las reglas de facturación. Siete habilidades de flujo de trabajo se mantienen delgadas y delegan en él.

travel-data-api                 hub — auth, hosts, endpoints, response fields, cost per call
  |- cheapest-dates             WHEN to fly: scan a date range, judge the winner
  |- destination-compare        WHERE to go: price many cities from one origin
  |- trip-planner               flights + hotel totalled into one all-in budget
  |- fare-watch                 one pinned route, re-checked over time, book-now-or-wait
  |- hotel-search               find and price places to stay
  |- rate-parity-monitor        same hotel priced as a resident of each country
  `- travel-brief               presentation layer — recommendation, table, links

Habilidad	Úsala cuando quieras…	Devuelve
`travel-data-api`	escribir código curl o de cliente, buscar un parámetro o campo de respuesta, instalar un servidor, o calcular cuánto cuesta una llamada	tablas de endpoints, curl ejecutable, nombres exactos de campos JSON
`cheapest-dates`	encontrar el día, semana o mes más barato para volar una ruta conocida — o la duración de viaje más barata	tarifa más barata por fecha, el `departure_date`/`return_date` ganador, `buy_link`, y el veredicto de oferta
`destination-compare`	decidir a dónde ir: "algún lugar cálido por menos de $300 en octubre"	una tabla de ciudades ordenada por precio, más una línea de cobertura que nombra cada destino realmente buscado
`trip-planner`	cotizar un viaje nombrado de principio a fin: "7 noches en Lisboa por menos de $2000"	check-in/check-out alineados, vuelos de ida y vuelta, hoteles coincidentes, total combinado por persona vs. el límite
`fare-watch`	rastrear el precio de una ruta a lo largo de verificaciones repetidas y alertar solo en una caída significativa	precio en vivo, veredicto `low`/`typical`/`high`, banda histórica de Google, `checked_at`, delta vs. tu historial almacenado
`hotel-search`	encontrar hoteles por ciudad, vecindario o punto de referencia, o cotizar una propiedad nombrada	`name`, `price_string`, `review_score`, `room_type`, `location`, `link`
`rate-parity-monitor`	ver si un hotel nombrado es más barato reservado desde otro país	tabla por mercado con el país desde el que se vio cada precio, varias muestras por país, tarifa por noche en una moneda, brecha vs. el mercado más barato, y un veredicto que solo cuenta una brecha que se mantiene en las muestras
`travel-brief`	convertir resultados en algo que puedas enviar a un cliente	recomendación → tabla → veredicto → enlaces de reserva → línea de hora de verificación

Las habilidades se nombran por el trabajo, no por el endpoint. Dos endpoints de vuelos y dos endpoints de hoteles producen siete flujos de trabajo, porque "qué día es más barato" y "a dónde debería ir" son preguntas diferentes para un usuario y preguntas idénticas para una API.

Otros prompts para los que están construidas:

Where can I go from JFK for under $400 in late October? Somewhere warm.
Watch BER→LHR for the 14th and ping me if it drops below $90.
Plan a week in Rome in May for two, £1800 all in, hotel needs free cancellation.
Is the Hotel Gracery Shinjuku cheaper booked from Japan than from Germany, same dates?
Write up the Lisbon options for my client with a table and booking links.

Instala las habilidades

Claude Code (plugin)

claude plugin marketplace add mtnrabi/travel-agent-skills
claude plugin install travel-agent-skills@travel-agent-skills

Reinicia Claude Code y las ocho se cargan juntas: el agente elige la correcta según la pregunta, y también puedes invocar una directamente por nombre (cheapest-dates, trip-planner, rate-parity-monitor).

Cualquier agente con un directorio de habilidades simple

git clone https://github.com/mtnrabi/travel-agent-skills.git

# personal, every project:
cp -r travel-agent-skills/skills/* ~/.claude/skills/

# or scoped to one project:
mkdir -p .claude/skills && cp -r travel-agent-skills/skills/* .claude/skills/

Cada habilidad es una carpeta autocontenida con un SKILL.md y un descriptor de visualización agents/openai.yaml, por lo que cualquier runtime que lea un directorio de habilidades puede cargarlas: copia el conjunto completo o solo las carpetas que quieras. Nada aquí importa nada; no hay paso de compilación ni dependencias.

Servidores sin anuncios (tu propia clave)

El servidor gratuito es la forma más rápida de empezar. Cuando lo quieras sin anuncios, con mayor fan-out y su propio informe de gastos, las mismas herramientas están alojadas en dos servidores facturados a tu propia clave de RapidAPI:

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

# hotels
claude mcp add --transport http hotels https://hotels.flightpowers.com/mcp \
  --header "x-rapidapi-key: YOUR_RAPIDAPI_KEY"

Si tu cliente no puede enviar encabezados personalizados, ambos también aceptan ?rapidapi_key= en la URL, o un campo de clave de API donde el cliente ofrezca uno. El servidor de vuelos también responde en su hostname original, google-flights-mcp.flightpowers.com/mcp, para que las configuraciones existentes sigan funcionando.

	Gratis: `free-trial`	Sin anuncios: `flights.` / `hotels.`
Anuncios	una tarjeta patrocinada divulgada por respuesta	ninguno
Clave	ninguna, inicia sesión con Google	tu propia clave de RapidAPI
Límite de búsqueda por llamada	15 combinaciones de fecha × destino, muestreadas uniformemente más allá	30 por defecto, hasta 60 vía `max_searches`
Presupuesto diario	50 búsquedas al día y 250 al mes por cuenta iniciada	tu propio plan
Informe de gastos	—	`api_usage` y cuota restante en cada llamada
Hoteles	búsqueda y por nombre	además precios por país y 24 filtros de Booking.com

El servidor de hoteles sin anuncios agrega dos cosas que el gratuito no tiene: price_as_seen_from (un código de país de dos letras que cotiza la estadía como la vería un comprador residente allí) y filters — free_cancellation, breakfast_included, review_score_8, stars_4, pets_allowed y diecinueve más.

El servidor gratuito lleva anuncios, por lo que deliberadamente no está listado en ningún directorio de MCP: la política de directorio de Anthropic, las pautas de plugins de OpenAI y el registro oficial de MCP prohíben contenido patrocinado. Instálalo por URL, como arriba.

O llama a la API REST directamente

Ambas APIs están publicadas en RapidAPI por mtnrabi y se facturan con tu propia clave. La misma clave funciona para ambas una vez que te suscribes a cada una.

API	Qué devuelve	Listado en RapidAPI
Google Flights Live API	Tarifas de vuelos en tiempo real con el veredicto `low\|typical\|high` de Google, ida y ida y vuelta	rapidapi.com/mtnrabi/api/google-flights-live-api
Booking Live API	Disponibilidad de hoteles en tiempo real y tarifas por noche con precios por país	rapidapi.com/mtnrabi/api/booking-live-api

cp .env.example .env    # then paste your key into RAPIDAPI_KEY

Las habilidades nunca imprimen, registran o confirman tu clave, y no pedirán una a menos que una llamada en vivo la necesite.

No hay endpoint masivo en REST: una búsqueda flexible es un bucle, y cada combinación de fecha × destino es una solicitud facturada. Eso es exactamente lo que los parámetros de rango de MCP existen para colapsar. skills/travel-data-api/SKILL.md tiene la referencia completa de endpoints, cada parámetro y curl ejecutable.

¿Prefieres sin código o ejecuciones por lotes programadas? Los mismos datos se envían como actores de Apify: vuelos ($5 / 1k) y hoteles ($4 / 1k).

Lo que los datos hacen que un scraper no puede

El veredicto propio de Google, no solo un número. price_insights_low, price_insights_high y price_range_in_relation_to_other_periods proporcionan la banda histórica para esa ruta y período, además de una calificación low | typical | high. Cada skill de vuelos comienza con el veredicto.
El viaje redondo es una búsqueda real de tramos emparejados, no dos trayectos de ida unidos: un objeto por itinerario con un total combinado, ambos tramos ya coincidentes, y un único buy_link para el viaje.
Precios hoteleros por país. price_as_seen_from en el servidor de hoteles sin anuncios (proxy_country en REST) enruta la solicitud a través de un proxy residencial en ese país, para que puedas consultar la misma habitación en las mismas fechas tal como se la cotizarían a un residente de de, jp o il. Las tarifas varían, así que muestrea cada país varias veces antes de considerar real una diferencia, y espera que algunas propiedades aparezcan con el mismo precio en todos lados. Para eso está diseñado rate-parity-monitor correctamente.
Un resultado vacío te dice qué tipo de vacío es. Ver más abajo: es el modo de fallo que envenena silenciosamente a todo agente de viajes construido sobre un scraper.

Vacío no siempre es vacío

Una búsqueda de vuelos que recibió una página que no pudo leer — un muro de consentimiento, una verificación anti-bot, una respuesta truncada — solía parecer exactamente como si Google dijera "no hay vuelos en esta ruta". Ambos eran [] con HTTP 200. Un agente interpreta el primero como el segundo y le dice con confianza al usuario que la ruta no existe.

La API REST ahora indica cuál de los dos ocurrió, en los encabezados de respuesta:

Encabezado	Significado
`X-Search-Status`	`ok` \| `empty` \| `partial` \| `degraded`
`X-Search-Reason`	qué salió mal en algún intento — `blocked_page`, `unrecognized_page`, `unreadable_prices`, `upstream_timeout`, `search_truncated` y otros. Registra el primer fallo, por lo que puede aparecer en una respuesta que un reintento recuperó; lee `X-Search-Status` para decidir si obtuviste una respuesta
`X-Search-Results`, `X-Search-Attempts`, `X-Search-Combinations`	cuánto trabajo realizó la búsqueda

empty — la búsqueda se completó y Google genuinamente no tiene nada para esa ruta y fecha. El array vacío es la respuesta; reintentar es una solicitud desperdiciada.
partial — resultados reales, conscientemente incompletos. Algunas filas o algunas combinaciones no pudieron entregarse.
degraded — la búsqueda no se completó. El array vacío no dice nada sobre la disponibilidad de vuelos. Reinténtalo; no se reservó ni cambió nada.

Las páginas ilegibles se reintentan automáticamente, y una página que genuinamente dice "no hay vuelos" nunca se reintenta — así que un resultado vacío real sigue llegando tan rápido como siempre. Envía "strict": true y una búsqueda degradada devuelve HTTP 503 con un cuerpo explicativo en lugar de un [] engañoso.

status = r.headers.get("X-Search-Status")
if status == "degraded":
    raise RuntimeError(f"search incomplete ({r.headers.get('X-Search-Reason')}), retry")
flights = r.json()
if not flights:
    print("No flights on this route for these dates")  # status == "empty"

Los servidores MCP leen estos encabezados por ti: cuando parte de una búsqueda no se completó, el resultado de la herramienta lo dice en palabras en lugar de entregar al modelo una lista corta que parece completa.

Reglas de diseño que siguen estos skills

Prefiere las herramientas MCP cuando un cliente las tenga; usa curl REST como alternativa.
Di cuánto cuesta una llamada antes de hacerla. Cada solicitud facturada es dinero del usuario.
Un resultado vacío solo es "no hay vuelos" cuando la búsqueda dice que se completó. Verifica X-Search-Status (REST) o la nota de resultado propia de la herramienta (MCP) antes de reportar una ruta como vacía, y nunca reintentes un empty genuino en un bucle.
Nunca almacenes en caché ni reutilices una tarifa de antes en la conversación. Siempre sella la respuesta con cuándo se obtuvieron los datos.
Comienza con la respuesta, luego la evidencia. Nunca presentes un buy_link como una tarifa mantenida, bloqueada o garantizada.
Nunca imprimas, registres ni confirmes una clave de API.
Sin números inventados. No hay afirmaciones de tiempo de actividad, latencia, número de usuarios o ingresos en este repositorio, y no se deben agregar.

Estas son APIs independientes que devuelven precios públicos de vuelos y hoteles. No están afiliadas, respaldadas ni patrocinadas por Google o Booking.com.

Licencia MIT — ver LICENSE.