Vexa MCP Server

官方

面向 Google Meet、Teams 与 Zoom 的开源会议机器人与实时转写 MCP 服务

分类: 团队协作第 20 / 55
Stars: ★ 2.9k 非常热门
传输方式: Streamable HTTP
运行环境: 远程托管（无需本地环境）
凭据: 需要 API Key / 凭据
许可证: Apache-2.0
最近提交: 15 天前

57FMRS · C

Vexa 是由上游项目方维护的开源会议转写与机器人服务，以 MCP 形式暴露托管 streamable-http 端点（https://api.cloud.vexa.ai/mcp），需要 Bearer 形式的 Vexa API Key。它把机器人加入 Google Meet、Microsoft Teams 与 Zoom 的实时转写能力带给 AI 智能体，并支持完全自托管、Kubernetes 部署与隔离网络运行，采用 Apache-2.0 许可。适合需要数据主权、希望把会议内容编译为自有 Markdown 工作区的团队；不适合只需要托管 SaaS 的用户，或依赖尚未接线功能（中途改配置、机器人语音发言、WebSocket 多路复用）的场景。使用时需注意 API Key 保管、参会者知情同意与智能体对不可信输入的审批门控。

最强项 · 文档质量 14/20 最弱项 · 可靠性 9/20

可靠性

9/20

安全与权限

10/20

维护活跃度

13/20

文档质量

14/20

安装易用性

11/20

查看各项评分依据

可靠性 9/20: 静态证据显示该 MCP 服务器的启动链路是清晰的：唯一传输方式为托管的 streamable-http 端点 https://api.cloud.vexa.ai/mcp，仅需 Bearer 认证头，无需本地进程或构建，因此初始化与工具列表握手路径本身可被合理推断为可行。但来源中没有任何 CI 工作流、没有提交的测试、没有针对 MCP 端点本身的可复现执行证据，MCP manifest 也完全未列出任何 tools/resources/prompts，无法核对‘声明的工具与实际行为一致’这一核心要求。README 自我披露了多处功能缺口：WebSocket 传输未接通返回 404、PUT /bots/{…}/config 与 POST /bots/{…}/speak 返回 404、POST /agent/meeting/{start,process} 在开放核心栈中不可用；STT 缺失时 POST /bots 直接返回 503（默认依赖外部 GPU 转录单元或免费 token），capture-only 才需显式 opt-out；说话人归属明确不保证，重度串音下约 4–7% 行会返回空说话人。依赖面（Docker、Postgres、Redis、MinIO、GPU STT、外部 API key）较多且耦合，错误可诊断性依赖托管侧。综合：主路径合理但边界与错误处理证据薄弱，且存在自述的能力矛盾（MCP 端点无工具清单 vs README 宣称 MCP server）。保守评分 9。
安全与权限 10/20: 认证设计在方向上是最小权限的：远程 MCP 仅为 bearer token，manifest 将该头标记为 isRequired 与 isSecret，令牌取自用户账户页，示例中未出现真实密钥（使用 $API_KEY / vxa_… 占位符），符合不泄露凭据的要求。部署侧宣称数据不出本网、可空气隔离、bucket 中存放录制与工作区、可自带 LLM 端点，静态配置上未见隐蔽外发或恶意行为，未触及任一红线。但扣分点明确：manuscript 层面没有给出 MCP 工具粒度的权限范围说明，读/写/删除能力边界未在 MCP manifest 中定义；agent 运行被描述为可写工作区并能生成 git commit，属于有副作用的操作，文档仅以‘信任聊天可写入、不可信输入仅 propose-only’作原则性描述，未见针对 MCP 调用的显式确认机制；‘at-rest encryption（工作区/转录/令牌）’明确标注为 Planned 未实现；K8s 后端与 agent 容器依赖 Docker socket/集群权限，代理不自行强制隔离而是依赖底层 substrate，审计与速率限制未披露。风险可见但确认机制与作用域说明不完整，评 10。
维护活跃度 13/20: 维护活跃度信号较强：Apache-2.0 明确许可，版本号为 0.12.27，stars 2767，未归档，仓库内提供 SECURITY.md 漏洞报告渠道、security-insights.yml（OpenSSF Security Insights）、license-exceptions.json（依赖许可门禁）、architecture.calm.json（FINOS CALM，且宣称 CI 漂移门禁）、CONTRIBUTOR_RIGHTS.md（含 DCO）、deploy/helm 与公开 roadmap/board/milestone 治理。这些都指向持续维护与清晰的所有权与更新路径。扣分在于：open issues 高达 544，与 2767 stars 相比问题积压偏多，来源未给出响应时效或关闭率证据；文档中对 Helm/K8s 后端状态、Jitsi 实时验证、WS 与 mid-call 控制等多个功能仍标注进行中或 Planned，说明治理虽有但交付节奏尚在追赶；缺少可见的发布说明与依赖更新的具体证据（仅凭 README 自述，属不可信证据）。给 13。
文档质量 14/20: 文档层次相当完整：README 提供了动机、架构图、快速开始（托管 curl 与自托管 make all/lite/dev 三条路径）、环境变量与运行时后端（docker/process/k8s）说明、托管与自建两套 base URL、Meetings API 与 Agent API 的端点表、SSE 帧类型（message-delta、tool-call、commit、done、error）、平台枚举、STT 与 503 行为、定价（$0.30/hr，$5 新账户额度，约 16 小时）、以及一张诚实的状态与路线图表（Production/In progress/Planned 三态，含归属准确率 4–7% 空说话人披露、Jitsi 待验证、K8s 状态）。合规侧还给出 SECURITY.md、security-insights.yml、CALM、license-exceptions 等可审查材料。扣分点：面向 MCP 客户端的文档被外链到 docs.vexa.ai/vexa-mcp，本仓内缺少 MCP 工具清单、参数、返回结构与客户端接入示例；未说明速率限制与配额；v0.12 的 404 行为分散在正文与脚注中，容易被忽略；故障排查章节未在来源中出现。可读可用但存在隐藏假设与排障缺口，评 14。
安装易用性 11/20: 托管 MCP 路径极为轻量：只需一个 streamable-http URL 与 Bearer 密钥，密钥从 vexa.ai/account 获取，无需本地运行时、无需构建，客户端接入步骤少且明确，这是加分项。自托管路径也给了 make all / make lite / make dev / make probe / make down / make help 的清晰目标，并列出各服务与端口（Terminal 13000、Gateway 18056）。但扣分明显：自托管门槛不低——需要 Docker engine ≥ v26、make，Linux(Ubuntu 24.04) 为生产目标，转录为独立 GPU 单元且默认必需（缺失时 POST /bots 返回 503），完整栈涉及 gateway/terminal/meeting-api/agent-api/runtime/admin-api/redis/postgres/minio 共九个容器；agent plane 仅在自托管可用（托管服务不含），贡献者构建需 8 vCPU/16GB；生产需自行配置 TLS 反向代理；来源中没有任何主流 MCP 客户端（Claude Desktop、Cursor、VS Code 等）的具体配置文件示例，只有 curl 示例。步骤清晰但组件多、平台依赖重、缺少客户端配置样例，按静态上限保守给 11。

静态评测 · 未实际运行收录于 2026-09-10

查看 FMRS 评分方法 →

选型与风险

能访问什么读取本地文件写入 / 删除本地文件执行命令或代码访问网络

适合谁

希望自托管并完全掌控会议数据与转写内容的团队
需要在隔离网络（air-gapped）中运行会议智能的受监管行业组织
希望把会议转写接入自有 AI 智能体与知识库的开发者

不适合谁

只想使用托管 SaaS 且不需要自托管的用户（自托管专属能力如智能体平面不包含在托管服务中）
需要已完整支持中途修改机器人语言/任务或让机器人语音发言的用户（这些端点在开源核心中返回 404）
需要官方保证 100% 说话人归因准确率的场景（严重串话时约 4–7% 的行会输出空说话人）

所需权限

访问远程 MCP 端点需要 Vexa API Key（Authorization: Bearer 头，敏感凭证）
调用 HTTP API 需要 X-API-Key 请求头
自托管部署需要 Docker（建议引擎 ≥ v26）或 Kubernetes/OpenShift 集群
如需转写需配置 STT 服务或使用托管令牌；如启用录音需对象存储（MinIO）

风险与副作用

API Key 泄露可能导致他人以此身份发送机器人、读取转写与派发智能体
机器人加入会议会以参与者身份出现在通话中，需获得参会者知情与同意
录音与转写内容可能包含敏感信息，自托管时可使用 MinIO 等自有存储以控制数据边界
智能体处理不可信输入（邮件、网页）时应采用仅提议模式并保留人工审批，否则可能产生不可逆写入
开源核心中中途修改机器人配置与语音发言端点当前返回 404，不应依赖这些能力

安装接入

准备工作

运行环境：远程托管（无需本地环境）

托管方式：在 vexa.ai/signin 登录，从 vexa.ai/account 复制 API Key。
自托管方式：克隆仓库 https://github.com/Vexa-ai/vexa 并执行 make all（拉取已发布镜像并生成 .env、打印 API Key 与地址）；make lite 为单容器轻量部署，make dev 为从源码构建。
默认需要语音转写（STT）能力：使用 vexa.ai/account 的免费令牌，或在 deploy/transcription 部署 GPU 转写服务并在 .env 中指向它；缺少 STT 时 POST /bots 返回 503。
MCP 客户端连接地址为 https://api.cloud.vexa.ai/mcp（托管）或自托管网关的 /mcp 路径，使用 streamable-http 传输。
认证头：Authorization: Bearer <Vexa API key>，该请求头为必填且属于敏感凭证。
除 MCP 之外，也可以直接调用网关上的 HTTP API，使用 X-API-Key 认证。

验证是否装好

在 MCP 客户端中将服务器地址指向 https://api.cloud.vexa.ai/mcp，并在 Authorization: Bearer 头中填入从 https://vexa.ai/account 获取的 Vexa API 密钥；连接成功后询问某场会议的转录内容，若能返回带说话人标注的文本即说明配置生效。

常见排障

POST /bots 返回 503：通常是未配置语音转写（STT），请配置令牌或部署转写服务，或显式设置 transcribe_enabled=false 做纯采集
MCP 连接失败：确认使用 streamable-http 传输、URL 正确且 Authorization: Bearer 头携带有效 API Key
Agent API 返回的通用错误：确认使用 X-API-Key 认证，且身份由服务端根据密钥推导
实时转写查询：当前需轮询 GET /transcripts/{platform}/{native_meeting_id}，WebSocket 多路复用仍属计划功能
调用 PUT /bots/{...}/config 或 POST /bots/{...}/speak 返回 404：这些能力在开源核心中尚未接线

试试这样问

连接成功后，可以直接对 AI 助手这样说：

向我的 Google Meet 会议 abc-defg-hij 发送一个 Vexa 机器人并开始转录。
查看 google_meet 会议 abc-defg-hij 的实时转录文本。
给我简报一下 Acme 账户：所有会议、未决决策和下一步行动。
我们上次会议决定了什么？

使用场景

让机器人自动加入 Google Meet、Microsoft Teams 或 Zoom 会议并获取带说话人标注的实时转写

在会议进行中用 AI 智能体结合实时转写与自有工作区提问

通过定时（cron）例程生成晨间简报或会议纪要

在会议结束后自动派发一次性智能体输出报告、决议与行动项

以事件触发方式（如收到邮件）派发只读或仅可提议的智能体流程

浏览与读取以 Markdown（OKF kg/ 包）形式存储的工作区知识

支持客户端

Claude Code部分支持

Codex部分支持

依据项目文档列出，未经本站实测。

详细介绍

Vexa 是一个开源的会议机器人与实时转写服务，机器人可加入 Google Meet、Microsoft Teams 和 Zoom 通话，并以实时方式输出带说话人标注的转写内容。它提供 Meeting API（发送机器人、获取转写、录音）和 Agent API（工作区问答、定时例程、事件触发派发），并在网关的 /mcp 路径暴露 MCP 端点供 AI 智能体客户端使用。可自托管（Docker Compose 或 Kubernetes/OpenShift 上的 Helm），也可使用官方托管服务。源码以 Apache-2.0 许可发布，支持完全隔离（air-gapped）部署。