c.4操作⏱ 约 4 分钟

管理与共享 MCP 服务器

接的服务器多了,怎么管、怎么给团队用

🔎 最后验证 2026-05📚 来源:Claude Code 官方文档🧰 Claude Code、MCP、Git✅ 75 人学过👁 119 次阅读

为什么学这个

接了几个 MCP 服务器后,你会需要:看看现在接了哪些、临时关掉某个、把好用的配置分享给同事。这一节讲 MCP 的日常管理与团队共享——让"接进来"之后还能"管得住"。

💡 打个比方

管理 MCP 服务器,就像管理电脑上装的软件:你要能列出装了啥、卸载不用的、把常用配置同步给团队。接得进、也要管得好,工具台才不会越用越乱。

日常你会做的几件事(具体命令以官方文档为准):
- 查看:列出当前接了哪些 MCP 服务器、各自状态
- 启用/停用:临时关掉不用的(减少干扰和风险)
- 移除:不再用的就删掉,别囤着(呼应 c.3 的"精而不滥")
配置作用域:有的配置只对当前项目生效,有的对你所有项目生效——分清楚,别把项目专属的接成全局的
团队共享:项目级的 MCP 配置可以随仓库提交,团队 clone 就有一致的工具环境(又是 Git 的功劳,P1C)——但含密钥的部分别提交(P4 #5)

❓ 测验

把团队都要用的 MCP 配置分享给大家,合适的方式是?

⚠️ 避坑分清'项目级'和'全局级',别把权限范围搞混

把一个只该用于某项目的服务器(尤其能访问敏感数据的)误设成"对所有项目全局生效",会让它在你不该用它的地方也被调用,扩大风险面。配置作用域要和它的用途匹配:专用的就锁在项目里。

🤖 梳理你的 MCP 配置(去真实环境)

请基于官方文档当前版本帮我:1) 列出我当前接入的 MCP 服务器和它们的作用域;2) 判断有没有'权限大却很少用'或'作用域设得过宽'的;3) 给团队共享配置时,如何把可提交的配置结构和不可提交的密钥分开。

🔎 来源与核验· 1 条,点开核对

本节每个关键论断都对应一个可追溯的来源 —— 这是本课程"靠谱、不过时"的底线。

「MCP 服务器可按项目/全局作用域管理,并可随仓库共享配置(密钥除外)」

✅ 小结

你会管理和共享 MCP 了。接下来是最该认真对待的一节——安全:用别人做的 MCP 服务器,有哪些风险、怎么防。

下一节 → 传输方式与权限:第三方 MCP 的安全风险

都看到这了，打个赏呗！