核心用法
opentable-mcp 是一个基于 MCP（Model Context Protocol）的餐厅预订管理工具，通过自然语言指令操控 OpenTable 平台。它并非官方 API 封装，而是借助 fetchproxy 浏览器扩展，在已登录的 opentable.com 标签页中代理执行操作，实现零配置鉴权——无需粘贴 Cookie、无需处理密码，依赖浏览器现有的邮件 OTP 会话状态。
关键能力：
- 餐厅发现：按关键词、位置、日期、人数搜索，获取菜系、价格区间、评分等信息
- 实时查位：查询指定日期的可预订时段，获取限时有效的 reservation_token
- 完整预订流程：支持普通即时预订、需预览的信用卡担保预订、以及必须选择套餐的 Experience 预订
- 预约管理：查看即将/历史预约、取消预订（需 confirmation_number + security_token）
- 收藏夹：增删餐厅收藏（存在约 10 秒读写延迟）
- 修改预约：通过 preview→commit 模式安全变更时间/人数/区域，避免取消重订导致的抢单风险
使用门槛：必须同时安装 npm 包 opentable-mcp 和 fetchproxy 浏览器扩展（Chrome/Safari），保持 opentable.com 标签页登录状态。扩展状态通过工具栏徽章（绿/黄/红）直观展示。
显著优点
1. 零凭据架构：用户侧无需管理 API Key、OAuth 令牌或密码，鉴权完全委托给浏览器端的 OpenTable 邮件 OTP 会话，降低了凭据泄露风险
2. 功能覆盖完整：涵盖搜索、查位、预订预览、支付担保、取消、修改、收藏等全链路，甚至处理了 OpenTable 内部三种 booking_type（instant/experience_mandatory/listing-only）的差异逻辑
3. 透明风控处理：文档明确标注了 Akamai WAF（_abck Cookie）轮换、Apollo persisted query 哈希失效等反爬机制，并给出手动修复指引
4. 防御性设计：CC 担保预订强制 preview→commit 两步流程，确保用户在知情（取消政策、扣款卡号后四位）后确认；修改预约避免"取消+重订"的竞态风险
潜在缺点与局限性
1. 架构脆弱性：依赖 fetchproxy 扩展和特定浏览器标签页状态，Chrome MV3 Service Worker 30 秒休眠会导致冷启动延迟 2-5 秒；扩展崩溃或标签页关闭即服务中断
2. 非官方实现风险：调用 OpenTable 内部 GraphQL 端点（window.__APOLLO_CLIENT__ 等），属于未公开契约，随时可能因对方部署变更而失效（文档已提示 PersistedQueryNotFound 修复方式）
3. 地域与平台限制：fetchproxy 扩展需手动安装（GitHub 下载或侧载），未上架 Chrome Web Store 主区则普通用户安装门槛高；Safari 版本为 .dmg 分发，更新滞后
4. 用户体验摩擦：dining_area_id 强制要求、slot token 90 秒超短有效期、收藏读写延迟等技术细节暴露给用户，增加认知负担
5. 无支付信息访问：出于安全设计，无法读取完整卡号，但这也意味着 preview 阶段无法让用户切换支付方式，只能使用 OpenTable 账户默认卡
适合人群
- 技术型美食爱好者：愿意配置 MCP 环境、安装浏览器扩展，追求"对话式订餐厅"效率
- 多预约管理者：需要快速查看、取消、修改多个预约的场景（如行政助理、活动策划）
- OpenTable 重度用户：已有账户、默认支付方式、熟悉其取消政策的用户
常规风险
- 账户风控：高频/异常模式操作可能触发 OpenTable 或 Akamai 的 bot 检测，导致临时限制或强制重新验证
- 预订失效风险：slot token 过期、扩展状态异常可能导致预览成功但提交失败，热门时段存在被其他用户抢占窗口
- 隐私边界：fetchproxy 扩展需访问 opentable.com 页面 DOM 和 Cookie，虽为本地代理，但权限较大
- 项目可持续性：个人开源项目（
chrischall维护），无商业背书，长期维护承诺不明