Airbnb 숙소 목록을 검색하고 목록 세부 정보를 얻는 MCP 서버입니다. 검색 결과에 Airbnb 숙소에 대한 직접 링크를 제공합니다.
airbnb_search
Airbnb 숙소 검색
필수 항목: location (문자열)
선택 항목:
placeId (문자열)
checkin (문자열, YYYY-MM-DD)
checkout (문자열, YYYY-MM-DD)
adults (인수)
children (숫자)
infants (수)
pets (개수)
minPrice (숫자)
maxPrice (숫자)
cursor (문자열)
ignoreRobotsText (부울)
반환: 이름, 가격, 위치 등의 세부 정보가 포함된 목록 표. 각 목록에는 Airbnb 페이지로 직접 연결되는 url 포함되어 있습니다.
airbnb_listing_details
특정 Airbnb 숙소에 대한 자세한 정보를 얻으세요
필수 입력: id (문자열)
선택 항목:
checkin (문자열, YYYY-MM-DD)
checkout (문자열, YYYY-MM-DD)
adults (인수)
children (숫자)
infants (수)
pets (개수)
ignoreRobotsText (부울)
반환: 설명, 호스트 세부 정보, 편의 시설, 요금 등을 포함한 숙소에 대한 자세한 정보. 응답에는 Airbnb 숙소 페이지의 직접 url 포함됩니다.
Related MCP server: Airbnb MCP Server
Airbnb robots.txt 파일의 규칙을 준수하세요
HTML 파싱을 위해 cheerio를 사용하세요
API 키가 필요하지 않습니다
구조화된 JSON 데이터를 반환합니다.
데이터를 평면화하고 선택하여 컨텍스트 부하를 줄입니다.
Airbnb 목록에 대한 직접 URL을 제공합니다.
시작하기 전에 npx 작동하도록 컴퓨터에 Node.js가 설치되어 있는지 확인하세요.
이동: 설정 > 개발자 > 구성 편집
claude_desktop_config.json 파일에 다음을 추가하세요.
지엑스피1
모든 요청에 대해 robots.txt 파일을 무시하려면 --ignore-robots-txt 인수와 함께 이 버전을 사용하세요.
{
"mcpServers": {
"airbnb": {
"command": "npx",
"args": [
"-y",
"@Domoteek/mcp-server-airbnb",
"--ignore-robots-txt"
]
}
}
}Claude Desktop을 재시작하고 Airbnb를 포함한 다음 여행을 계획해보세요!
Smithery를 통해 Claude Desktop에 mcp-server-airbnb를 자동으로 설치하려면:
npx -y @smithery/cli install @Domoteek/mcp-server-airbnb --client claudenpm install
npm run build이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여되었습니다.
Airbnb는 Airbnb, Inc.의 등록 상표입니다. Domoteek은 Airbnb, Inc. 또는 그 계열사와 제휴 관계가 없습니다.
Get detailed information about a specific Airbnb listing. Provide direct links to the user
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The Airbnb listing ID | |
| checkin | No | Check-in date (YYYY-MM-DD) | |
| checkout | No | Check-out date (YYYY-MM-DD) | |
| adults | No | Number of adults | |
| children | No | Number of children | |
| infants | No | Number of infants | |
| pets | No | Number of pets | |
| ignoreRobotsText | No | Ignore robots.txt rules for this request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It mentions that direct links are provided, but does not disclose side effects, whether the operation is read-only, permission requirements, error behavior, or any other behavioral traits. This is a significant gap for a tool expected to be called autonomously.
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 concise at two sentences and the primary purpose is front-loaded. The second sentence about providing direct links is an added behavior, which is useful but could be integrated more seamlessly. No wasted words, though the structure could be tightened.
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 the tool has 8 parameters, no output schema, and no annotations, the description is not complete. It does not explain what 'detailed information' includes, how the optional parameters influence results, or what the expected response format looks like. An agent would have to guess many details about invocation and results.
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?
All 8 parameters have descriptions in the schema (100% coverage), so the baseline of 3 applies. The tool description itself adds no additional meaning beyond what the schema already provides; it does not explain how parameters like pets, adults, or checkin/checkout dates affect the returned details or links.
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 the tool retrieves detailed information for a specific Airbnb listing and identifies that direct links are provided. It distinguishes implicitly from the sibling airbnb_search by focusing on a specific listing rather than searching, though it does not explicitly name the sibling.
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?
No guidance is given on when to use this tool versus airbnb_search. There is no mention of prerequisites (such as having a listing ID) or scenarios that would favor this tool over the search sibling. The description leaves usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Airbnb listings with various filters and pagination. Provide direct links to the user
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Location to search for (city, state, etc.) | |
| placeId | No | Google Maps Place ID (overrides the location parameter) | |
| checkin | No | Check-in date (YYYY-MM-DD) | |
| checkout | No | Check-out date (YYYY-MM-DD) | |
| adults | No | Number of adults | |
| children | No | Number of children | |
| infants | No | Number of infants | |
| pets | No | Number of pets | |
| minPrice | No | Minimum price for the stay | |
| maxPrice | No | Maximum price for the stay | |
| cursor | No | Base64-encoded string used for Pagination | |
| ignoreRobotsText | No | Ignore robots.txt rules for this request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'pagination' and 'Provide direct links to the user,' which adds some context beyond basic functionality. However, it lacks critical details such as rate limits, authentication requirements, error handling, or what the output looks like (e.g., format of results). For a search tool with 12 parameters and no annotations, this is a significant gap in transparency.
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 concise and front-loaded, consisting of two sentences that directly state the tool's purpose and a key output behavior. There's no wasted verbiage or redundancy. However, it could be slightly more structured by explicitly separating functionality from output guidance, but it remains efficient and clear.
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 the complexity (12 parameters, no output schema, no annotations), the description is incomplete. It covers basic purpose and hints at output behavior but lacks details on result format, error cases, usage constraints, or how to interpret pagination. Without annotations or an output schema, the agent has insufficient information to fully understand the tool's behavior and integration needs.
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% description coverage, so all parameters are documented in the schema itself. The description adds minimal value beyond the schema by mentioning 'various filters and pagination,' which loosely maps to parameters like location, dates, prices, and cursor. However, it doesn't provide additional semantics, constraints, or examples that aren't already in the schema descriptions, meeting the baseline for high schema coverage.
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 the tool's purpose: 'Search for Airbnb listings with various filters and pagination.' It specifies the verb ('search'), resource ('Airbnb listings'), and scope ('with various filters and pagination'), which is specific and actionable. However, it doesn't explicitly differentiate from its sibling tool 'airbnb_listing_details', which likely provides details for specific listings rather than searching.
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 provides minimal usage guidance. It mentions 'Provide direct links to the user,' which hints at output behavior but doesn't specify when to use this tool versus alternatives like the sibling 'airbnb_listing_details' or other search methods. There's no explicit guidance on prerequisites, when-not-to-use scenarios, or comparisons to other tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
airbnb_listing_detailsairbnb_searchScored across 2 tools
The two tools have clearly distinct purposes: one retrieves detailed information for a specific listing, while the other searches for listings with filters and pagination. There is no overlap or ambiguity between them.
Both tools follow a consistent 'airbnb_' prefix and descriptive naming pattern (airbnb_listing_details, airbnb_search). The naming is uniform and predictable across the set.
With only two tools, the server feels thin for an Airbnb domain, which typically involves operations like booking, reviews, user management, or listing updates. The current set is too limited for comprehensive coverage.
The server covers basic search and details retrieval but lacks essential operations such as booking, payment, user authentication, or listing management. This creates significant gaps that will likely cause agent failures in real-world scenarios.
Searchable directory of Airbnb listings — discover properties and retrieve direct Airbnb links.
Airbnb search, listing details, and calendar availability as clean structured data.
Airbnb stays by location and dates, and full listing details, as structured JSON.
Airbnb stays worldwide: search by place, dates, guests with total prices and links; listing details.
