MCPAgent对比SmitheryComposio

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

AIHO 编辑部 · 2026-06-21

TL;DR

维度	手搓 MCP Server	Smithery 安装	Composio 托管
上手成本	高（写 TS/Python）	低（npx 一行）	中（注册 + 配 Auth）
定制度	最高	低（用别人写好的）	中（数百预置 + 自定义）
Auth 管理	自己写	Server 自带	托管平台帮你管
生产可用	看你写得好不好	参差，需自己审	有 SLA + 日志
适合场景	特殊定制需求	快速试 / 个人用	团队 / 生产级

背景：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 托管

{
  "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（免费、一键装、最快）

踩坑记录

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

当前生态的真实状态

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

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

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