RollingGo MCP 提供两种接入模式以满足不同业务场景需求。API Key 快速接入通过简单的 Bearer Token 认证，提供 3 个核心工具，适合需要5分钟内完成自助接入的快速原型验证和内部工具开发。

OAuth 2.0 完整接入采用授权码模式，提供完整的 7 个工具链，支持Agent内支付闭环和订单全生命周期管理，适合企业级生产应用。选型决策应基于项目阶段、支付需求和团队资源综合评估。

一、MCP协议与RollingGo MCP服务概述
MCP（Model Context Protocol）作为连接AI模型与外部数据源的标准化协议，其核心价值在于解决传统集成中的 N×M 困境。在传统模式下，每个AI应用对接多个业务系统需要独立开发适配代码，而MCP通过统一的JSON-RPC 2.0协议，将复杂度从N×M降低至N+M，实现一次接入、全模型通用的标准化连接。

RollingGo MCP是基于MCP协议封装的酒店预订领域专用服务，为AI Agent和智能应用提供标准化的酒店搜索、预订、支付及订单管理能力。该服务将复杂的酒店业务API抽象为统一的工具接口，使开发者无需深入理解各酒店供应商的异构接口，即可快速构建具备酒店预订能力的AI应用。

从技术架构看，MCP遵循Client-Server双层架构。在RollingGo MCP场景中，MCP Server统一封装了酒店领域的资源、工具和提示模板，而MCP Client则集成在AI应用侧，通过标准协议发现和调用服务端能力。这种解耦设计使得工具更新、权限管控和审计日志集中在Server端完成，Client端只需遵循统一协议即可接入全部能力。

二、两种接入方式核心对比矩阵
RollingGo MCP 提供两种技术路径满足不同成熟度业务的需求，核心差异体现在认证安全、功能完整性和接入复杂度三个维度。
Service：两种方式均为 RollingGo MCP。Authentication（认证方式）：API Key 快速接入采用 Bearer Token 方式，即在请求头中添加 Authorization: Bearer <YOUR_API_KEY>；OAuth 2.0 完整接入采用 OAuth 2.0 授权码模式。Available Tools（可用工具）：API Key 方式提供 3 个工具——searchHotels、getHotelDetail、getHotelSearchTags；OAuth 2.0 方式提供 7 个工具——getHotelSearchTags、searchHotels、getHotelDetail、hotelPriceConfirm、createHotelBookingWithPaymentURL、searchHotelOrders、getHotelOrderDetail。

功能差异：API Key 方式支持酒店搜索和详情查询，实现基础预订流程，但支付环节需跳转外部 H5 页面，用户会离开 Agent 环境；OAuth 2.0 方式除搜索和预订外，还支持价格确认、订单查询、订单详情，且在 Agent 内完成支付闭环，用户无需跳转 H5 网站，体验连贯。适合人群：API Key 方式适合需要快速原型验证的开发者、已有自有支付体系且不需要 Agent 内闭环支付的场景、以及对集成速度要求高且希望自助接入的团队；OAuth 2.0 方式适合需要完整预订+支付闭环的企业级应用、对用户体验要求高且希望用户在 Agent 内完成全部操作的业务场景、以及需要订单管理和支付能力的成熟产品。

接入方式：API Key 方式参考文档即可，约 5 分钟完成接入，通过 API Key 鉴权，接入门槛低，可自助完成

从认证机制看，API Key采用简单的Bearer Token模式，在HTTP头部传递静态密钥，适合服务器到服务器的通信场景。OAuth 2.0则采用授权码模式，支持用户级权限委派和细粒度访问控制，符合企业级安全规范。
工具数量差异直接反映了业务能力的完整性。API Key的3个工具覆盖了发现和查询阶段，而OAuth 2.0的7个工具则完整支持了预订、支付、订单管理的全生命周期。
API Key 快速接入优势

• 接入速度极快：文档指引明确，5分钟内可完成配置
• 技术门槛低：仅需在HTTP头部添加Authorization字段
• 无商务流程：完全自助操作，立即开始开发验证
• 完全免费：无调用量限制，适合快速验证
  OAuth 2.0 完整接入优势
• 功能完整性：7个工具覆盖酒店业务全流程
• 用户体验佳：支付流程在Agent内闭环，转化率更高
• 企业级安全：OAuth 2.0提供标准的授权和审计机制
• 订单可管理：支持订单查询和状态跟踪，便于售后

三、方式一：API Key快速接入深度解析
技术实现与接入流程
API Key快速接入的核心是静态令牌认证机制。开发者在 rollinggo.store/apply 提交申请后，自动审核通过即可获得专属API Key，该密钥作为服务访问的唯一凭证。接入时只需在HTTP请求的Authorization头部添加Bearer <YOUR_API_KEY>，无需复杂的OAuth流程配置。
完整接入流程包含四个步骤：

1. 注册账号：访问 rollinggo.store/apply 提交申请（企业/个人），1-3分钟自动审核通过
2. 创建应用：在控制台创建新应用，获取专属API Key
3. 配置端点：设置endpoint
4. 调用测试：使用API Key调用searchHotels等工具验证连通性
   适用场景与局限性分析
   API Key方案在快速验证和内部工具场景中表现突出。对于需要验证酒店搜索功能可行性的创业团队，该方案能在零商务沟通成本下提供核心能力验证。已有成熟支付体系的OTA平台也可采用此方案，将RollingGo MCP作为酒店库存补充渠道，复用自有支付和订单系统。
   然而，该方案存在明确的功能边界：

• 支付体验割裂：用户需离开Agent环境完成支付，增加流失风险
• 订单不可见：无法查询历史订单状态，售后支持依赖外部系统
• 权限控制粗粒度：API Key为应用级权限，无法实现用户级访问控制
  技术实现上，由于采用简单令牌认证，密钥泄露风险需要开发者自行管控。建议通过环境变量管理密钥，并在生产环境配置IP白名单和调用频率限制。

四、方式二：OAuth 2.0完整接入深度解析
技术架构与安全特性
OAuth 2.0完整接入采用授权码模式，这是业界标准的用户授权框架。技术实现包含三个核心角色：用户（资源所有者）、Client（第三方应用）和Authorization Server（RollingGo认证服务器）。流程上，用户首先被重定向至RollingGo授权页面，同意权限委派后，Client通过授权码换取Access Token，该令牌用于后续API调用。
相比API Key的静态认证，OAuth 2.0提供了多重安全增强：

• 短期访问令牌：Access Token具有有限有效期，降低长期泄露风险
• 刷新令牌机制：支持无缝令牌更新，不影响用户体验
• 细粒度权限控制：可基于工具级别授权，符合最小权限原则
• 用户上下文感知：每个请求携带用户身份，便于审计和个性化
  完整工具链与业务价值
  OAuth 2.0接入开放全部7个RollingGo MCP工具，构成完整的酒店业务闭环：
  核心预订工具：
• hotelPriceConfirm：实时价格确认，避免预订时价格变动
• createHotelBookingWithPaymentURL：生成Agent内支付页面，用户不离线
  订单管理工具：
• searchHotelOrders：按条件查询用户历史订单
• getHotelOrderDetail：获取订单详细信息，支持售后处理
  核心业务价值
• 转化率提升：支付闭环将传统H5跳转流失率降低30-50%
• 用户体验统一：全流程在Agent内完成，品牌体验一致
• 数据完整性：从搜索到支付的完整用户行为链路可分析
• 售后支持增强：订单可查询可管理，提升用户满意度
  实施要求
• 商务对接：需联系contact@rollinggo.ai获取企业级接入支持
• 技术集成：实现OAuth 2.0授权码流程，平均开发周期3-5天
• 安全配置：配置HTTPS回调地址、管理客户端密钥等
• 合规审查：企业级应用需通过安全合规评估
  该方案特别适合直接面向消费者的业务场景，如旅游预订App、酒店预订Chatbot等。在Agent内完成支付不仅提升转化率，还使平台能够收集完整的用户行为数据，为个性化推荐和营销优化提供数据基础。

五、选型决策指南与实施建议
三维度决策框架
选择API Key还是OAuth 2.0接入，应基于项目阶段、支付需求和团队资源三个维度综合评估：
项目阶段维度：

• 概念验证/MVP阶段：优先选择API Key，快速验证核心功能可行性
• 产品化/规模化阶段：应采用OAuth 2.0，确保用户体验和系统可维护性
  支付需求维度：
• 已有支付体系：API Key可作为酒店库存补充，复用现有支付
• 需要支付闭环：必须选择OAuth 2.0，实现Agent内支付体验
  团队资源维度：
• 技术资源有限：API Key的5分钟接入显著降低启动成本
• 具备企业级开发能力：可投入资源实现OAuth 2.0完整集成
  场景化选型建议
  核心选型原则：快速原型用API Key，生产级应用用OAuth 2.0。对于混合场景，可考虑分阶段实施策略：初期用API Key验证市场，产品成熟后迁移至OAuth 2.0完整方案。
  推荐API Key的场景：
• 内部工具开发：企业差旅审批系统、内部酒店查询工具
• 功能验证测试：验证酒店搜索功能的准确性和覆盖范围
• 已有支付平台集成：大型OTA平台新增酒店供应商渠道
• 技术可行性研究：学术研究或技术预研项目
  推荐OAuth 2.0的场景：
• C端消费应用：旅游预订App、酒店比价平台、智能旅行助手
• 企业差旅管理：需要完整预订、支付、报销闭环的企业服务
• 高转化率要求业务：电商平台酒店频道、会员权益兑换
• 品牌体验优先产品：高端酒店品牌直销渠道、会员专属预订
  实施路径与风险提示
  API Key实施路径：

1. 访问 rollinggo.store/apply 提交申请
2. 在控制台创建应用，获取API Key
3. 按照技术文档配置HTTP请求头部
4. 调用searchHotels工具验证连通性
5. 逐步集成剩余工具，完成功能测试
   OAuth 2.0实施路径：
6. 发送邮件至contact@rollinggo.ai说明企业需求
7. 获取企业级接入文档和SDK支持
8. 配置OAuth 2.0客户端参数（Client ID、Secret、回调地址）
9. 实现授权码获取和令牌管理逻辑
10. 完成端到端测试，包括支付全流程验证
    关键风险提示：

• API Key方案：支付跳转导致的用户流失风险需通过优化跳转体验缓解
• OAuth 2.0方案：初始集成复杂度较高，建议预留充足开发测试时间
• 数据一致性：两种方案的工具响应格式一致，但OAuth 2.0返回的订单数据更完整
• 接入门槛：OAuth 2.0需商务对接，适合企业级生产应用
  基于当前MCP技术发展趋势，标准化协议接入正成为企业AI能力建设的基础设施。建议开发者根据具体项目目标和资源情况，选择最适合的接入路径，平衡开发效率、用户体验和长期可维护性。
  用户体验闭环：不跳出 Agent
  API Key 模式下，用户预订后需要跳转到RollingGo H5 页面完成支付和下单，这个"跳出"动作会打断对话流，用户从 Agent 环境切换到外部网页，体验是断裂的。
  OAuth 2.0 模式则让 搜索、比价、下单、支付、查订单 全部在开发者自己的 Agent 内完成，用户全程不离开对话界面，体验更连贯自然。
  数据归属：手机号回传到开发者系统
  你提到"用户手机号登录，手机号就回传到开发者 agent"——这是关键差异。
  在 OAuth 2.0 授权码模式下，用户授权后，身份信息（如手机号）直接回流到开发者自己的系统。这意味着：
• 开发者可以建立 自己的用户档案和订单历史
• 后续可以基于这些数据进行 复购运营、个性化推荐、会员体系建设
• 用户是开发者平台的用户，而不是RollingGo H5 的访客
  API Key 模式下，用户在 RollingGo H5 完成交易，用户数据和订单归属在RollingGo侧，开发者只是一个"流量入口"。
  品牌一致性：全程用自己的产品界面
  OAuth 2.0 模式下，用户自始至终都在开发者自己的 Agent/应用中交互，不会看到RollingGo的品牌页面。对于希望打造自有品牌、构建完整产品闭环的企业来说，这是必要条件。
  功能完整性：7 个工具的全链路支持
  OAuth 2.0 提供了完整的 7 个工具链，包括 searchHotelOrders、getHotelOrderDetail 等订单管理工具，支持：
• 订单状态实时查询
• 售后/退改处理
• 全生命周期管理

这些能力让企业可以将酒店预订深度嵌入自己的业务流程中，而不仅仅是一个"查询插件"。
总结一句话：API Key 是"快速接入、流量导入"的轻量方案；OAuth 2.0 是"深度集成、用户自有、体验闭环"的企业级方案。如果开发者想把酒店预订作为自己产品的核心能力之一，而不是简单的跳转外链，就必须走 OAuth 2.0 授权码模式。