需要大量第三方 SaaS 操作时使用 Composio，需要执行按用户身份授权的工具时使用 Arcade，需要封装现有 REST 端点时使用 RapidMCP，产品特有且要求精确语义的工作流则适合自定义 MCP 工具。同一个产品可以组合多种方案，因为这些平台解决的是不同的集成问题。
比较功能数量前，先对所需工具进行分类。Gmail 操作与产品特有的计费决策，不应该采用同一个自建或购买答案。
各种方案分别优化什么
Composio
Composio 提供大量第三方应用工具包，以及托管式身份验证、已连接账户、trigger、日志和基于会话的发现功能。其会话文档会针对一次 agent 运行限定用户、工具访问、身份验证、已连接账户和执行状态。
如果产品需要 GitHub、Slack、Gmail、Notion 或 CRM 操作等大量常见 SaaS 操作，可以使用它。会话应只开放工作流所需的工具包和操作，而不是整个目录。
Arcade
Arcade 专注于带身份验证的 agent 工具，以及代表各个用户执行这些工具所需的授权。其文档涵盖工具开发、用户身份验证、授权和执行。
如果核心集成问题是代表各用户执行操作，而且团队希望使用托管授权与工具运行时，可以选择它。
RapidMCP
RapidMCP 将 REST 端点映射为托管 MCP 工具，并配置身份验证、header、参数和 trigger。其概览明确介绍了一个工具对应一个端点的映射方式。
它适合快速封装一个规模较小、设计已经成熟的 API，但需要仔细审核生成的边界。一对一转换可能会公开内部端点，而不是模型应该选择的任务级工具。
自定义 MCP 工具
如果工作流属于产品核心行为、需要组合多项内部服务、具有严格的数据位置要求，或需要精确控制授权、幂等性和结果契约，应自行构建工具层。
相应的维护责任由团队承担，包括协议更新、身份验证、部署、可观测性、评估和事故响应。REST 转 MCP 教程给出了最小且实用的自建起点。
按工具类型对比
| 需求 | 建议起点 | 重点审核内容 |
|---|---|---|
| 大量常见 SaaS 集成 | Composio | 会话中的工具包范围、已连接账户和数据路径 |
| 按用户身份授权的操作 | Arcade | 提供商 scope、用户同意和资源授权 |
| 小型现有 REST API | RapidMCP | 单端点映射和结果整理 |
| 产品特有的业务工作流 | 自定义 MCP | 协议维护和运维 |
| 混合型产品 | 组合方案 | 重复身份验证、工具重叠和日志分散 |
这是一张适用场景图，并不表示某个厂商不能支持其他行。
能揭示真正区别的问题
由谁管理用户连接？
确认 OAuth client credential、refresh token、scope、撤销流程和账户选择分别由哪一层管理，再检查工具获得的是绑定到用户的凭据，还是共享服务凭据。
模型能看到什么？
导出确切的工具名称、描述和 schema。大型目录可以通过运行时发现，避免把每项工具都放入上下文。自动生成的封装则可能公开每个端点。应针对一项真实任务评估模型实际看到的列表。
工具数据会经过哪里？
记录哪些厂商服务会接收参数、结果、文件和凭据，再将这条路径与客户数据要求对照。即使工具 schema 完全相同，托管 connector 和自行运维的 MCP 服务器也有不同的信任边界。
工具能否保留业务语义？
产品特有工具可能需要关联多个 API、执行租户规则、核对操作结果，再返回精简结果。如果平台强制要求一个端点对应一个工具，应继续自建该工具，或在封装层后放置任务级 API。
任务级工具指南提供了相应的评估契约。
Cohesivity 位于哪一层
Cohesivity 通过面向 agent 的控制面和数据面提供后端资源，但它不是 Gmail 或 Slack 操作目录。Composio、Arcade、RapidMCP 或自定义工具都可以调用由 Cohesivity 托管或配置的后端。
选型时应保持各层独立。Connector 决定 agent 如何访问某项能力，Cohesivity 则可以提供该能力所需的数据库、存储、托管、邮件或其他后端。
先进行分类盘点
列出计划中的所有工具，将其归类为常见 SaaS 操作、按用户身份授权的操作、REST 封装或产品特有工作流，再在每一类中对比平台。除非厂商契约完全符合需求，否则核心授权和业务决策应继续保持自定义实现。
下方的提示词会依据仓库生成这份自建或购买选型说明，但不会集成任何平台。