Skip to main content
Glama
enesjakoruzh
HasData

Airbnb MCP Server

by HasData
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Airbnb MCP Server

ホスト型のModel Context Protocol（MCP）サーバーで、Claude、Cursor、Windsurf、その他のあらゆるMCPクライアントに、読み取り専用のAirbnbツールを2つ提供します。場所と日付による滞在先検索、および個別リスティングの全文読み取りを、すべて構造化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 Deskopで実践的に実行しています。他のブックは、各クライアント独自のリモートサーバー用ドキュメント形式に従います。

フィールド

値

URL

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

トランスポート

HTTP、ストリーム可能

認証ヘッダー

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 Deskopはローカル（stdio）サーバーだけを読み込むため、stdioランチャーを介してリモートサーバーに到達します。@hasdata/airbnb-mcpパッケージがそのランチャーで、環境からキーを読み取ります。これをclaude_desktop_config.jsonに追加します：

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

Pythonの場合はNodeの代わりに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クレジットかかるためです。

オースティンで大人2名、9月15日から18日の滞在先を検索し、1泊200ドル未満で評評価が高い上位10件を教えてください。

1コール、5クレジット。評評価と1泊料金は検索結果に含まれます。

最上位の結果について、設設備、ゲスト数、ベッドルーム数、ホスト詳情を全て取てください。

1コール、5クレジット。これらはプロパティページにあり、詳情ツールがURLで読取ります。

オースティンでの大人2名、3泊の1泊料金を、ナッシュビルと比較してください。

2コール、10クレジット。各都市に1回の検索です。

このリステイングURLについて、ベッドとバスの数、ホストがスーパーホストかどうかを教えてください。

1コール、5クレジット。

検索結果は意図的に軽量で、順位付けや絞り込みに十分な内容です。アメニティ、ベッド、ホスト、詳しい説明はプロパティ・コールから得られるため、3軒に絞り込んで詳調べるプロンプトは、検索1回とプパティ・コール3回になります。

ツール

読取専用の2つのツール。以のサンプルは実コールから簡略したもので、数値はAirbnbの更新に伴い動きます。形として読取ってください。各ツール名は、完全なフィールドリストを載せたエンドポイント・リファレンスにリンクしています。

サンプルはペイロードであり、レスポンス全体ではありません。tools/callの結果にはテキスト・ブックが1つ含まれ、そのテキスト自体がurl、status、text、jsonを保持するJSONであり、スケレープされたデータはjsonの下にあります。生のJSON-RPCレスポンスからのパスはresult.content[0].textをパースし、その.jsonです。チャット・クライアントはこれを自動で展かし、エンドポイントに直に話すコードは自で行う必があります。

Airbnbリスティングの取得

hasdata_airbnb_listing_getAirbnbListings

場と日付による検索結果の1ページ。

パラメータ

型

必須

注記

location

string

はい

検索する場、例えばAustin, Texas

checkIn

string

はい

チェックイン日、YYYY-MM-DD

checkOut

string

チェックアウト日、YYYY-MM-DD

adults / chilren / infnts / pets

number

ゲスト構、各カウント

nextPageToken

string

前回レスポンスのpagination.nextPageToken

propertes配列とpaginationを返し、そのnextPageTokenとpageTokensで結果セットを巡します。各プパティにはid、url、title、latitude、longitude、短いdescriptionタグライン、photos配列、rating、reviews、Guest favoriteやSupehostなどのbadges配列、priceオブジェクが含まれます。priceはoriginalPrice、割引された滞在の場合の任意のdiscountedPrice、for 3 nightsのようなqualifier、breakownを保持します。

検索結果は意図的に軽量です。ベッド、バス、アメニティ、ホスト、詳しい説明はここにはなく、以のプパティ・ツールから得られます。検索結果にベッドルーム数を期待しないでください。

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

URLによる1つのリスティングを完に。

パラメータ

型

必須

注記

url

string

はい

AirbnbリスティングURL。検索結果のurlフィールド

title、["4 guests", "2 bedrooms", "2 beds", "2 baths"]のようなoverview配列、完なdescription、rating、reviews、address、latitude、longitude、photos配列、guestCapacity、hostオブジェク、amenities配列、saetyAndPropertInfoを返します。hostオブジェクにはname、isSupehost、isVerified、ホスト自身のreviews、rating、yearsHostingが含まれます。各アメニティにはtitle、type、任意のdescription、availbleフラグが含まれ、フイルタはavailbleを読取るため、リステイングされた全アメニティが存すると前提視しません。

{
  "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で応答し、問のフィールドを名指します。何も取されず、何も請求されません。

可能在のない検索は、空のpropertes配列を伴う成功結果を返します。エラーではありません。何も空いない場と日付範でも、requstMetadata.statusがokに設定されて戻ります。イテレートする前配列長をテスとします。

削除されたリスティングは400を返し、requstMetadata.statusがerrorに設定されます。古い検索のURLが、消えたホームを指している可能性があります。

データを伴う結果にはrequstMetadata.idも含まれ、サポートで引用する価値があります。

価格、無料ティア、制限

各Airbnbツールは成功コールごとに5クレジットです。レスポンスサイズは価格に影響しません。多数の滞在先がある検索ページも、2件だけの場も同額です。

無料トライアルはカー不要で30日間1,000クレジット、つまりAirbnbコール200回です。その後、活発なアカウントは残高が100を下るたびに毎日100クレジットをチャージされ続けるため、低ボリュームのエージェントは無期に無料ティアで動きます。

有料プランは月額$49からで200,000クレジット、つまり40,000コールです。単価はボリュームに応じて下がり、エントリー・プランの1,000コールあたり$1.23から、Businessで**$0.50**、Growthで**$0.42**、最も大な高ボリューム・プランでは**$0.37**です。

プランは同時接続数も定します。無料トライアルは同時1リクエスト、Startup 15、Business 30、Growth 50、高ボリューム・プランは200から1,500です。無人動なものでは防衛的にオーバーフローを処理してくたさい。

非200で返るリクエストは課金されません。何も見つからない成功コールはそれでも1コールです。

ツールの選択

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で失敗し、ボディには認できなかっものと有効な全値の両方が列されます。パラメータを省くと同じエンドポイントが全57のHasDataツールを公開します。

他のサービスとの比較

Airbnbには公開検索APIがありません。AirbnbのAPIプログラムは、自分のリスティングを管理するためのパートナー／共同ホスト向け統合であり、市場を読み取る手段ではありません。滞在先の検索や任意のリスティングの閲覧には、公開ページのスクレイピングが唯一の方法であり、このサーバーは安定したスキーマを通じてそれを実現します。

Airbnb partner API

このサーバー

目的

自分のリスティングを管理

公開市場を読み取る

アクセス

パートナー承認

1つのキーと1つのURL

市場全体の検索

いいえ

はい

セットアップ

法人向けオンボーディング

不要

出力

パートナー向けペイロード

構造化JSON、価格と評価を事前解析済み

このサーバーが行わないこと。 予約も、メッセージングも、ホスト向けダッシュボードも、ゲストデータも扱いません。ログアウトした訪問者に見える内容だけを読み取ります。

FAQ

公式のAirbnb MCPサーバーはありますか？

Airbnbは公式のものを公開していません。このサーバーはHasDataがメンテナンスしており、公開ページを読み取るため、Airbnbの開発者アカウントは不要です。

Airbnb MCPサーバーとは何ですか？

Airbnbのデータを、AIクライアントが呼び出せるツールとして公開するサーバーです。クライアントはModel Context Protocolを介してツール呼び出しを送信し、サーバーはデータを取得して構造化JSONを返し、モデルがその結果を処理します。このサーバーは2つのツールを公開し、リモートで実行されます。

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サーバーのドキュメント

1つのサーバーに全57ツール

HasData/hasdata-mcp

クライアント向けウォークスルー

MCPクライアントとインテグレーション

その他にスクレイピングするすべて

Airbnb Scraper APIと他54件

プランとクレジット費用

プランとクレジット費用

キーと利用状況

HasDataダッシュボード

npmのNodeランチャー

@hasdata/airbnb-mcp

PyPIのPythonランチャー

hasdata-airbnb-mcp

開発

このリポジトリは、リモートサーバーの設定とドキュメントです。ビルドステップはなく、コンテナ化するものもありません。

test/内のテストはツール契約を検証します。これは、ここへのコミットなしでも壊れ得る部分です。テストは、?apis=airbnbが正確に2つのツールを返すこと、すべてのツールが必要パラメータを引き続き宣言していること、名前が変更されていないこと、そして使用中のキーが実際に受け入れられることを確認します。最後のチェックは実際にツールを呼び出し、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
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

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

Resources

Related MCP Connectors

Related MCP Servers