核心用法
resy-mcp 是一个基于 MCP（Model Context Protocol）协议的服务器，允许用户通过自然语言与 Resy 餐厅预订平台进行交互。安装后需配置 RESY_EMAIL 和 RESY_PASSWORD 环境变量，支持通过 npx 一键运行或源码构建部署。
主要功能模块：
- 餐厅搜索：按日期、人数、地理位置搜索可预订餐厅，支持关键词模糊匹配
- 座位预订：复合式一键预订（自动查找可用时段→获取详情→完成预订），支持指定偏好时间
- 预约管理：查看历史/ upcoming 预约，获取取消所需的
resy_token，执行取消操作 - 收藏与通知：维护"hit list"收藏清单，订阅 Priority Notify 排队通知，在热门餐厅释放座位时邮件提醒
典型工作流示例：
"今晚在旧金山找一家能订2人位的意大利餐厅" → resy_search_venues "预订 Carbone 下周三晚上7点2人位" → resy_book "取消我下周的预约" → resy_list_reservations → resy_cancel "4 Charles 有位置了提醒我" → resy_add_notify
显著优点
1. 自然语言交互：将复杂的餐厅预订流程抽象为对话式指令，大幅降低操作门槛
2. 功能完整度高：覆盖 Resy 核心场景——搜索、预订、取消、收藏、排队通知，实现闭环管理
3. 地理位置灵活：支持传入经纬度定位，默认 NYC 但可扩展至 Resy 覆盖的任意城市
4. 智能容错设计：resy_book 内部自动刷新短时效的 config_token，避免用户手动处理过期令牌
5. 开源透明：GitHub 开源，可审计实现逻辑，社区可贡献改进
潜在缺点与局限性
| 方面 | 具体限制 |
|------|---------|
| **API 合规性** | 使用 Resy 私有 Web App API（逆向工程），非官方授权，存在服务条款风险 |
| **认证方式** | 必须提供明文邮箱密码，虽本地缓存 token 但初始凭据暴露于环境变量 |
| **地理默认偏差** | 默认 NYC 坐标，其他城市用户需显式传入 lat/lng，增加使用摩擦 |
| **支付依赖** | 预订前必须在 Resy 官网绑定支付方式，无法通过 MCP 直接添加银行卡 |
| **令牌时效** | `config_token` 仅数分钟有效，高频并发场景下可能遇到竞态问题 |
| **通知延迟** | Priority Notify 依赖 Resy 邮件推送，非实时 WebSocket，热门餐厅释放座位可能存在秒级延迟 |
| **功能边界** | 不支持修改预约（只能取消重订），不支持特殊需求备注（如过敏信息、纪念日布置） |
适合人群
- 高频餐厅预订用户：美食爱好者、商务宴请组织者、约会场景规划者
- Resy 重度依赖者：常驻 NYC、LA、SF、Chicago 等 Resy 核心市场的用户
- AI 工作流整合者：希望将餐厅预订嵌入 Claude 对话流，实现"找餐厅→订位→发日历邀请"自动化
- 技术尝鲜者：愿意承担非官方 API 风险，追求效率优先于合规保守
不适合：对账户安全极度敏感者、Resy 非覆盖地区用户、需要企业级合规保障的场景
常规风险
| 风险类别 | 等级 | 说明 |
|---------|------|------|
| **服务中断** | 中高 | Resy 可随时更改私有 API 端点或密钥旋转，导致功能失效（作者提供 `RESY_API_KEY` 覆盖机制作为缓冲） |
| **账户封禁** | 中 | 违反 Resy ToS 使用非官方客户端，理论存在账号限制风险（实践中个人用户风险较低） |
| **凭据泄露** | 中 | 邮箱密码存储于本地 MCP 配置，多用户共享机器或配置提交 Git 时暴露 |
| **预订失误** | 低中 | 自然语言理解偏差可能导致错误时间/人数预订，建议关键操作后人工复核确认邮件 |
| **隐私合规** | 中 | 预订历史、地理位置等敏感数据流经 MCP 服务器，需信任作者实现不持久化存储 |
使用建议
1. 隔离凭证：使用专用邮箱注册 Resy，避免主邮箱密码暴露
2. 启用 2FA：在 Resy 官网开启双因素认证，降低凭据泄露后的账户风险
3. 验证关键预订：首次使用后检查 Resy 官方 App/邮件确认预约详情，建立信任基线
4. 监控 API 稳定性：关注 GitHub issues，如遇大规模失效可及时切换回官方渠道
5. 谨慎共享配置：.mcp.json 含明文密码，勿提交公共仓库或共享给不可信环境