Composio Fathom 会议转录 Toolkit 支持与 OAuth 授权 URL 排查指南-迪斯科星球

Composio Fathom 会议转录 Toolkit 支持与 OAuth 授权 URL 排查指南

【免费下载链接】composioComposio powers 1000+ toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio

本篇指南围绕 Composio 官方知识库文档（docs/kb/articles/toolkits-fathom.md）展开，系统梳理 Composio 对fathom与granola_mcp两个会议转录工具包的支持范围、Fathom 的两种接入认证方式（OAuth2 / API Key），以及排查"授权 URL 报错"时的核心原则：授权 URL 是 provider 特定的，必须依据实际解析到的连接流程来判断对错。读完本文，你将掌握：如何确认某个会议转录工具是否受支持、如何为不支持的转录工具提交接入请求、Fathom 工具包的完整工具清单与认证配置字段、以及如何避免在 OAuth 重定向排查中把"provider 特有域名"误判为配置错误。

支持的会议转录工具包：fathom 与 granola_mcp

Composio 目前明确支持的会议转录（meeting transcription）工具包有两个：

工具包 slug	定位	认证方式	工具数量
`fathom`	AI 会议助手，可录制、转录并总结会议	OAuth2（Composio 托管）、API Key	7
`granola_mcp`	基于 Granola 官方 MCP server 的会议笔记工具	DCR_OAUTH	6

以上信息可在仓库的 docs/public/data/toolkits.json 中逐条核对，也可通过npx composio add fathom/npx composio add granola_mcp将对应工具包安装到你的 Agent 工作区（工具包 slug 同时出现在 ts/packages/cli/src/generated/toolkit-slugs.ts 中）。

遇到不支持的转录工具怎么办

知识库原文明确指出：如果客户请求的会议转录器不在支持列表中（例如 Otter），应引导其前往https://request.composio.dev/提交接入请求。这是一个独立于主仓库的官方需求收集入口，用于把新工具包的接入优先级交由用户投票/提交来决定，而不是在本地自行绕过认证体系去对接第三方 API。

需要区分的是：Composio 平台支持的工具包远不止转录类，本文所述支持范围仅针对会议转录/会议笔记这一类别。判断一个具体工具是否可用，最可靠的依据是 docs/public/data/toolkits-list.json 与 docs/public/data/toolkits.json 中的条目，而不是印象中的"热门工具一定支持"。

granola_mcp：元数据来自上游 MCP server

与 Fathom 这种由 Composio 直接维护的工具不同，granola_mcp走的是 MCP 镜像路线。仓库另一份知识库文档 docs/content/kb/guide/toolkits-granola-mcp.mdx 对此有明确说明：

Granola MCP 工具包使用的是Granola 官方 MCP server，工具名、描述、输入定义与响应元数据全部受限于上游 server 暴露的内容；
如果 Granola 上游只提供了工具名和描述，Composio 能暴露的元数据就只有这些；
如果上游没有声明响应/输出 schema，Composio 也无法凭空补造，因此空的输出 schema 本身并不能证明 Composio 目录数据过期；
当发现元数据不一致时，应记录确切的工具名与缺失字段，与当前 Granola 官方 MCP server 的行为对比后再下结论；若确认官方已暴露而 Composio 缺失，再带着对比细节联系 Composio 支持。

这一点与 TS SDK 源码中 ts/packages/core/src/models/Tools.ts 的注释相互印证：MCP 背书的工具包（granola_mcp、apify_mcp、tavily_mcp等）没有本地维护的完整工具目录，工具集合以运行时抓取的上游 MCP 定义为准。

Fathom 工具包全量工具清单

根据 docs/public/data/toolkits.json 中fathom条目的tools字段，该工具包（版本20260724_00）共暴露 7 个工具，覆盖"会议列表 → 转录 → 总结 → Webhook 通知"的完整链路：

工具 slug	名称	关键行为
`FATHOM_CREATE_WEBHOOK`	Create webhook for meeting content	创建 Webhook 接收新会议内容；payload 中至少包含 transcript、CRM matches、summary、action items 中的一项
`FATHOM_DELETE_WEBHOOK`	Delete Webhook	按 Webhook ID 删除不再需要的 Webhook
`FATHOM_GET_RECORDING_SUMMARY`	Get Recording Summary	获取指定录音的 AI 摘要；支持同步返回，也支持异步投递到`destination_url`参数指定的 Webhook
`FATHOM_GET_RECORDING_TRANSCRIPT`	Get Recording Transcript	获取完整会议转录（含说话人与时间戳）；支持同步/异步两种模式；响应中`speaker`是对象，应读取`speaker.display_name`而非当作字符串
`FATHOM_LIST_MEETINGS`	List Meetings	分页列出当前用户/组织的会议录音，可按日期、域名、会议类型、录制人过滤，并通过`include_*`参数做数据富化
`FATHOM_LIST_TEAM_MEMBERS`	List Team Members	分页列出组织内团队成员，可按团队名过滤或使用 cursor 分页
`FATHOM_LIST_TEAMS`	List Teams	分页列出组织内所有团队

值得注意的工程细节：官方对FATHOM_GET_RECORDING_TRANSCRIPT的指引是优先用它直接拉取转录，而不是通过list-meetings加include_transcript=true来批量取，因为后者在会议数量较多时会产生极大的响应体——这直接关系到你在 Agent 工作流中如何设计"取转录"这一步，以避免 token 与内存浪费。

Fathom 的两种认证接入方式

fathom工具包在 docs/public/data/toolkits.json 中声明了两种认证方案：OAUTH2与API_KEY，其中 Composio 托管（composio-managed）的认证方案是OAUTH2。

方式一：OAuth2（推荐，Composio 托管）

OAuth2 模式对应的 auth config 名为fathom_oauth，其创建字段如下：

字段	必填	默认值	说明
`client_id`	是	—	你在 Fathom 开发者平台创建的应用 Client ID
`client_secret`	是	—	对应的 Client Secret
`oauth_redirect_uri`	否	`https://backend.composio.dev/api/v1/auth-apps/add`	需加入 Fathom 应用 OAuth 白名单的回调地址
`scopes`	否	`public_api`	向用户请求的权限范围，逗号分隔

在默认托管模式下，你无需关心client_id/client_secret，直接发起连接即可；只有当你需要自定义 OAuth 应用（如白标、独立配额、自定义 scope）时，才需要在 dashboard 创建自定义 auth config 并填写上述字段。仓库文档 docs/content/docs/auth-configuration/custom-auth-configs.mdx 给出了何时该自定义 OAuth 的决策表：工具包无托管认证、需要白标展示自有应用名、共享配额触顶、需要额外 scope、或需要连接自建实例/子域。白标场景的具体做法见 docs/content/docs/auth-configuration/white-labeling.mdx。

方式二：API Key

API Key 模式对应的 auth config 名为fathom_api_key。此模式下创建 auth config 本身不需要任何字段，真正的凭据在"发起连接（connected account initiation）"阶段提供：

字段	必填	说明
`generic_api_key`	是	允许 Composio 读取你的 Fathom 会议与转录的密钥；在 Fathom 后台Settings → API Access（fathom.video/customize）中创建

两种模式二选一即可。API Key 模式适合不想走完整 OAuth 流程、仅需读取会议内容的场景；OAuth2 托管模式则更适合需要 Webhook 订阅、多用户授权等完整能力的生产级使用。

OAuth 授权 URL 是 provider 特定的：排查核心原则

这是本知识库文章最重要的排障结论：授权 URL（authorization URL）取决于连接流程中所涉及的具体 provider/toolkit。不同供应商的 OAuth 授权端点域名各不相同，例如 Fathom、Granola 各自的授权域名是不同的。因此：

先确认 auth config 与连接流程实际解析到了哪个 provider：检查你创建的 auth config 所用的认证模式（fathom_oauth/fathom_api_key/ 自定义 OAuth 应用）以及该 toolkit 声明支持的 auth scheme；
再对照该 provider 的授权域名：如果跳转到的授权域名与该 provider 的官方域名一致，即使它看起来与你预期中的"通用域名"不同，也不应直接判定为错误；
不要以"域名眼生"为由臆断配置错误：把 provider 特有授权域名当作异常，是 OAuth 重定向排查中最常见的误判来源。正确做法是核对 auth config 中配置的client_id/client_secret/oauth_redirect_uri（默认https://backend.composio.dev/api/v1/auth-apps/add）是否与 Fathom 侧 OAuth 应用白名单一致，再结合实际落地的授权 URL 判断问题出在配置还是 provider 侧。

排查建议清单

在 dashboard 的Authentication management中查看该连接的 auth config，确认 mode 是OAUTH2还是API_KEY，并核对 provider 名称；
若使用自定义 OAuth 应用，确认oauth_redirect_uri已加入 Fathom 应用的回调白名单（该字段默认值即 Composio 后端回调地址）；
若使用托管（managed）OAuth，确认连接流程中的授权域名属于对应 provider 官方域，不要与 API Key 模式混用；
对granola_mcp这类 MCP 镜像工具包，认证走DCR_OAUTH（动态客户端注册），排查时优先对照上游 Granola MCP server 行为，参见 docs/content/kb/guide/toolkits-granola-mcp.mdx。

企业官网建设流程全解析