企业官网建设流程全解析

Zoom MCP 会议生命周期管理：REST 承担 CRUD、MCP 承担语义检索的分工与混合模式实践

【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins

导读

在 knowledge-work-plugins 仓库的 Zoom 插件中，Zoom MCP 服务器（mcp-us.zoom.us）为 AI Agent 提供语义化会议检索、会议资产与录制资源获取等能力，但不暴露确定性的会议创建、更新、列举与删除工具。本文以 zoom-mcp/examples/meeting-lifecycle.md 为骨架，结合仓库内 Zoom MCP 工具目录、OAuth 配置与 REST API 文档，讲清"何时用 MCP、何时改走 REST"的边界，并给出可复制的 MCP→REST 混合调用模式，帮助你为 Agent 设计正确的会议生命周期路由策略。

MCP 工具面的现状：没有确定性的 CRUD 工具

当前 Zoom MCP 的托管服务器对 AI Agent 暴露的能力集中在检索与内容获取方向。根据 zoom-mcp/SKILL.md 与 zoom-mcp/references/tools.md，主 MCP 服务器只公开四个工具：

仓库文档明确记录：在一次探测中，主 MCP 服务器并未暴露list_meetings、get_meeting、create_meeting、get_user_profile、list_available_tools等被误传的旧工具名（见 references/tools.md 的 Discovery Notes）。这一点与 meeting-lifecycle.md 开篇的判断完全一致：MCP 不提供确定性的 create / update / list / delete 会议工具。

如果你需要会议生命周期管理（建会、改期、删除、确定性列举），请直接路由到 REST API skill：rest-api/SKILL.md，而不要假设 MCP 表面存在会议 CRUD。

Zoom MCP 擅长什么：语义检索与内容获取

MCP 的价值不在"改数据"，而在"找到内容并拿回相关资源"。依据 meeting-lifecycle.md，Zoom MCP 适合处理以下场景：

• 对会议的语义搜索：search_meetings不是简单的标题过滤，而是基于 AI Companion 检索的内容级搜索，覆盖会议内容、纪要关联资产与录制相关产物（见 concepts/mcp-architecture.md 的 Retrieval Model）；
• 会议关联资产检索：get_meeting_assets返回某个会议的摘要、录制引用、关联文档、白板链接等资产包；
• 录制资源检索：get_recording_resource返回含转写时间线、摘要片段、下一步行动片段、播放 URL 等录制相关资源；recordings_list按用户/时间范围列举云端录制；
• 从 Markdown 创建 Zoom Docs：注意这一步要走独立的zoom-docs-mcp服务器（mcp.zoom.us/mcp/docs/streamable），工具为create_file_with_content与get_file_content，而不是主zoom-mcp服务器。

完整的检索工作流（"按主题搜索 → 取资产"与"按录制列举 → 取录制资源"两条路径）见 examples/transcript-retrieval.md 和 examples/search-and-act.md。

必须改走 REST 的操作：确定性 CRUD

当用户要求的是确定性的资源管理时，应使用 REST API：

• 创建会议（POST /v2/users/{userId}/meetings，对应meetingCreate，见 rest-api/references/meetings.md）；
• 改期或更新会议（PATCH /v2/meetings/{meetingId}，部分字段更新，成功返回 204）；
• 确定性列举已排定的会议（GET /v2/users/{userId}/meetings?type=scheduled&page_size=30，支持next_page_token分页）；
• 删除会议或单次实例（DELETE /v2/meetings/{meetingId}，可选occurrence_id删除周期性会议的单次发生）。

这些端点全部基于https://api.zoom.us/v2基础地址，并且要求 REST 层面的 scope（如meeting:write、meeting:read）。完整可运行的 curl 与 Node.js 示例（Create → Update → Get → List → Delete，含 webhook 事件集成）见 rest-api/examples/meeting-lifecycle.md。

混合模式：MCP 先行发现，REST 随后管理

meeting-lifecycle.md 给出的核心编排建议是：当用户从"会议内容/纪要"意图出发时，先用 MCP 完成发现与内容获取；只有当下一步动作变成确定性的资源管理步骤时，再切换到 REST。

典型调用序列如下：

1. search_meetings q: "client onboarding" from: "2026-03-01" to: "2026-03-06" 2. get_meeting_assets meetingId: "MEETING_ID_OR_UUID" 3. 如果用户随后想改期或删除该会议， 则路由到 zoom-rest-api，在那里执行 CRUD 操作。

这一模式在 examples/search-and-act.md 中同样被强调：search_meetings拿到目标会议 →get_meeting_assets检查资产 → 遇到"create / reschedule / update settings / delete"类需求时，明确路由到 rest-api/SKILL.md。

实际工程中还可以扩展为更完整的混合管线：

1. MCP 语义搜索：用户只记得"上季度关于某主题的会"，用search_meetings按关键词与时间窗找回；
2. MCP 资产/录制检查：get_meeting_assets或get_recording_resource确认目标并取回纪要、转写、录制引用；
3. REST 确定性操作：用户要求"把这会改到周五下午"或"删掉 3 月 10 号的周会"，切换到 REST 执行PATCH /v2/meetings/{meetingId}或DELETE /v2/meetings/{meetingId}；
4. （可选）事件驱动闭环：借助 webhook 事件（meeting.created、meeting.updated、meeting.deleted、meeting.started、meeting.ended、recording.completed）驱动后续自动化，参见 rest-api/examples/meeting-lifecycle.md 的 Webhook Integration 章节。

应当路由到 REST 的示例 Prompt

仓库文档给出了四类典型的、Agent 应判定为"改走 REST"的用户表述（见 meeting-lifecycle.md）：

• "Create a 45-minute design review for next Tuesday."—— 新建会议 →POST /v2/users/{userId}/meetings，设置type: 2（定时会议）、duration: 45、start_time；
• "Move my Q1 planning meeting to Friday at 3pm Pacific."—— 改期 →PATCH /v2/meetings/{meetingId}，更新start_time与timezone；
• "Delete the team sync meeting scheduled for March 10th."—— 删除 →DELETE /v2/meetings/{meetingId}；
• "Show me all my scheduled meetings for this week."—— 确定性列举 →GET /v2/users/{userId}/meetings?type=scheduled配合时间过滤。

反向地，如果用户表述是"找一下关于某主题的会并总结""拉取上周全员会的录制资源"，则留在 MCP 侧即可。

为什么是这种分工：仓库证据链

1. 工具目录与 Scope 设计

主 Zoom MCP 服务器通过 OAuth protected-resource 元数据声明的 scope 家族为（见 concepts/mcp-architecture.md 与 references/tools.md）：

• ai_companion:read:search—— 跨会议/聊天/文档的语义搜索；
• meeting:read:search、meeting:read:assets—— 会议搜索与资产读取；
• cloud_recording:read:list_user_recordings、cloud_recording:read:content—— 录制列举与内容读取；
• docs:write:import、docs:read:export—— Zoom Docs 导入/导出。

全部是read / 内容侧scope，没有任何meeting:write一类的写权限，这与"CRUD 不在 MCP 表面"的定位互为印证。而 REST API skill 明确要求meeting:write、meeting:read才能做会议管理（见 rest-api/SKILL.md 的 Prerequisites 与 rest-api/examples/meeting-lifecycle.md）。

2. 认证模型差异

MCP 走General app + 用户级 OAuth，token 由插件通过 .mcp.json 中以Authorization: Bearer ${ZOOM_MCP_ACCESS_TOKEN}注入到https://mcp-us.zoom.us/mcp/zoom/streamable（Streamable HTTP，另有 SSE fallback）；REST 侧则更常使用 Server-to-Server OAuth 做服务端自动化。注意：MCP 使用的粒度化 scope 与旧的宽泛 REST scope 不是同一套，配置 token 时务必核对 MCP 专属 scope（见 concepts/oauth-setup.md）。

3. 错误码印证

references/error-codes.md 记录了 MCP 协议层错误（-32001无效 access token、-32602找不到工具、-32603调用处理失败）以及各工具缺失 scope 时的精确报错（如search_meetings缺meeting:read:search、get_meeting_assets缺meeting:read:assets）。当 Agent 试图在 MCP 上执行不存在的工具时，-32602 Can not found tool会直接出现——这正是"不要在 MCP 上做 CRUD"最直观的运行时证据。

REST 侧落地要点与常见陷阱

把 CRUD 落到 REST 后，以下要点来自 rest-api/examples/meeting-lifecycle.md 与 rest-api/SKILL.md，值得在实现路由时一并考虑：

• 会议类型：type: 1即时会议、type: 2定时会议、type: 3周期性（无固定时间/PMI）、type: 8周期性（固定时间）；
• me关键字规则：用户级 OAuth 应用必须用me代替userId；Server-to-Server OAuth 应用禁止用me，需显式传 host 用户 ID 或邮箱；
• Meeting ID 与 UUID：以/开头或含//的 UUID 需要双重 URL 编码；
• 时间格式：yyyy-MM-ddTHH:mm:ssZ表示 UTC；无Z时表示本地时间，配合timezone字段；
• 限流与配额：限流按账号共享而非按应用隔离；单个用户每天的会议创建/更新操作硬限制为100 次（UTC 00:00 重置），批量操作应分摊到不同 host 用户；
• 删除响应：PATCH/DELETE成功通常返回 204 No Content；周期性会议可通过occurrence_id只删单次。

# 以用户级 OAuth 为例，创建 45 分钟定时会议（对应上文第一个示例 Prompt） curl -X POST "https://api.zoom.us/v2/users/me/meetings" \ -H "Authorization: Bearer ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "topic": "Design Review", "type": 2, "start_time": "2026-09-22T15:00:00Z", "duration": 45, "timezone": "America/Los_Angeles", "settings": { "join_before_host": false, "waiting_room": true } }'

给 Agent 的路由决策清单

综合 meeting-lifecycle.md 与 examples/search-and-act.md，Agent 可按以下规则决策：

记住一条总原则：MCP 负责"发现与理解"，REST 负责"确定性的增删改查"。先判断用户是否真的需要资源管理操作，再决定路由，能最大程度避免-32602 Can not found tool一类的误调用，也让 Agent 的会议生命周期处理既快又稳。

延伸阅读

• zoom-mcp/SKILL.md：主 MCP 服务器完整工具目录、端点、错误速查
• zoom-mcp/references/tools.md：各工具参数与实时 schema 注意事项
• zoom-mcp/examples/transcript-retrieval.md：MCP 检索两条主路径
• zoom-mcp/examples/search-and-act.md：搜索-行动模式与 REST 交棒时机
• zoom-mcp/concepts/oauth-setup.md：MCP 专属 scope 与 token 生命周期
• rest-api/SKILL.md：REST API 总览、base URL、限流与陷阱
• rest-api/examples/meeting-lifecycle.md：会议 CRUD 完整可运行示例与 webhook 集成

【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins