Claude Code 接 MCP 的 6 个最常用服务器

接入 MCP 之前和之后

我 2025 年 9 月之前用 Claude Code 基本就是”读代码、写代码、跑 bash”三件套。碰到线上排错，还是得自己开 5 个终端窗口：一个 kubectl、一个 psql、一个 grep 日志、一个翻 GitHub issue、一个发 Slack 汇报。

MCP 生态起来之后我开始一个个接，到 2026 年 3 月稳定用 6 个。变化挺大的，上周一次 on-call 处理线上 webhook 丢数据：

我：”查一下最近 20 分钟 webhook_delivery 表里 status=failed 的记录，按 error 分组，翻下 GitHub 有没有相关 issue，截个 dashboard 图发我 Slack。”

Claude 一把做完，4 分 23 秒。之前这事我自己大概 15-18 分钟。

下面这 6 个是我认真筛过的，不是列一堆让你挑。

先说清楚 MCP 在 Claude Code 里是怎么工作的

MCP（Model Context Protocol）简单理解就是”标准化的工具接入协议”。Claude Code 通过配置文件连到一个 MCP server，server 向 Claude 暴露一堆 tool（每个 tool 有 JSON Schema 定义），Claude 就可以调用它们。

配置位置：.mcp.json（repo 级，入 git）或 ~/.claude/mcp.json（用户级）。格式：

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgres://..."],
      "env": {}
    }
  }
}

跟传统 function calling 的差别我在 MCP vs Function Calling 那篇写过。一句话区分：function calling 是你在 API 调用里 inline 传工具定义，MCP 是把工具托管到独立进程、标准化协议通信。MCP 更适合多个 agent/工具链复用。

MCP 1：PostgreSQL —— 日常排查最高频

用了快半年，我的 on-call 工具箱里这个排第一。

{
  "postgres-readonly": {
    "command": "npx",
    "args": [
      "-y",
      "@modelcontextprotocol/server-postgres",
      "postgres://readonly:xxx@db.internal:5432/app"
    ]
  }
}

几个关键点：

用只读账号。这个 MCP 没有原生的 readonly flag（2026 年 3 月最新版本还没有），靠 DB 账号权限约束。我们 DBA 专门给我建了一个 readonly 账号，SELECT 权限 + 排除敏感表。
连接串别进 git。我是写在 settings.local.json 里通过环境变量引用，args 里用 ${PGURL} 占位。

它暴露的工具有 query、list_tables、describe_table 等。Claude 用法：

我：”last hour 的 orders 表按 status 分组”
Claude: 调用 query 工具，写 SQL，返回结果

大坑：连到生产库。我坚决不连生产，只连 staging 或生产 replica。宁可查慢 3 秒，不给 Claude 直连生产的机会。配合权限模式里的 deny 规则，双保险。

MCP 2：GitHub —— issue 和 PR 整合

@modelcontextprotocol/server-github 官方维护，质量稳定。

{
  "github": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-github"],
    "env": {
      "GITHUB_PERSONAL_ACCESS_TOKEN": "${GH_TOKEN}"
    }
  }
}

我常用的几个 tool：

search_issues：搜相关 issue（排错时必查，经常发现同问题已有人提）
get_pull_request：读 PR 全文（review 时用）
create_issue：发现 bug 直接让 Claude 起草一条 issue 发出去
list_commits：看某个文件最近的改动历史

注意 PAT 要用细粒度的 fine-grained token，只给必要仓库的必要权限。我的 PAT 只有 Issues: read/write、Pull requests: read、Contents: read，没有 Contents: write——不让 Claude 通过 MCP 直接 push 代码，push 走本地 git。

MCP 3：Playwright —— 浏览器自动化

排查前端问题、跑 e2e 验证必备。

{
  "playwright": {
    "command": "npx",
    "args": ["-y", "@playwright/mcp@latest"]
  }
}

Playwright MCP 暴露的 tool 包括 navigate、click、fill、screenshot、get_page_text 等。

我的高频用法：

“访问 staging.app.com/dashboard，登录（凭证 env 里），截图 orders 页面，告诉我有没有看到红色 error”

Claude 自己一步步做。2026 年 2 月有次 staging 环境报错我自己看不出原因，Claude 通过 Playwright 发现是一个前端 React error boundary 显示了 stacktrace，里面提到 window.gtag is undefined。问题直接定位。

坑：headless 模式下有些 CSS hover 状态抓不到。如果是交互类问题，需要改成 headless: false 模式人工盯着看。

另一个坑：tool 定义偏多。Playwright MCP 的 tool 列表我数了数 18 个，占了将近 4.2K context。如果你只需要 screenshot 不需要交互，可以 fork 一个精简版（或者未来可能有 lazy 加载 tool 的机制）。

MCP 4：Slack —— 通知和跨团队沟通

@modelcontextprotocol/server-slack 社区版维护得还行。

{
  "slack": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-slack"],
    "env": {
      "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}",
      "SLACK_TEAM_ID": "${SLACK_TEAM_ID}"
    }
  }
}

Scope 我只给 chat:write、channels:read、users:read，够用就行。

典型场景：

on-call 时让 Claude 汇总排查结论发到 #incidents
Review 完大 PR 让 Claude 发一段总结到 #eng-review
查完 bug 根因让 Claude @ 相关同事

坑：别给 channels:history 权限。给了之后 Claude 会很爱”先读 10 条历史消息再回复”，既耗 token 又有合规风险（别人说的话可能不想被 AI 读）。

MCP 5：Notion —— 团队知识库

@notionhq/notion-mcp-server，2025 年底官方出的，质量比社区版好。

{
  "notion": {
    "command": "npx",
    "args": ["-y", "@notionhq/notion-mcp-server"],
    "env": {
      "NOTION_API_KEY": "${NOTION_KEY}"
    }
  }
}

我的用法是把团队的 runbook、架构决策记录（ADR）、onboarding 文档都放 Notion，Claude 在 MCP 里搜。

“查一下我们怎么处理 webhook 重试的 ADR”
Claude 搜 Notion，找到 ADR-0042，摘要+链接贴回来

这比直接把文档塞进 CLAUDE.md 好——CLAUDE.md 放原则性的、每次都要参考的东西，Notion 放”可能用到”的长尾知识。Claude 按需去查，不占常驻 context。

想理解这个模式背后的 context 设计可以看长期记忆与 Agent 状态——本质上就是把部分长期记忆外挂到 Notion，用 MCP 做检索。

MCP 6：自建内部 API —— 我们团队自己写的

前 5 个都是现成，第 6 个是自己写的。场景是我们有一个内部 admin 平台，暴露用户管理、订单查询、feature flag 切换这类功能。原本 Claude 要 curl 这个平台，一堆 auth header 很麻烦。

我们花了 3 天写了个内部 MCP server，用 @modelcontextprotocol/sdk 的 TypeScript SDK。核心代码就 ~320 行。暴露的 tool 包括：

find_user_by_email
get_user_orders(user_id, limit)
toggle_feature_flag(flag_name, enabled)
query_admin_metrics(metric_name, time_range)

每个 tool 的权限在 server 侧严格校验，MCP 只是一个语义友好的 wrapper。

实现上类似我在 MCP Server 内部工具那篇里讲的模式。关键设计：

工具描述要写得像菜单而不是 API 文档。Claude 看的是自然语言，不是 OpenAPI spec。
返回结果要包含下一步建议。比如 find_user_by_email 找不到人时，返回 "no user found. try: list_recent_signups(email_domain='xxx')"。这种主动引导能明显降低 Claude 的瞎猜概率。

最大的坑：tool 定义吃 context

这是我想重点说的。2026 年 2 月有段时间我觉得 Claude Code 越来越慢、越来越贵，排查了半天发现——我一共挂了 9 个 MCP server，每次请求光 tool 定义就占 21.4K token。

具体算一下：

PostgreSQL: 1.8K
GitHub: 3.2K
Playwright: 4.2K
Slack: 2.1K
Notion: 3.6K
内部 API: 2.8K
另外 3 个实验性 MCP: 3.7K 合计

总计 21.4K。这意味着每次请求的 input 都自带这么多 overhead，cache 打不住的时候就是真烧钱。想了解 cache 机制看 Prompt Caching 深度指南。

我的解决方案有两步：

第一步：砍掉不常用的 MCP。留下真正每周用的。我砍掉了 3 个（某个 weather MCP、某个 stock MCP、一个失败的 email MCP 实验），省了 3.7K。

第二步：用 MCP 的 tool filter。Claude Code 支持按 MCP 和 tool 名字白名单：

1 2	"enabledMcpjsonServers": ["postgres", "github", "playwright"], "disabledMcpjsonServers": [],

更细的粒度可以通过 permissions 的 allow/deny 间接做——deny 某个 tool 的话定义也会从 tool 列表剔除。

调完后稳定在 9-11K tool overhead，可以接受。

配完之后怎么验证能用

每个 MCP 装好第一件事：在 Claude Code 里输入 /mcp，看连接状态。connected 状态才算成功。

如果显示 error，按顺序排查：

命令能否独立跑（终端里先 npx -y @xxx/server-xxx 看有没有报错）
env 变量是否注入（echo $GH_TOKEN 确认）
网络（有些 MCP 会连外网，公司防火墙可能挡）
协议版本（MCP SDK 更新频繁，老版本 server 可能不兼容新 client）

然后在对话里让 Claude 试一下：

“用 GitHub MCP 搜一下这个仓库最近 issue”

Claude 会显式提到调用了哪个 tool，你在 transcript 里能看到。看到就是通了。

最后：MCP 不是越多越好

一年下来我的感觉是——MCP 的价值在于接住那些”人手动做很费时间、但规则清晰”的事。凡是规则模糊、需要人判断的，就别用 MCP，让 Claude 和你互动。

贪多挂一堆 MCP 只会拖慢 agent、烧更多 token、让你自己也记不清有啥工具可用。我团队里给新人的建议是：先裸用 Claude Code 一个月，感受到具体的重复痛点再有针对性地装 MCP。不要一上来挂 15 个”据说有用”的 MCP。

整个 MCP 生态的深入理解建议配合看 MCP Server 内部工具和 MCP vs Function Calling——前者讲怎么自己写 MCP server，后者讲为什么要用 MCP 而不是原生 function calling。

我的 .mcp.json 完整配置 + 内部 MCP server 代码骨架
上面提到的 6 个 MCP 的完整配置（含环境变量管理、按环境切换 staging/prod、tool filter 策略），加上我们自建内部 MCP 的 TypeScript 代码骨架（320 行左右，去掉了公司特定逻辑），整理成一个 starter。如果你正要接入 MCP 或者想把内部平台包成 MCP，评论区留言你们的技术栈（Node/Python/Go），我发对应那份给你。记得自建 MCP 的 tool 描述要过 review——那部分是最容易翻车的地方。