Airbnb MCP Server
Airbnb MCP Server
Un servidor alojado de Model Context Protocol (MCP) que ofrece a Claude, Cursor, Windsurf y cualquier otro cliente MCP dos herramientas de Airbnb de solo lectura. Busca estancias por ubicación y fechas, y lee un anuncio completo por completo, todo como JSON estructurado, sin cuenta de desarrollador de Airbnb ni aprobación de socio.
Lee páginas públicas de anuncios que un visitante sin sesión puede ver.
https://mcp.hasdata.com/api/mcp?apis=airbnb
Contenido
Related MCP server: lilo-vacation-rentals
Qué necesitas
Un cliente MCP y una clave de API de HasData desde el panel de control, que se crea gratis y sin tarjeta; la prueba cubre unas 200 llamadas a la tarifa de 5 créditos. Es un servidor remoto, así que el camino más sencillo es una URL y una cabecera x-api-key, sin contenedor que ejecutar y sin cuenta de desarrollador de Airbnb en ningún paso del proceso. Un cliente que solo hable stdio lo alcanza mediante un lanzador ligero, publicado como @hasdata/airbnb-mcp en npm y hasdata-airbnb-mcp en PyPI, que se muestra abajo.
Inicio rápido
La URL del servidor es la misma para todos los clientes. Lo usamos de forma práctica en Claude Code y Claude Desktop. El resto de bloques siguen el formato documentado de cada cliente para un servidor remoto.
Campo | Valor |
URL |
|
Transporte | HTTP, streamable |
Cabecera de autenticación |
|
Los clientes con soporte de OAuth pueden añadir la misma URL como conector e iniciar sesión sin poner una clave en un archivo de configuración.
claude mcp add --transport http airbnb "https://mcp.hasdata.com/api/mcp?apis=airbnb" \
--header "x-api-key: HASDATA_API_KEY"Ve a Configuración, luego Conectores, luego Añadir conector personalizado, pega https://mcp.hasdata.com/api/mcp?apis=airbnb e inicia sesión.
Para la vía del archivo de configuración, Claude Desktop solo carga servidores locales (stdio), así que accede a un servidor remoto mediante un lanzador stdio. El paquete @hasdata/airbnb-mcp es ese lanzador, y lee la clave del entorno. Añade esto a claude_desktop_config.json:
{
"mcpServers": {
"airbnb": {
"command": "npx",
"args": ["-y", "@hasdata/airbnb-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}Si usas Python en lugar de Node, sustituye el lanzador por el paquete de PyPI, que uvx ejecuta sin instalación manual:
{
"mcpServers": {
"airbnb": {
"command": "uvx",
"args": ["hasdata-airbnb-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json para todos los proyectos, o .cursor/mcp.json para uno solo:
{
"mcpServers": {
"airbnb": {
"url": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf llama al campo serverUrl, no url:
{
"mcpServers": {
"airbnb": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}.vscode/mcp.json en el espacio de trabajo:
{
"servers": {
"airbnb": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Ejemplos de prompts
Son prompts, no código. Pega uno y el agente elige la herramienta por sí mismo. Cada uno está anotado con las llamadas que requiere, porque cada llamada correcta cuesta 5 créditos.
Busca estancias en Austin para dos adultos del 15 al 18 de septiembre y dame las diez mejor valoradas por menos de 200 $ la noche.
Una llamada, 5 créditos. La valoración y el precio por noche vienen en el resultado de búsqueda.
Toma el primer resultado y extrae todos sus servicios, el número de huéspedes y dormitorios, y los datos del anfitrión.
Una llamada, 5 créditos. Esos datos están en la página del anuncio, que la herramienta de detalles lee por URL.
Compara el precio por noche de una estancia de tres noches para dos huéspedes en Austin con Nashville.
Dos llamadas, 10 créditos, una búsqueda por ciudad.
Para esta URL de anuncio, dime cuántas camas y baños tiene y si el anfitrión es Superhost.
Una llamada, 5 créditos.
Un resultado de búsqueda es intencionadamente ligero, suficiente para clasificar y preseleccionar. Los servicios, las camas, el anfitrión y la descripción completa llegan con la llamada al anuncio, así que un prompt que preselecciona y luego inspecciona tres alojamientos son una búsqueda más tres llamadas al anuncio.
Herramientas
Dos herramientas, de solo lectura. Las muestras siguientes están recortadas de llamadas reales, y los números cambian con las actualizaciones de Airbnb. Fíjate en su forma. Cada nombre de herramienta enlaza a su referencia de endpoint, que incluye la lista completa de campos.
Las muestras son el payload, no la respuesta completa. Un resultado de tools/call contiene un bloque de texto, y ese texto es a su vez JSON que contiene url, status, text y json, con los datos extraídos en json. En una respuesta JSON-RPC cruda, la ruta es result.content[0].text, parseado, y luego .json. Un cliente de chat te lo desempaqueta, y el código que habla directamente con el endpoint no.
Obtener anuncios de Airbnb
hasdata_airbnb_listing_getAirbnbListings
Una página de resultados de búsqueda por ubicación y fechas.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | El lugar a buscar, como |
| string | sí | Fecha de entrada, |
| string | Fecha de salida, | |
| number | Composición de los huéspedes, cada uno como recuento | |
| string | El |
Devuelve un array properties y pagination, cuyos nextPageToken y pageTokens recorren el conjunto de resultados. Cada propiedad incluye id, url, title, latitude, longitude, una breve description a modo de eslogan, un array photos, rating, reviews, un array badges como Guest favorite o Superhost, y un objeto price. price contiene originalPrice, un discountedPrice opcional cuando la estancia tiene descuento, un qualifier como for 3 nights, y un breakdown.
Un resultado de búsqueda es intencionadamente ligero. Las camas, los baños, los servicios, el anfitrión y la descripción completa no están aquí; vienen de la herramienta de propiedad que aparece abajo. No esperes un recuento de dormitorios en un resultado de búsqueda.
{
"id": "17545365",
"url": "https://www.airbnb.com/rooms/17545365",
"title": "Home in East Austin",
"latitude": 30.25741,
"longitude": -97.73366,
"description": "Downtown Casa - neighborhood feel, close to it all",
"rating": 4.87,
"reviews": 601,
"badges": ["Guest favorite"],
"price": {
"originalPrice": "$607",
"discountedPrice": "$447",
"qualifier": "for 3 nights",
"breakdown": [{ "description": "3 nights x $149.00", "price": "$447.00" }]
}
}Obtener detalles de la propiedad de Airbnb
hasdata_airbnb_property_getAirbnbPropertyDetails
Un anuncio completo, a partir de su URL.
Parámetro | Tipo | Obligatorio | Notas |
| string | sí | Una URL de anuncio de Airbnb, el campo |
Devuelve title, un array overview como ["4 guests", "2 bedrooms", "2 beds", "2 baths"], la description completa, rating, reviews, address, latitude, longitude, un array photos, guestCapacity, un objeto host, un array amenities y safetyAndPropertyInfo. El objeto host incluye name, isSuperhost, isVerified, los reviews propios del anfitrión, rating y yearsHosting. Cada servicio incluye un title, un type, una description opcional y un indicador available, así que un filtro debe leer available; no asumas que todos los servicios listados están presentes.
{
"id": "17545365",
"title": "Downtown Casa - neighborhood feel, close to it all",
"overview": ["4 guests", "2 bedrooms", "2 beds", "2 baths"],
"rating": 4.87,
"reviews": 601,
"address": "Austin, Texas, United States",
"guestCapacity": 4,
"host": { "name": "Deanna", "isSuperhost": true, "isVerified": true, "reviews": 1273, "rating": 4.86, "yearsHosting": 11 },
"amenities": [
{ "title": "Wifi", "type": "SYSTEM_WI_FI", "available": true },
{ "title": "Free washer – In unit", "type": "SYSTEM_WASHER", "available": true }
]
}Errores y casos de fallo
Tu cliente casi nunca ve un código de error HTTP en una llamada a una herramienta. La capa MCP responde 200 y coloca el fallo dentro del resultado, con isError establecido a true y el motivo como texto. El agente lee un mensaje donde cabría esperar una línea de estado.
Una clave incorrecta aparece como salida de la herramienta, no como una conexión fallida. tools/list acepta cualquier clave no vacía y devuelve ambas herramientas, así que el cliente completa el handshake y se muestra en verde. La primera llamada a una herramienta devuelve entonces isError: true y el texto HasData API error: 401 Unauthorized. Estate atento a esa cadena, porque nada anterior en el flujo informa del problema.
Una clave ausente es el único error HTTP real. La autorización se ejecuta antes que cualquier herramienta, y la propia conexión falla con 401. Las cabeceras CORS están presentes, y un cliente de navegador lee el estado en lugar de un fallo de red opaco.
Un argumento que incumple el esquema de una herramienta se rechaza antes de que se convierta en un scraping. El servidor responde con isError: true y el texto MCP error -32602: Input validation error, indicando el campo infractor. No se obtiene nada y no se cobra nada.
Una búsqueda sin disponibilidad devuelve un resultado correcto con un array properties vacío, no un error. Una ubicación y un rango de fechas sin nada disponible siguen devolviendo requestMetadata.status establecido a ok. Comprueba la longitud del array antes de iterar.
Un anuncio que ha sido retirado devuelve 400 con requestMetadata.status establecido a error. Una URL de una búsqueda antigua puede apuntar a un alojamiento que ya no existe.
Los resultados que incluyen datos también llevan un requestMetadata.id que conviene citar al contactar con el soporte.
Precios, plan gratuito y límites
Cada herramienta de Airbnb cuesta 5 créditos por llamada correcta. El tamaño de la respuesta no cambia el precio. Una página de búsqueda con decenas de estancias cuesta lo mismo que una con dos.
La prueba gratuita es de 1.000 créditos durante 30 días sin tarjeta, lo que equivale a 200 llamadas de Airbnb. Después, una cuenta activa sigue recibiendo 100 créditos cada día siempre que su saldo baje de 100, así que un agente de bajo volumen funciona con el plan gratuito de forma indefinida.
Los planes de pago empiezan en 49 $ al mes por 200.000 créditos, es decir, 40.000 llamadas. El precio unitario baja con el volumen: de 1,23 $ por cada 1.000 llamadas en el plan inicial a 0,50 $ en Business, 0,42 $ en Growth y 0,37 $ en los planes de alto volumen más grandes.
Tu plan también fija la concurrencia. La prueba gratuita permite 1 solicitud a la vez; Startup 15, Business 30, Growth 50, y los planes de alto volumen van de 200 a 1.500. Gestiona el caso de desbordamiento de forma defensiva en cualquier proceso desatendido.
Una solicitud que devuelve un código distinto de 200 no se factura. Una llamada correcta que no encuentra nada sigue siendo una llamada.
Selección de herramientas
El parámetro de consulta apis decide qué herramientas ve tu agente. Menos herramientas significa menos contexto dedicado a las definiciones de herramientas y menos probabilidades de que el modelo elija la equivocada.
?apis=airbnb the two tools in this repo
?apis=airbnb,booking add Booking.com stays
?apis=airbnb,google_maps add Google Maps placesEl parámetro acepta nombres de proveedor como airbnb y nombres de API individuales como airbnb_listing. Los nombres mal escritos se ignoran. Si todos los nombres son incorrectos, la solicitud falla con 400 y el cuerpo indica tanto lo que no reconoció como todos los valores válidos. Si omites el parámetro, el mismo endpoint expone las 57 herramientas de HasData.
Cómo se compara
Airbnb no tiene una API pública de búsqueda. Su programa de API es una integración para socios y coanfitriones pensada para gestionar tus propios anuncios, no una forma de leer el mercado. Para buscar estancias y leer anuncios arbitrarios, la única vía es hacer scraping de las páginas públicas, y este servidor lo hace bajo un esquema estable.
API de socios de Airbnb | Este servidor | |
Propósito | Gestionar tus propios anuncios | Leer el mercado público |
Acceso | Aprobación de socios | Una clave y una URL |
Búsqueda en todo el mercado | No | Sí |
Configuración | Incorporación de empresas | Ninguna |
Salida | Cargas de datos de socios | JSON estructurado, precio y valoración preprocesados |
Lo que este servidor no hace. Ni reservas, ni mensajería, ni panel de control del anfitrión, ni datos de huéspedes. Lee lo que un visitante sin sesión iniciada puede ver.
FAQ
¿Existe un servidor MCP oficial de Airbnb?
Airbnb no publica ninguno. Este está mantenido por HasData y lee páginas públicas, por lo que no necesita ninguna cuenta de desarrollador de Airbnb.
¿Qué es un servidor MCP de Airbnb?
Es un servidor que expone los datos de Airbnb como herramientas que un cliente de IA puede invocar. El cliente envía una llamada a una herramienta a través del Model Context Protocol, el servidor obtiene los datos y devuelve JSON estructurado, y el modelo trabaja con el resultado. Este expone dos herramientas y se ejecuta de forma remota.
¿Necesito una clave de API de Airbnb o una cuenta de socio?
No. La única credencial es tu clave de HasData. No hay proceso de incorporación de socios, porque las herramientas leen páginas públicas de Airbnb.
¿Por qué el resultado de búsqueda no muestra camas o servicios?
Porque Airbnb no los incluye en la tarjeta de búsqueda. Están en la página del alojamiento, que la herramienta de detalles lee mediante la URL. Busca para preseleccionar y luego llama a la herramienta del alojamiento para obtener más detalle.
¿Puedo filtrar por huéspedes, mascotas o fechas?
Sí. La herramienta de anuncios acepta checkIn, checkOut y los recuentos de adults, children, infants y pets, y devuelve la disponibilidad y los precios para ese grupo y ese período.
¿Puedo usar esto junto con otras APIs de HasData?
Sí. El parámetro apis acepta una lista, y ?apis=airbnb,booking le da a tu agente Airbnb más Booking.com. Omite el parámetro y obtendrás todo.
Cumplimiento normativo y datos personales
HasData solo accede a datos disponibles públicamente. Los términos de una plataforma pueden restringir el acceso automatizado, y tú eres responsable de tu propio cumplimiento normativo. Si los datos que recopilas incluyen información personal, asegúrate de tener una base legal para ello según el GDPR, la CCPA o las normas equivalentes de tu jurisdicción.
Enlaces de HasData
Página del producto y constructor de solicitudes | |
Documentación del servidor | |
Las 57 herramientas en un único servidor | |
Tutoriales para clientes | |
Todo lo demás que extraemos | |
Planes y costes de créditos | |
Claves y uso | |
Lanzador de Node en npm | |
Lanzador de Python en PyPI |
Desarrollo
Este repositorio es la configuración y la documentación de un servidor remoto. No hay paso de compilación ni nada que contenerizar.
Las pruebas en test/ verifcan el contrato de las herramientas, la parte que puede romperse sin que haya un commit en este repositorio. Comprueban que ?apis=airbnb devuelve exactamente dos herramientas, que cada herramienta sigue declarando sus parámetros obligatorios, que ningún nombre ha cambiado y que la clave en uso es realemente aceptada. Esa últmia comprobación llama a una herramienta de verdad y cuesta 5 créditos, que es el preciio de un canario que puede fallar por la razón correcta.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testLa misma suite se ejecuta en CI en cada push y una vez por semana de forma programada, por que la lista de herramientas upstream puede cambiar sin que nadie toque este repositorio. Un fallo signifca que la lista de herramientas se ha movido, que la clave ha dejado de funcionar o que el endpoint no era accesible, y el mensaje de la aserción indiica cuál de esos casos es.
Contribuciones
Las correcciones de las tablas de herramientas y de los ejemplos de respuesta son la contribución más útil, por que son las partes que tienden a desactualizarse. Incluye la llamada que hiciste y la respuesta que obtuviste. Las pull requests de forks ejecutan la suite sin clave, y las comprobaciones en vivo se omiten en lugar de ponerse en rojo.
Licencia
MIT. Consula LICENSE.
Available Tools
2 toolshasdata_airbnb_listing_getAirbnbListingsairbnb_listing: GET /AInspect
Get Airbnb Listings
Searches Airbnb for available stays by location and date range (check-in/check-out) with guest composition (adults, children, infants, pets) and nextPageToken pagination. Returns listing id/url, title, price per night and total, rating, review count, coordinates, photos, host info, room/bed/bath counts, and amenities summary. Use for travel planning agents, short-term rental market analysis, pricing/occupancy research, and lead lists for property management.
| Name | Required | Description | Default |
|---|---|---|---|
| pets | No | Number of pets. | |
| adults | No | Number of adults. | |
| checkIn | Yes | The check-in date for the listings. | |
| infants | No | Number of infants. | |
| checkOut | No | The check-out date for the listings. | |
| children | No | Number of children. | |
| location | Yes | The location to search for listings. | |
| nextPageToken | No | The token used to retrieve the next page of results. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it explains that the tool searches Airbnb and returns a broad set of listing fields, including pagination via nextPageToken. However, it does not disclose behavioral limits such as page size, data freshness, errors, or any hidden constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly compact and front-loaded, listing the purpose, inputs, return attributes, and use cases. The opening 'Get Airbnb Listings' is slightly redundant with the tool name/title, but not enough to hurt the overall presentation seriously.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-style tool with no output schema and no annotations, the description covers all essential aspects: what triggers it, what it returns, and examples of appropriate usage. Limitations such as default page size, location/date formats, and error handling are missing, but not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description only paraphrases already-documented inputs (location, date range, guests, pets, pagination). It adds no real additional syntax, formats, or nuances beyond schema descriptions for the 8 parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states how to search for listings and what it returns. It is specific about the resource (Airbnb listings) and verbs (searches/listings), but it does not explicitly distinguish itself from the sibling tool 'property details', leaving the boundary slightly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names several concrete use cases including travel planning, rental market analysis, pricing/occupancy research, and property management. It does not give exclusion criteria or explicitly compare with the property details sibling, so it receives a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hasdata_airbnb_property_getAirbnbPropertyDetailsairbnb_property: GET /AInspect
Get Airbnb Property Details
Fetches the full Airbnb property page by listing URL. Returns title, description, location, coordinates, price breakdown, cleaning/service fees, rating and review distribution, host profile, room/bed/bath counts, photos, amenities list, house rules, cancellation policy, and availability calendar hints. Use for travel-planning agents, deep-dive rate research, photo/amenity enrichment of listings discovered via the listing-search endpoint, and LSTR compliance or market-quality audits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the Airbnb listing. Must be a valid Airbnb listing URL. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It says 'Fetches' which implies a read operation, and the title indicates GET. However, it does not explicitly state it is read-only, nor does it mention rate limits, latency, or any side effects. The detailed field list is helpful, but behavioral expectations beyond a straightforward fetch are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated. It front-loads the purpose and then lists the returned fields and use cases. Every sentence adds value, though the field list could be trimmed slightly. It remains efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by enumerating the returned fields thoroughly (title, description, location, coordinates, fees, ratings, host, counts, photos, amenities, rules, policy, calendar hints). It also covers typical use cases. It does not address error handling, pagination, or timeouts, but for a single-URL fetch those are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'url' parameter, which is described as a valid Airbnb listing URL. The description confirms this by saying 'by listing URL' but adds no new semantics (e.g., format, validation rules, or URL variants). With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource ('Get Airbnb Property Details') and immediately specifies the input (listing URL). It enumerates the full set of returned fields, which leaves no ambiguity about what the tool does. It also explicitly ties it to the sibling listing-search endpoint, making differentiation straightforward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists concrete use cases: travel-planning, deep-dive rate research, photo/amenity enrichment, and compliance audits. It references the listing-search endpoint as the source of discovered listings, which implies the sibling is for searching while this is for detail retrieval. It does not explicitly state when not to use it, but the use cases and the mention of the sibling provide adequate guidance.
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.
2 tool updates
v1.0.0- First observed
hasdata_airbnb_listing_getAirbnbListings - First observed
hasdata_airbnb_property_getAirbnbPropertyDetails
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one searches for available listings based on location/date/guests, while the other fetches complete details for a specific property URL. An agent would not struggle to choose between them.
Both tools follow the same structured pattern: hasdata_airbnb_<resource>_get<Resource>Details/Listings. The naming convention is consistent and predictable.
Two tools is thin for an Airbnb MCP server, but the pair forms a coherent, minimal workflow: search for listings then get more detail on a specific property. The count feels acceptable but smaller than ideal.
The core read-only Airbnb use cases are covered: discovering stays by search filters and retrieving a full property detail view. Missing operations like availability calendar lookups or review breakdowns are minor gaps, not dead ends.
Maintenance
Related MCP Connectors
Airbnb MCP server for short-term rental data: occupancy, ADR, RevPAR, revenue, comps, live rates
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables users to search Airbnb listings with advanced filtering options and retrieve detailed property information through an MCP server interface.21,760 npmMIT
- AlicenseCqualityDmaintenanceThe only MCP server with AI guest risk scoring and extortion detection. Search properties, book instantly, protect hosts. 41 tools across 5 layers. Instant API key, 10 free credits.6MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for Airbnb — lets AI agents search listings, check availability, manage reservations, and book stays via browser automation.3 npmMIT
- AlicenseNot gradedqualityBmaintenanceMCP server for searching stays, comparing prices across Booking.com, Airbnb, Vrbo, and Google Hotels, and fetching reviews via natural language in AI assistants.MIT