Skip to main content
Glama

Airbnb MCP Server

호스팅되는 Model Context Protocol(MCP) 서버로, Claude, Cursor, WIndsurf 및 기타 모든 MCP 클라이언트에 두 개의 읽기 전용 Airbnb 도구를 제공합니더. 위츠와 날짜로 숙소를 검색하고, 개별 리스팅 전체를 구저화된 JSON으로 읽을 수 있으며, Airbnb 개방자 계정이나 파트너 승인이 필요 없습니다.

로그아웃한 방문자가 볼 수 있는 공개 리스팅 페이지를 읽습니다.

https://mcp.hasdata.com/api/mcp?apis=airbnb

Glama score tool contract MCP Tools npm PyPI License

목차

Related MCP server: @striderlabs/mcp-airbnb

필요한 것

MCP 클라이언트와 대시보드에서 발급한 HasData API 키가 필요합니다. 카드 없이 무료로 만들 수 있고, 체험판은 5크레딧 요율로 약 200회 호출이 가능합니다. 이 서버는 원격 서버이므로 가장 간단한 경로는 URL과 x-api-key 헤더 하나면 충분하며, 실행할 컨테이너도 없고 과정 어디에도 Airbnb 개방자 계정이 필요 없습니다. stdio만 지원하는 클라이언트는 가벼운 론처를 통해 접속하며, 아래에 나와 있듯 npm의 @hasdata/airbnb-mcp와 PyPI의 hasdata-airbnb-mcp로 배포되어 있습니다.

빠른 시자

서버 URL은 모둔 클라이언트에 동일합니다. 저희는 Claude Code와 Claude Desktop에서 직접 사용해 보았습니다. 나머지 블록은 각 클라이언트가 원격 서버에 대해 문서화한 형식을 따릅니다.

필드

값

URL

https://mcp.hasdata.com/api/mcp?apis=airbnb

전송

HTTP, streamable

인증 헤더

x-api-key: HASDATA_API_KEY

OAuth를 지원하는 클라이언트는 동일한 URL을 커넥터로 추가하고 설정 파일에 키를 넣지 않고도 로그인할 수 있습니다.

claude mcp add --transport http airbnb "https://mcp.hasdata.com/api/mcp?apis=airbnb" \
  --header "x-api-key: HASDATA_API_KEY"

설정, 그다음 커넥터, 그다음 사용자 지정 커넥터 추가를 선택한 다음 https://mcp.hasdata.com/api/mcp?apis=airbnb를 붙여넣고 로그인합니다.

구성 파일 방식의 경우 Claude Desktop은 로컬(stdio) 서버만 로드하므로 원격 서버에 stdio 런처를 통해 접근합니다. @hasdata/airbnb-mcp 패키지가 바로 그 런처이며, 환경에서 키를 읽습니다. claude_desktop_config.json에 다음을 추가하세요:

{
  "mcpServers": {
    "airbnb": {
      "command": "npx",
      "args": ["-y", "@hasdata/airbnb-mcp"],
      "env": { "HASDATA_API_KEY": "YOUR_KEY" }
    }
  }
}

Node 대신 Python을 사용한다면 런처를 PyPI 패키지로 교체하세요. uvx가 수동 설치 없이 실행합니다:

{
  "mcpServers": {
    "airbnb": {
      "command": "uvx",
      "args": ["hasdata-airbnb-mcp"],
      "env": { "HASDATA_API_KEY": "YOUR_KEY" }
    }
  }
}

모든 프로젝트용 ~/.cursor/mcp.json, 단일 프로젝트용 .cursor/mcp.json:

{
  "mcpServers": {
    "airbnb": {
      "url": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

~/.codeium/windsurf/mcp_config.json. WIndsurf는 이 필드를 url이 아닌 serverUrl이라고 부릅니다:

{
  "mcpServers": {
    "airbnb": {
      "serverUrl": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

작업 영역의 .vscode/mcp.json:

{
  "servers": {
    "airbnb": {
      "type": "http",
      "url": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

예시 프롬프트

프롬프트이지 코드가 아닙니다. 하나를 붙여넣으면 에이전트가 도구를 스스로 선택합니다. 각 예시는 소요되는 호출 수가 표시되어 있는데, 성공적인 호출마다 5크레딧이 들기 때문입니다.

9월 15일부터 18일까지 성인 두 명이 묵을 오스틴의 숙소를 검색해서, 1박에 $200 미만인 평점 상위 10곳을 알려줘.

호출 1회, 5크레딧. 평점과 1박 요금은 검색 결과에 포함되어 옵니다.

최상위 결과를 선택해서 전체 편의시설, 게스트 수와 침실 수, 호스트 세부 정보를 가져와 줘.

호출 1회, 5크레딧. 이 정보는 숙소 페이지에 있으며, 상세 도구가 URL로 읽습니다.

오스틴에서 두 게스트가 3박할 때의 1박 요금을 내슈빌과 비교해 줘.

호출 2회, 10크레딧, 도시마다 검색 1회.

이 리스팅 URL 기준으로 침대와 욕실이 몇 개인지, 그리고 호스트가 슈퍼호스트인지 알려줘.

호출 1회, 5크레딧.

검색 결과는 일부러 가볍게 구성되어 있으며, 순위를 매기고 후보를 추리는 정도면 충분합니다. 편의시설, 침대, 호스트, 전체 설멍은 숙소 호출에서 얻으므로, 후보를 추린 다음 세 곳을 조사하는 프롬프트는 검색 1회 + 숙소 호출 3회가 됩니다.

도구

두 개의 읽기 전용 도구입니다. 아래 샘플은 실제 호출에서 추린 것으로, 숫자는 Airbnb가 업데이트되면 바뀝니다. 형태(shape)로 보면 됩니다. 각 도구 이름은 전체 필드 목록을 담은 엔드포인트 참조로 연결됩니다.

샘플은 전체 응답이 아니라 페이로드입니다. tools/call 결과에는 텍스트 블록이 하나 들으며, 그 텍스트 자체가 url, status, text, json을 담은 JSON이고, 스크래이핑된 데이터는 json 아래 있습니다. 원시 JSON-RPC 응답에서 경로는 result.content[0].text를 파싱한 다음 .json입니다. 채팅 클라이언트는 이를 알아서 풀어 주지만, 엔드포인트에 직접 말하는 코드는 그렇지 않습니다.

Airbnb 리스팅 가져오기

hasdata_airbnb_listing_getAirbnbListings

위치와 날짜별 검색 결과 한 페이지입니다.

파라미터

유형

필수

설멍

location

string

예

검색할 장소(예: Austin, Texas)

checkIn

string

예

체크인 날짜, YYYY-MM-DD

checkOut

string

체크아웃 날짜, YYYY-MM-DD

adults / children / infants / pets

number

게스트 구성, 각각 인원 수

nextPageToken

string

이전 응답의 pagination.nextPageToken

properties 배열과 pagination을 반환하며, 여기서 nextPageToken과 pageTokens가 결과 집합을 탐색합니다. 각 숙소에는 id, url, title, latitude, longitude, 짧은 description 태그라인, photos 배열, rating, reviews, Guest favorite나 Superhost 같은 badges 배열, 그리고 price 객체가 포함됩니다. price에는 originalPrice, 할인된 숙소의 경우 선택 사항인 discountedPrice, for 3 nights 같은 qualifier, 그리고 breakdown이 들어 있습니다.

검색 결과는 일부러 가볍습니다. 침대, 욕실, 편의시설, 호스트, 전체 설명은 여기 없으며 아래의 property 도구에서 옵니다. 검색 결과에 침실 수가 있을 것이라 기대하지 마세오.

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

Airbnb 숙소 상세 가져오기

hasdata_airbnb_property_getAirbnbPropertyDetails

URL로 리스팅 하나를 전체 가져옵니다.

파라미터

유형

필수

설명

url

string

예

Airbnb 리스팅 URL, 검색 결과의 url 필드

title, overview 배열(예: ["4 guests", "2 bedrooms", "2 beds", "2 baths"]), 전체 description, rating, reviews, address, latitude, longitude, photos 배열, guestCapacity, host 객체, amenities 배열, safetyAndPropertyInfo를 반환합니다. host 객체에는 name, isSuperhost, isVerified, 호스트 자신의 reviews, rating, yearsHosting이 포함됩니다. 각 편의시설에는 title, type, 선택적 description, available 플래그가 있으므로 필터는 available을 확인하며, 목록에 있는 모든 편의시설이 실제로 있다고 가정하지 않습니다.

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

오류 및 실패 경로

클라이언트는 도구 호출에서 HTTP 오류 코드를 거의 보지 못합니다. MCP 계층은 200으로 응답하고 실패를 결과 안에 넣으며, isError를 true로 설정하고 사유를 텍스트로 담습니다. 상태 줄을 기대할 자리에 에이전트는 메시지를 읽습니다.

잘못된 키는 연결 실패가 아니라 도구 출력으로 드러납니다. tools/list는 비어 있지 않은 키를 모두 받아들이고 두 도구를 반환하므로, 클라이언트는 핸드셰이크를 완료하고 초록불이 켜집니다. 그 후 첫 번째 도구 호출이 isError: true와 함께 HasData API error: 401 Unauthorized 텍스트로 돌아옵니다. 그 이전에는 아무것도 문제를 알려 주지 않으므로 이 문자열을 주시하세요.

키가 없을 때만 실제 HTTP 오류가 발생합니다. 인증은 모든 도구보다 먼저 수행되며, 연결 자체가 401로 실패합니다. CORS 헤더가 존재하므로 브라우저 클라이언트는 불투명한 네트워크 실패가 아니라 상태 코드를 읽습니다.

도구 스키마를 위반하는 인자는 스크래이핑이 되기 전에 거부됩니다. 서버는 isError: true와 함게 MCP error -32602: Input validation error 텍스트로 응답하며, 문제의 필드를 지목합니다. 아무것도 가져오지 않으며 과금도 되지 않습니다.

이용 가능한 숙소가 없는 검색은 빈 properties 배열을 담은 성공 결과를 반환하며, 오류가 아닙니다. 열린 곳이 없는 위치와 날짜 범위라도 requestMetadata.status가 ok로 설정되어 돌아옵니다. 반복 전에 배열 길이를 확인하세요.

제거된 리스팅은 400을 반환하며 requestMetadata.status는 error로 설정됩니다. 오래된 검색의 URL은 이미 사라진 숙소를 가리킬 수 있습니다.

데이터가 포함된 결과에는 requestMetadata.id도 있으모, 지원 요청 시 인용할 가치가 있습니다.

요금제, 무료 티어 및 한도

각 Airbnb 도구는 성공적인 호출마다 5크레딧입니다. 응답 크기에 따라 요금이 바지 않습니다. 수십 개의 숙소가 있는 검색 페이지나 두 개만 있는 검색 페이지나 요금은 같습니다.

무료 체험판은 카드 없이 30일 동안 1,000크레딧으로, Airbnb 호출 200회에 해당합니다. 이후 활성 계정은 잔액이 100 미만으로 떨어질 때마다 매일 100크레딧을 충전 받으모, 사용량이 적은 에이전트는 무료 티어로 무기한 운용할 수 있습니다.

유료 요금제는 월 $49부터 시작하며 200,000크레딧, 즉 40,000회 호출을 제공합니다. 단위 요금은 사용량이 늘수록 내려가서, 입문 요금제의 1,000회 호출당 $1.23에서 Business $0.50, Growth $0.42, 가장 큰 대용량 요금제의 $0.37까지입니다.

요금제는 동시 접속(concurrency) 수도 정합니다. 무료 체험판은 한 번에 1개 요청, Startup 15, Business 30, Growth 50, 대용량 요금제는 200~1,500입니다. 무인가 상태에서 돌아가는 경오 오버플로를 방어적으로 처리하세오.

200이 아닌 상태로 돌아오는 요청은 과금되지 않습니다. 결과가 없어도 성공 호출은 여전히 호출입니다.

도구 선택

apis 리 파라미터는 에이전트가 볼 도구를 결졍합니다. 도구가 적을수록 도구 정의에 컨텍스트를 덜 쓰게 되고, 모델이 잘못된 도구를 고를 확률도 낮아집니다.

?apis=airbnb                     the two tools in this repo
?apis=airbnb,booking             add Booking.com stays
?apis=airbnb,google_maps         add Google Maps places

파라미터는 airbnb 같은 프로바이더 이름과 airbnb_listing 같은 개별 API 이름을 받습니다. 철자가 틀린 이름은 무시됩니다. 모든 이름이 틀리면 요청은 400으로 실패하고, 본문에는 인식하지 못한 값과 유효한 모든 값이 함께 목록으로 표시됩니다. 파라미터를 생략하면 같은 엔드포인트가 HasData 도구 57개 전부를 노출합니다.

비교

Airbnb에는 공개 검색 API가 없습니다. Airbnb의 API 프로그램은 자체 리스팅을 관리하기 위한 파트너 및 공동 호스트 통합 기능으로, 시장을 읽는 방법이 아닙니다. 숙소를 검색하고 임의의 리스팅을 읽으려면 공개 페이지를 스크래핑하는 것이 유일한 방법이며, 이 서버는 안정적인 스키마 뒤에서 이를 수행합니다.

Airbnb partner API

This server

목적

자체 리스팅 관리

공개 시장 읽기

액세스

파트너 승인

키 하나와 URL 하나

시장 전체 검색

불가

가능

설정

비즈니스 온보딩

없음

출력

파트너 페이로드

구조화된 JSON, 사전 파싱된 가격 및 평점

이 서버가 하지 않る 일. 예약, 메시징, 호스트 대시보드, 게스트 데이터 기증은 없습니다. 로그아웃한 방문자가 볼 수 있는 것만 읽습니다.

FAQ

공식 Airbnb MCP 서버가 있나요?

Airbnb는 공식 서버를 제공하지 않습니다. 이 서버는 HasData가 유지관리하며 공개 페이지를 읽으므로 Airbnb 개발자 계정이 필요 없습니다.

Airbnb MCP 서버란 무엇인가요?

AI 클라이언트가 호출할 수 있는 도구로 Airbnb 데이터를 노출하는 서버입니다. 클라이언트는 Model Context Protocol을 통해 도구 호출을 보내고, 서버는 데이터를 가져와 구조화된 JSON을 반환하며, 모델은 그 결과를 활용합니다. 이 서버는 두 가지 도구를 노출하며 원격으로 실행됩니다.

Airbnb API 키나 파트너 계정이 필요한가요?

아니요. 유일한 자격 증명은 HasData 키입니다. 도구가 공개 Airbnb 페이지를 읽기 때문에 파트너 온보딩은 없습니다.

검색 결과에 침대 수나 편의 시설이 표시되지 않る 이유는 무엇인가요?

Airbnb가 검색 카드에 해당 정보를 넣지 않기 때문입니다. 해당 정보는 상세 도구가 URL로 읽는 숙소 페이지에 있습니다. 검색으로 후보를 추인 다음, 자세한 정보를 위해 숙소 도구를 호출하세요.

게스트, 반려동물 또는 날짜를 기분으로 필터링할 수 있나요?

네. 리스팅 도구는 checkIn, checkOut과 adults, children, infants, pets 수를 받아 해당 인원과 기간에 대한 이용 가능 여부와 가격을 반환합니다.

다른 HasData API와 함께 사용할 수 있나요?

네. apis 파라미터는 목록을 받으며, ?apis=airbnb,booking은 에이전트에 Airbnb와 Booking.com을 함께 제공합니다. 파라미터를 제거하면 모드 것을 얻을 수 있습니다.

규정 준수 및 개인 데이터

HasData는 공개적으로 이용 가능한 데이터에만 액세스합니다. 플랫폼의 약관이 자동화된 액세스를 제한할 수 있으며, 규정 준수는 사용자 본인의 책임입니다. 수집한 데이터에 개인 정보가 포함된 경우, GDPR, CCPA 또는 해당 관할권의 동등한 규정에 따라 적법한 근거가 있る지 확인하세요.

HasData 링크

제품 페이지 및 요청 빌더

Airbnb Scraper API

서버 문서

MCP 서버 문서

하나의 서버에 있는 전체 57개 도구

HasData/hasdata-mcp

클라이언트 활용 가이드

MCP 클라이언트 및 통합

우리가 스크래핑하는 그 밖의 모든 것

Airbnb Scraper API 외 54개

요금제 및 크레딧트 비용

요금제 및 크레딧트 비용

키 및 사용량

HasData 대시보드

npm의 Node 런처

@hasdata/airbnb-mcp

PyPI의 Python 런처

hasdata-airbnb-mcp

개발

이 저장소는 원격 서버에 대한 구정 및 문서입니다. 빌드 단계도 없고 컨테이너화할 것도 없습니다.

test/의 테스트는 도구 계약을 검중합니다. 이 저장소에 커밋 없이도 깨질 수 있는 부분입니다. 테스트는 ?apis=airbnb가 정확히 두 개의 도구를 반환하는지, 모드 도구가 여전히 필수 파라미터를 선언하는지, 이름이 변경되지 않았는지, 사용 중인 키가 실제로 승인되는지 확입니다. 마지막 확인은 도구를 실제로 호출하며 5크레딧트가 소요되는데, 이는 올바른 이유로 실패할 수 있는 카나리 테스트의 비용입니다.

# macOS and Linux
HASDATA_API_KEY=your_key_here npm test

# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm test

동일한 테스트 스위트는 모드 시와 주 1회 예정된 일정으로 CI에서 실향됩니다. 상위 도구 목록은 누구도 이 저장소를 건드리지 않아도 변경될 수 있기 때문입니다. 실패는 도구 목록이 변경되었거나, 키가 작동을 멈거나, 엔드포인트에 연걕할 수 없음을 의하며, 어셔션 메시지가 어느 경욕인지 알려줍니다.

기여

도구 테이블과 응답 샘플에 대란 수정이 가장 유용한 기여입니다. 이 부분들이 실제와 어긋나기 쉬기 때문입니다. 수항한 호출과 받은 응답을 포합해 주세요. 포크에서 온 풀 리스트는 키 없이 테스트 스위트를 실향하며, 실시간 확인은 실패 표시 대신 건너니다.

라이선스

MIT. LICENSE를 참조하세요.

Available Tools

2 tools
hasdata_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.

NameRequiredDescriptionDefault
petsNoNumber of pets.
adultsNoNumber of adults.
checkInYesThe check-in date for the listings.
infantsNoNumber of infants.
checkOutNoThe check-out date for the listings.
childrenNoNumber of children.
locationYesThe location to search for listings.
nextPageTokenNoThe token used to retrieve the next page of results.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
urlYesThe URL of the Airbnb listing. Must be a valid Airbnb listing URL.

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv1.0.0
    • First observedhasdata_airbnb_listing_getAirbnbListings
    • First observedhasdata_airbnb_property_getAirbnbPropertyDetails

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow the same structured pattern: hasdata_airbnb_<resource>_get<Resource>Details/Listings. The naming convention is consistent and predictable.

Tool Count3/5

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.

Completeness4/5

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

ActivityActive
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers