MCP 生态实测：Smithery vs Composio vs 手搓，Agent 接工具的最优解

TL;DR

背景：MCP 协议解决了什么

MCP（Model Context Protocol）是 Anthropic 开放的协议标准，核心解决一个问题：AI 模型调外部工具太碎片。

在 MCP 之前，每个 Agent 框架有自己的 tool 格式——一个框架用 Python function，另一个用 JSON schema，再一个用各自的 function calling 约定。同一个"查 GitHub PR"的能力，换个框架就得重写一遍。MCP 统一了这层：一个 MCP Server 对外暴露工具，任何支持 MCP 的客户端（Claude、Cursor、Windsurf 等）都能直接调，不用为每个框架重写。

协议是好协议，但留下一个现实问题：谁来写 Server？ Smithery 和 Composio 就是来回答这个问题的——一个做"应用商店"，一个做"托管平台"。MCP 概念详解见 什么是 MCP。

实测环境

• Agent 客户端：Claude Code (CLI) + Cursor (IDE)
• 要接的工具：GitHub（读 PR + 评论）、Slack（发消息）、PostgreSQL（查数据）
• 时长：每种方案各用 3 天

方案一：手搓 MCP Server

用官方 SDK 从零写一个 GitHub MCP Server：

import { Server } from "@modelcontextprotocol/sdk/server";

const server = new Server({ name: "github-mcp", version: "1.0.0" });

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "get_pr",
      description: "Get a GitHub PR by number",
      inputSchema: {
        type: "object",
        properties: { repo: { type: "string" }, pr: { type: "number" } },
      },
    },
  ],
}));
// 还要自己实现 CallTool handler、OAuth、rate limit、重试……

体验：

• 完全可控，想加什么工具加什么
• GitHub OAuth 流程写了一整天
• Rate Limit / 重试 / 错误处理全得自己写
• 3 天才搞定 3 个工具，而且只有自己能维护

结论：除非有特殊定制需求（内部系统、私有协议），否则不推荐。时间成本太高，且重复造轮子——常见 SaaS 早有人写好了。

方案二：Smithery 一键安装

# 装 GitHub Server
npx @smithery/cli install @modelcontextprotocol/server-github --client claude

# 装 PostgreSQL Server
npx @smithery/cli install @modelcontextprotocol/server-postgres --client claude

重启客户端，GitHub 和 PostgreSQL 工具自动出现。

体验：

• 5 分钟搞定 2 个工具，体验极爽
• 社区已有数百个 Server，常见 SaaS 基本都有
• 同一个工具能搜到多个版本，质量参差——第一个试的版本有 bug，换一个才正常
• Auth 需要手动配（Smithery 不帮你管 token）
• 生产环境心里没底——Server 是社区上传的，没有 SLA

结论：个人开发 / 快速试水首选。生产用需要自己审代码 + 自托管。装之前看 star 数和最近 commit 时间，能避开大半的坑货。

方案三：Composio 托管

注册 Composio → 连 GitHub / Slack 账号（OAuth 流程 Composio 帮你跑）→ 配置 MCP Server：

{
  "mcpServers": {
    "composio": {
      "command": "npx",
      "args": ["@composio/mcp", "--api-key", "***"]
    }
  }
}

客户端自动获得数百个工具能力。

体验：

• Auth 全托管——不用自己管 token 续期
• 有调用日志和 trace，生产级可观测
• Rate Limit 帮你管，不会打爆上游 API
• 数百个工具全暴露给模型时，Claude 偶尔会调错工具（用工具过滤可缓解）
• 国内 SaaS 覆盖少（飞书 / 钉钉 / 微信等较缺）
• 托管版按月付费，对个人开发者偏贵

结论：团队 / 生产级 Agent 首选。个人开发者用免费额度也能跑，但 Auth 要自己管。

选型决策树

有特殊定制需求（内部系统 / 私有协议）？
├─ 是 → 手搓 MCP Server（接受高时间成本）
└─ 否 → 要不要 Auth 托管 + 日志 + SLA（生产级）？
        ├─ 要 → Composio（团队 / 生产 Agent）
        └─ 不要（个人 / 试水）→ Smithery（免费、一键装、最快）

踩坑记录

1. Smithery 的 Server 不是官方审核的——装之前看 star 数和最近 commit，避开无人维护的版本。
2. Composio 默认暴露全部工具——工具太多会干扰模型选择，用工具过滤参数只暴露需要的那几个。
3. 客户端 MCP 配置文件路径各不相同——Claude 桌面端、Claude Code CLI、Cursor 的配置位置都不一样，照各自文档来，别想当然。
4. Cursor 的 MCP 支持两种传输——Settings → MCP → Add Server，支持 stdio（本地进程）和 SSE（远程）两种，远程 Server 用 SSE。
5. 工具暴露过多拖慢响应——每个工具的 schema 都占 context，挂几十个工具会明显增加每次调用的开销，按需精简。

当前生态的真实状态

MCP 解决了"协议碎片"，但生态还在早期，几个现实问题要心里有数：

• Server 质量参差是当前最大痛点——同一功能多个实现，好坏混杂。
• Auth 仍是麻烦——除非用 Composio 这类托管，否则每个 Server 的鉴权要自己折腾。
• 国内 SaaS 覆盖少——飞书、钉钉、微信生态的现成 Server 不多，往往还得自己写。

所以现阶段的务实路线：能用现成的就别手搓，个人用 Smithery 起步，团队上生产切 Composio，实在没有现成的再手搓那一两个特殊 Server。

2026-09-27 更新：协议已经不是 3 个月前那个协议了

本文初稿写于 2026-06，三个月里 MCP 本体变了两件会影响选型的事，改之前请先看完这一节。

① 版本号改成日期制，当前正式版是 2026-07-28

MCP 规范已不再用 1.0 / 2.0 这类序号，改用日期版本号；当前正式版为 2026-07-28（依据官方规范页，schema 锚定 schema/2026-07-28/schema.ts）。本文与本站 MCP 百科 早期提到的「MCP 1.0」是 2026 年中的旧口径。

这一版的三条硬事实：

• 基础协议：JSON-RPC 2.0；无状态、自包含的请求；按请求做能力协商。
• 服务端三能力 + 客户端一能力：Resources / Prompts / Tools，加上客户端侧的 Elicitation（Server 反向向用户要补充信息）。
• 传输层换了：远程传输是 Streamable HTTP，旧 HTTP+SSE 已弃用。本文「方案二 / 方案三」里按 SSE 配的远程 Server，现在应迁到 Streamable HTTP。

② 官方扩展开始决定「什么样的 MCP 能用」

规范之外现在有三个 opt-in 扩展，必须客户端与服务端同时支持并在初始化时协商：

这直接改写了选型的提问方式：过去只问「支不支持 MCP」，现在必须问「支持哪个规范日期版本 + 哪些扩展」。只支持核心协议、不支持 Tasks 的客户端，跑不了长任务 MCP Server——这在 6 月还不是一个问题。

③ 安全口径被写进了规范正文

规范新增的「Security and Trust & Safety」一节里有两句话值得所有装社区 Server 的人记住：

• 工具行为的描述（如 annotations）应视为不可信内容，除非来自可信 Server；
• 调用任何工具前，Host 必须取得用户明确同意。

也就是说「提示注入 → 恶意工具描述 → 模型自愿执行」这条链，规范层面只给了「必须让用户确认」这一道闸，没有给技术兜底。本文「踩坑记录」第 1 条（装之前看 star 与最近 commit）因此从「建议」升级为必要动作。

三个月后的务实路线（修订版）

FAQ

现在还能按本文的 SSE 配置接远程 Server 吗？

能跑，但该传输已被官方标记为弃用，新实现不应再选它。迁移目标是 Streamable HTTP；具体改动取决于你用的 SDK，请以所用 SDK 的迁移说明为准。

「MCP 1.0」和「2026-07-28」是什么关系？

后者是当前规范版本。MCP 已改用日期版本号，本站 2026 年中的文章（含本文初稿与 MCP 1.0 发布资讯）用的是当时的序号口径。引用时请以官方规范页的日期版本为准。

Smithery / Composio 支持 Tasks、Skills over MCP 这些扩展吗？

本站未做一手核实，属待确认项。 扩展是 opt-in 且需双方协商支持，选型时请向平台方确认具体支持到哪个规范日期版本与哪些扩展，不要假设「支持 MCP」等于「支持全部扩展」。

规范会频繁变吗？

官方另有一份公开的 roadmap 方向（2026-08 发布），涉及 Agent 消息、webhook 与事件、HTTP 传输统一、Agent 身份、企业安全与 SDK 体验。那是路线方向，不是当前规范特性——别把 roadmap 当已实现的功能写进架构设计。

结论

MCP 解决的是协议碎片这件事，它已经解决了——三个月里最大的变化不是「又多了多少 Server」，而是协议本身从「薄薄一层工具适配」长成了带扩展、带安全原则、带传输层换代的正式规范。

对应的实践结论只有一句：别再把「支持 MCP」当成一个是/否问题。 现在该问的是「哪个规范日期版本 + 哪些扩展 + 传输是不是 Streamable HTTP」。在这三个问题上有答案的选型，才经得起下一个季度。

延伸阅读

• Smithery 工具卡 · Composio · MCP Toolbox
• 什么是 MCP — 协议原理与架构
• Claude Skills 实战 — Skill 配合 MCP 用
• Cursor MCP 数据库集成实战 — 手把手接 DB