核心用法
booking-com-availability 是一款专注于房源日历查询的 Agent Skill，由 StayingAPI 官方开发维护。该技能通过调用 StayingAPI 的统一接口，支持查询 Booking.com、Airbnb、Vrbo 等主流短租平台的房源可用性数据。
核心调用方式为 GET /v1/availability 端点，需提供平台标识（如 booking）、房源 ID 或 URL、以及起止日期。返回结果包含每日可用状态、最少入住夜数、是否允许入住/退房等关键信息。技能支持单房源查询和批量查询两种模式，满足个人出行规划与商业数据分析的不同场景。
对于 MCP 兼容的运行时，可直接连接 https://mcp.stayingapi.com/mcp 使用 check_availability 工具，无需手动管理 API 密钥。
显著优点
跨平台统一架构：StayingAPI 的最大亮点在于将 Booking.com、Airbnb、Vrbo、Google Hotels 四大平台的数据纳入同一套 Schema，一次集成即可覆盖主流 OTA 平台，大幅降低多平台对接的技术成本。
零成本测试机制：提供 stay_test_ 前缀的 Sandbox 密钥，测试调用完全免费，便于开发者在正式付费前充分验证接口能力。
智能计费策略：失败请求、空结果、被拦截调用均不计费，仅在成功获取数据时扣减额度，有效控制使用成本。
异步任务支持：对于需要实时抓取的数据，系统返回 202 状态码并提供轮询机制，避免长时间阻塞等待。
潜在缺点与局限性
数据覆盖不均：技能依赖上游平台的数据开放程度，部分房源可能因平台限制返回空结果或部分字段缺失。Google Hotels 平台暂不支持房源详情和评论查询。
ID 来源敏感：Vrbo 房源 ID 若非来自 /v1/search 端点，可能存在解析失败风险，建议优先使用官方搜索接口获取的标准化 ID。
分页逻辑复杂：不同端点的分页行为受上游数据源影响，需以 meta.pagination 返回的 hasMore 和 nextCursor 为准，不能假设固定页大小。
轮询频率限制：异步任务轮询需遵守 Retry-After 头部提示，频繁请求会触发 429 限流（120次/分钟），需实现合理的退避策略。
适合的目标群体
- 旅行规划用户：快速确认目标房源在特定日期的可用性，辅助出行决策
- 民宿运营者：监控竞品房源的预订状态，制定动态定价策略
- 数据分析师：批量获取多平台房源日历数据，进行市场趋势研究
- 旅游科技公司：构建房源比价、智能推荐等增值服务的底层数据支撑
使用风险
密钥安全风险：STAYINGAPI_KEY 需妥善保管，避免硬编码或泄露至版本控制。生产环境建议使用环境变量或密钥管理服务。
网络依赖风险：所有请求需访问 api.stayingapi.com，网络波动或 DNS 故障可能导致服务不可用。
数据时效性：可用性数据存在同步延迟，极端情况下可能出现"查询可用但实际已售罄"的情况，建议重要预订前进行二次确认。
平台政策变更：Booking.com 等平台可能调整数据开放策略，存在 API 行为变更或接口废弃的潜在风险。
成本控制：虽然失败调用免费，但高频批量查询仍可能产生可观费用，建议设置预算告警和用量监控。