MCP 配置放哪一层：local、project、user 三种作用域与团队共享

同一个 MCP 服务端写在不同作用域，效果完全不同：写在本地作用域只有你自己在这个项目里能用，写在项目作用域会随仓库提交给全团队，写在用户作用域则对你所有项目生效。配置放错层，轻则同事跑不起来，重则密钥进仓库。先理解三层语义，再决定往哪写。

三种作用域的差别

添加服务端时用 --scope（简写 -s）指定，省略时默认落在本地作用域。注意旧版本里”项目”和”本地”的命名与现在相反，看文档时要留意版本。

项目作用域：团队共享的主战场

项目级配置写在根目录的 .mcp.json 里，随 git 提交，团队成员拉下来就能用。典型写法：

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.github.com/mcp"
    }
  }
}

三个要点：

• 类型字段：HTTP 传输用 "type": "http"（streamable-http 是同义别名，从服务端文档复制过来能直接用）；stdio 传输不写 type，用 command + args。
• 首次使用审批：团队成员第一次用项目里的服务端时会看到审批提示，这是设计上的安全门，不要想办法绕过。
• 不受信任的工作区：仓库自带的已提交配置不会被自动加载，会显示为待审批状态，直到用户接受信任对话框。

本地与用户作用域怎么分工

• 本地作用域：适合放个人实验性的服务端、以及需要本地绝对路径的配置。它不会被提交，改错了不影响别人。
• 用户作用域：放所有项目都要用的通用能力，比如记忆、搜索、文件系统这类。一次配置，处处可用。
• 覆盖关系：本地配置可以覆盖项目级和用户级设置，不产生冲突。想临时改团队配置的参数而改动仓库文件时，就写在本地。

团队共享的落地方案

服务端清单要克制

每加一个服务端，模型就多一个要考虑的选项，工具定义也会占上下文。团队共享清单应当只保留”多数人多数时候用得上”的几个，个人专用的放本地作用域。

新人上手要可复制

把安装步骤写进 README：需要哪些环境变量、怎么获取、怎么验证连通。团队共享配置的失败几乎都发生在这一步——配置对了，环境变量没设。

来源要可追溯

优先使用官方注册表里的包，第三方服务端要先看源码。 stdio 类型的服务端是以你当前系统用户权限运行的，它能读到你账号能读的任何文件。这条必须写进团队规范。

相关配置

不同客户端的接入步骤有差异，Cursor 与 VS Code 的完整流程见MCP 客户端配置；如果共享的是远程服务端，授权部分必须一并处理，参考远程 MCP 服务器的 OAuth 2.1 授权；涉及本地文件读写的，权限边界见Filesystem MCP Server 实战。