1. 先从“MCP 是什么，以及它到底解决了什么问题”说起

最近我几乎每天都在用 Claude Code 做开发辅助，接触最多的一个概念就是 MCP。很多人看到 Claude Code 能改代码、能执行命令，已经觉得很神奇了，但真正让它从一个“对话式代码助手”变成一个“能替你把活干完的自动化工具”，靠的就是 MCP。全称是 Model Context Protocol，翻译得直白一点，就是一套让 AI 模型和外部工具之间互相通信的标准化协议。说得再通俗一点，没有 MCP 之前，Claude Code 只能看到你在终端里给它的文本，它能做的也只是生成代码、改文件、运行命令。有了 MCP 之后，它可以调用浏览器自动化工具、连数据库、读本地文件、操作 Git 仓库，甚至和 Burp Suite、Yakit、Blender 这类专业软件对接。

这里要先想明白一个小问题：为什么需要一种“协议”？你可能会想，直接用 Python 脚本调用 API 不就行了？确实能行，但问题是每个工具的接口千奇百怪，今天你要调这个 SDK，明天要写那个封装，维护成本高得吓人。MCP 做的事情很简单，它把“工具调用”这个行为标准化了，让 Claude Code 这边不需要关心每个工具的内部实现，只需要遵循一套统一的请求和响应格式，而工具这一侧只需要实现 MCP Server 的规范，就能被任何支持 MCP 的客户端使用。类比一下，MCP 就像 USB-C 接口，你不需要知道充电器内部电路怎么设计，只要协议统一，插上就能用。

MCP 的核心价值就两条：一是让 AI 能实际操作外部系统，而不只是“建议”你怎么操作；二是把工具接入的工程量从一次性的硬编码，变成一次配置、长期复用。尤其是当你在一个项目里同时需要文件读写、数据库查询、浏览器自动化、HTTP 请求调试时，你会发现没有 MCP 的 Claude Code 和一个沉睡的编辑器没有区别。这篇文章我不会扯太多理论，重点讲清楚三件事：MCP 到底能帮你解决什么实际场景问题、怎么在 Claude Code 里把它配置起来、以及配完之后遇到的各种报错怎么排查。内容按我自己实际操作过的路径来写，适合准备认真把 Claude Code 用起来的开发者，也适合已经配了一半但在报错泥潭里挣扎的人。

1.1 没有 MCP 之前，AI 工具链长什么样

先说个真实感受。我最早用 Claude Code 的时候，它的能力边界特别明显：代码生成、解释、小范围重构都可以，但你要它帮你查一下项目里某个接口的调用链、去数据库里翻一条记录，它就傻眼了。你只能手动把信息复制粘贴到对话里，这会让所有依赖外部信息的任务断档。更别扭的是，你想让它跑一个自动化操作，比如用浏览器打开页面截图、抓某个接口返回的数据，它根本没有通道去执行。

所以大家开始自己写脚本，把工具逻辑封装在本地，然后在对话里让 Claude Code 用命令行去调用这些脚本。这确实能用，但稳定性和通用性都差：脚本依赖特定的运行环境、参数解析容易出错，跨项目复用时几乎是噩梦。你换一台电脑，或者换一个 AI 客户端，这套脚本就全废了。MCP 的出现在很大程度上解决了这个痛点，它把工具调用变成一种标准能力，前面提到的那些“奇技淫巧”统统可以收敛为统一的 MCP Server。

做个小结，MCP 最直接的收益有三个：第一，消除了重复工作，接入一个新工具时不需要从零写集成代码；第二，打通了信息孤岛，AI 可以实时读取真实环境中的数据，而不是靠用户复制粘贴；第三，生态共享，同一个 MCP Server 可以给 Claude Code、桌面版客户端或者其他支持 MCP 的产品用。这就是为什么现在大家越来越看重“某某工具支持 MCP 吗”，因为这决定了它能不能进入 AI 自动化的链条。

1.2 MCP 的核心作用：给 Claude Code 装一双“手”

单独看“配置 MCP”这个动作，好像就是在配置文件里加几行文字、运行一条命令，但背后的意义远比配置本身重要。当你在 Claude Code 里接入一个 MCP Server，本质上是在告诉你正在对话的这个 AI：你有权限执行某类真实操作了。比如接入了文件系统 MCP，它就能遍历目录、读取指定文件、创建新文件；接入了数据库 MCP，它就能执行查询、查看表结构；接入了 Playwright MCP，它就能打开浏览器、点击页面、截图保存。

我常用的一句话是：对话能力是 AI 的“大脑”，MCP 就是它的“手”。大脑想得再好，如果没有手去执行，就只能停留在建议层面。配置 MCP 之后，Claude Code 可以在一次会话中完成“分析需求 -> 读取相关文件 -> 修改代码 -> 运行测试 -> 根据结果调整”这套完整闭环。尤其是涉及工程化项目的场景，比如我在调试一个网页应用时，会同时挂载文件系统、Git 和 Playwright 三个 MCP Server，让 Claude Code 自己读代码、看历史提交、打开页面验证效果。

你还会听到“MCP Server”和“MCP Client”这两个词，它们的关系不复杂：Claude Code 是客户端，负责接收用户指令、通过 MCP 协议向工具发送请求；各种工具是服务端，负责执行具体操作，返回结构化结果。配置 MCP 时我们做的所有动作，本质都是在“告诉 Claude Code 去哪找到这些服务端、该怎么连”。

1.3 本地服务器与远程服务器，两种形态怎么选

MCP Server 的部署形态大致分成两类：本地 stdio 类型和远程 HTTP/WebSocket 类型。本地类型的典型做法是让 Claude Code 通过命令行启动一个进程，比如npx -y @some/mcp-server，双方通过标准输入输出通信。这种形态的优点是没有网络延迟、不需要鉴权服务器，适合接入本地文件、命令行工具、开发环境等场景。我日常配置最多的就是这种，尤其是文件系统、Git 操作、数据库这类敏感操作，留在本地最安心。

远程类型的 MCP Server 则通过 URL 暴露服务，常见协议是 HTTP 或 WebSocket，例如wss://api.example.com/mcp?token=xxx这样的地址。这种形态适合连接云端服务、共享工具服务，或者让团队里多台机器同时使用同一个 MCP Server。好处是部署集中的、更新容易，但缺点也很明显：必须注意网络连通性、鉴权方式和 token 的安全性。远程服务经常出现的连接超时、握手失败、token 过期等报错，都是配置时需要额外留心的点。

在动手配置之前，先想清楚你用这个 MCP 是做什么的：仅本地开发就用 stdio，安全可控；需要调用远程 API 或团队共享能力就用 http/ws，但一定要把鉴权信息管理好。我自己踩过不少坑，后面会细说。

2. 配置 MCP 之前，先把基础环境准备好

很多报错的根源不在 MCP 配置本身，而是底层环境没弄干净。MCP 的本地服务器多数依赖 Node.js 生态，远程服务器又依赖网络和鉴权，所以在开始配置之前，先把基础环境过一次，可以省掉后面一大半的排查时间。

2.1 Node.js 安装与版本确认

本地 MCP Server 最常见的启动方式是npx，而npx是 Node.js 自带的命令。如果你的机器上压根没有 Node.js，或者版本太老，那后续所有claude mcp add ... -- npx ...的操作都会直接失败。我强烈建议安装 LTS 版本，不要追新，也不要用那种被系统包管理器锁住的旧版本。

以我目前的经验，Windows 上一般用官方安装包或通过版本管理工具安装，macOS 上可以直接用 Homebrew。装完之后打开终端跑一下：

node -v npm -v npx -v

这三个命令分别确认 Node.js、npm、npx 都在且可用。常见问题是安装了 Node.js 但 npm 命令找不到，这在 Windows 上多半是 PATH 没有生效，重开一个终端通常就好了。另外一个容易忽略的点是，某些环境变量设置工具会修改你 shell 的 PATH，导致你在新窗口里找不到npx，这时候可以先手动执行一次环境刷新，或者直接使用 Node.js 安装目录里的完整路径来启动 MCP。

2.2 安装 Claude Code 本体：npm 与桌面版两条路

Claude Code 本身可以通过 npm 全局安装，这也是最主流的做法：

npm install -g @anthropic-ai/claude-code claude --version

全局安装的好处是命令行随处可用，后续配置 MCP 时也方便。如果你更习惯桌面图形界面，也有桌面版安装包，装完就可以通过图形配置入口来操作。但我的个人建议是，命令行方式始终是排查问题最可控的手段，因为你可以清楚地看到配置写入到了哪个文件、使用了什么参数，而图形界面虽然方便，但出了问题往往更难看透。

如果npm install -g在安装过程中出现权限问题，或者下载速度很慢，可以检查一下 npm 源配置。这个操作只影响 npm 包的下载，并不涉及任何系统级修改，改完之后重新执行安装命令即可。装好之后最好进入claude命令，实际跑一条简单的对话，确认能正常启动后再进行 MCP 配置。

2.3 认识三种配置作用域，避免配置“进错门”

Claude Code 的 MCP 配置并不是只写在一个地方，它支持作用域概念，具体来说有 local、project、user 三种。local 只对当前项目且仅对当前用户生效，通常写在项目的本地配置里，不提交到版本控制；project 对当前项目生效，所有项目成员（只要拉取到配置文件）都会生效，适合团队共享配置；user 则是对当前用户的所有项目生效，相当于全局配置。

为什么要区分得这么清楚？因为很多人配置完之后发现“明明加上了 MCP，换个项目就没了”，大概率就是把 project 和 user 搞混了。我在一个多项目工作流里会用 player 过滤配置的思路来区分：文件系统、Git 这类基础能力放 user 级，数据库连接、浏览器自动化这类场景相关的能力放 project 级，敏感或临时调试的工具放 local 级。这个习惯能让你在不同项目之间切换时不被一堆无关 MCP 拖慢启动速度。

用命令查看当前已有的 MCP 配置时，注意命令会为标准规范输出作用域标签，看到project和user的字样就能快速判断配置在哪一层。没有正确作用域观念，是大多数“配置不生效”类问题的元凶。

3. 给 Claude Code 配置 MCP 的完整教程

现在进入正题。我的推荐路径是：先用命令行添加，让 Claude Code 自动帮你处理配置文件；再手动检查或编辑配置文件，以便理解每一步的含义；最后通过对话里的工具调用验证整个链路通不通。这一套走下来，你对 MCP 怎么工作的理解会非常立体。

3.1 通过命令行添加 MCP 服务器

命令行方式最直接，Claude Code 提供了一套claude mcp add命令。基本的增删改查是这样的：

# 查看当前 MCP 配置 claude mcp list # 添加一个本地 MCP Server，用 npx 启动进程 claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/data # 添加一个带环境变量的 MCP Server claude mcp add my-api --env API_KEY=xxx -- npx -y my-mcp-server # 删除配置 claude mcp remove filesystem

这条命令里有个细节：--之前是给 Claude Code 的参数，--之后是实际启动 MCP Server 的完整命令。很多人执行的时候漏掉了--，或者命令里带了额外的引号，导致启动进程时参数被错误切分。我第一次配的时候就因为路径里带空格又没有加引号，报了一大堆奇怪的解析错误。

手动添加一个远程 MCP Server 也很方便，例如：

claude mcp add remote-api --transport http wss://api.example.com/mcp?token=YOUR_TOKEN

这里--transport http告诉 Claude Code 这个 MCP 是通过网络访问的，后面的 URL 就是服务地址。如果你使用的是需要自定义请求头的接口，Claude Code 也支持通过参数或者配置文件去设置鉴权头，但最简单的做法是把 token 放在 URL 参数里。要注意，这样 token 会被记录进配置文件，所以千万别把包含 token 的配置文件提交到公开代码仓库。

3.2 通过配置文件添加 MCP 服务器

命令行虽然快，但如果你想看清楚 Claude Code 到底把配置写到了哪里，首选方案是直接编辑配置文件。不同平台、不同作用域对应的文件路径不太一样，但通常可以在用户主目录下找到 Claude Code 的配置目录，里面会有一个 json 配置文件。project 作用域则一般写在项目根目录下，可能是一个.mcp.json文件，这个文件提交到 Git 后就能让团队其他人共享同一套 MCP 配置。

一个典型的配置文件长这样：

{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/path/to/data" ] }, "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] }, "remote-api": { "type": "http", "url": "wss://api.example.com/mcp?token=YOUR_TOKEN" } } }

手写这个文件的时候最需要注意的是 JSON 格式，多一个逗号、少一个引号都会导致 Claude Code 启动时解析失败。我自己推荐一个习惯：先通过claude mcp add添加，再用命令看它自动生成的配置内容，最后再手动微调，这比从零手写 JSON 要稳妥得多。

3.3 配置本地 MCP：文件系统实操示例

纸上得来终觉浅，我直接用一个最常见的文件系统 MCP 来走一遍完整流程。假设你想让 Claude Code 可以读取和操作/Users/me/projects/demo目录下的文件，配置命令是：

claude mcp add fs-demo -- npx -y @modelcontextprotocol/server-filesystem /Users/me/projects/demo

执行完之后运行claude mcp list，应该能看到fs-demo出现在列表里。接下来进入 Claude Code 会话，直接说“帮我看看 demo 项目里有哪些文件”，它找到对应工具去调用。整个过程你可以加--debug参数启动 Claude Code，观察它实际调用了哪些工具、传了哪些参数。我第一次看到 Claude Code 列出项目目录的时候，才真正理解什么叫“AI 长了手”。

这里有一个关键点：文件系统 MCP 只赋予 Claude Code 访问你指定路径的能力，而不是整台电脑。所以路径参数的设置要精准，别为了省事直接给根目录。否则 AI 能读到你的系统文件和隐私数据，虽然它不会主动乱来，但一旦配置泄露或被恶意指令诱导，风险会成倍放大。

3.4 配置远程 MCP：wss 地址连接

远程 MCP 的配置比本地稍微复杂一点，但核心就两步：拿到服务地址，配置鉴权。不少团队会把 MCP Server 部署在内网或云服务器上，对外提供wss://或https://地址。例如：

claude mcp add remote-tools --transport http wss://api.example.com/mcp?token=YOUR_TOKEN

为什么这里要用wss://而不是ws://？因为 MCP 的请求里会携带工具调用的上下文数据，如果服务端是生产环境，明文传输就等于裸奔。wss://是走 TLS 加密的 WebSocket，安全性更高，日常使用中也更不容易被网关拦下来。配置完远程 MCP 之后，可以用claude mcp list确认连接信息，但要注意，这个命令只是列出了配置，并不代表服务器一定连通。真正的连通性测试要通过一次实际的工具调用或者查看 Claude Code 的调试日志来完成。

如果你连的是同事自建的远程 MCP，最常遇到的坑就是 token 过期、服务地址写错、服务端 CORS 或鉴权策略不匹配。后面排查章节我会展开讲，这里只记住一个原则：远程 MCP 的配置信息一定要集中管理，别散落在各个项目里，更别写死在代码里。

4. 围绕 MCP 配置的典型场景与工具选择

配置方法只是基础，关键还是要知道配什么。我根据自己的实际使用，把日常最常见的几类 MCP 场景整理了一下，并附上对应的配置示例。你可以把这些当作一份“配置菜单”，按需取用。

4.1 浏览器自动化：Playwright MCP 示例

网页前端调试、E2E 测试、页面截图、接口抓取，这些事现在都能交给 Claude Code 干。Playwright MCP 是目前比较成熟的浏览器自动化方案，配置命令很简单：

claude mcp add playwright -- npx -y @playwright/mcp@latest

配完之后，你可以在对话里说“打开 example.com，点击登录按钮，截图保存到 /tmp/login.png”，Claude Code 会调用 Playwright MCP 逐步执行。这里有个前置条件：机器上要装好 Playwright 对应的浏览器内核，不然工具能启动但打开页面会报错。常见做法是单独跑一次npx playwright install chromium先准备好浏览器环境。

我在实际项目里最常用到的组合是：Playwright MCP 负责页面操作，文件系统 MCP 负责保存结果，Git MCP 负责提交变更。三个工具一起挂载时，AI 完全可以做到“打开页面发现问题 -> 修改代码 -> 跑测试 -> 提交”，整个闭环不再需要人肉搬运信息。这个场景很能体现 MCP 的价值，但也提醒你：不要一次性挂太多 MCP，否则上下文会被大量工具描述占满，反而影响对话质量。

4.2 数据库、Git 与安全测试工具场景

除了浏览器，数据库类 MCP 能让你用自然语言直接查库。比如你告诉 Claude Code“查一下 users 表里最近 7 天注册的用户数”，它会把 SQL 转换成实际查询并返回结果。配置时通常需要传入数据库连接串，类似DATABASE_URL=...环境变量，这一步务必使用最小权限的数据库账号，千万别用 root。因为 AI 的工具调用虽然看起来“智能”，但它不会像人一样判断哪些 SQL 是危险的。

Git 类 MCP 也很实用，常用的配置方式是让 Claude Code 可以查看分支、读取提交记录、执行提交操作。我的配置习惯是将它限定在当前项目内（project 作用域），避免 AI 误操作其他仓库。对于安全测试方向的读者，还有一些像 Burp Suite MCP、Yakit MCP 这类工具，核心思路都是一样：把安全测试工具的能力封装成 MCP Server，然后你在对话里指挥 Claude Code 完成请求拦截、流量分析、漏洞探测等操作。这类 MCP 的配置往往不只是加一个命令，还要先启动对应的软件并暴露出一个本地端口，配置时要留意端口是否被占用、防火墙是否放行。

4.3 一次配置多台 MCP 时的参数对比表

当你的 MCP Server 数量多起来之后，配置就成了一个需要管理的清单。下面是我常用的参数对比表，帮你快速看清每类常见 MCP 的配置要点：

这张表不是为了让你照着抄，而是提醒你：每个 MCP 都有自己的配置细节，不要指望一个通用模块能适配所有工具。接入前最好快速看一眼这个 MCP 的 README，把环境变量、参数、依赖确认清楚，配置到一半再回头查文档，浪费时间不说，还容易把配置改乱。

5. 常见报错排查与绕过方案

配置 MCP 几乎一定会遇到报错，尤其是第一次上手的时候。这里我把自己和身边同事踩过的高频问题集中列出来，并附上完整的排查思路。为了直观，我用速查表先给你一个全局观，然后挑几个典型场景细说。

5.1 命令、路径与启动类报错

这类报错的特征是：MCP 显示在列表里，但实际调用时失败，或者在 Claude Code 启动时就直接抛错。典型的错误信息包括command not found: npx、spawn npx ENOENT、module not found。

出现这些问题的根源，九成是环境变量和路径没有对齐。Claude Code 可能是在 GUI 环境下启动的，而你的npx安装在某个 shell 配置的 PATH 里，GUI 环境并没有加载这些配置。解决办法是使用npx的完整绝对路径，比如在 Windows 上是C:\Program Files\nodejs\npx.cmd，在 macOS 上可能是/usr/local/bin/npx。如果是通过 npm 全局安装的工具，也可以直接用工具的实际安装路径来配置。

另外还有一种情况：MCP Server 包名写错了，或者版本不存在。npm 对包名大小写并不敏感，但拼写错误会导致npx拉取不到包。稳妥的做法是先本地手动执行一次启动命令，确认能够正常跑起来之后，再把这个命令原样放进 MCP 配置里。能手动启动，配置环境才有意义；若手动都启动不了，先解决手动启动的问题。

5.2 远程连接与握手失败类报错

远程 MCP 的报错主要集中在connect ECONNREFUSED、Connection timeout、WebSocket connection failed这几类。看到这些信息，第一步是确认你填写的 URL 是否可以从当前网络访问。最简单的测试是直接用 curl 或浏览器访问一下地址，看看服务端有没有响应。如果是wss://的地址，部分命令行工具没法直接访问，可以换用支持 WebSocket 的调试工具，或者查看服务端日志来判断请求是否到达。

第二个常见原因是网络策略导致端口或协议被阻断。刚才说了，一般不推荐用ws://明文连接生产环境，但你内网调试时如果服务端只暴露了ws://端口，配置时就要对应调整。注意，问题可能出在握手阶段的 HTTP 状态码上：如果服务端返回 401 或 403，通常是 token 无效或权限不足；如果返回 404，大概率是路径写错了；如果反复超时，则要先检查服务端是否监听了正确的地址和端口，再检查客户端到服务端之间有没有网络隔离。

这里有个很典型的假阳性现象：claude mcp list显示远程 MCP 是正常的，因为list只读取本地配置，根本不发起网络请求。真正的连通性验证一定要靠实际调用工具，或者启动 Claude Code 时打开调试输出，看握手阶段的日志。我见过太多人配完远程 MCP 后以为成功了，实际一调用就超时，原因就是没有区分“配置存在”和“连接可用”这两个完全不同的状态。

5.3 工具加载不出来的问题

有时候 MCP 配置看起来完全正常，启动也不报错，但在对话里让 Claude Code 调用某个工具时，它却说“没有可用工具”或者“未找到”。遇到这个情况，先打开 Claude Code 的调试日志，确认 MCP Server 是否已经成功初始化、工具列表是否成功拉取。一个特别容易忽略的问题是：有些 MCP Server 启动后需要几秒钟才能完成初始化，而你立刻去调用工具，就会看到“无可用工具”的提示。遇到这种，等一两秒再重试往往就好了。

还有一种情况是 MCP Server 启动进程时挂掉了，但 Claude Code 并没有立刻感知到。代码里可以执行一个快速的自检，比如在终端里手动跑一遍配置的命令，观察是否有异常输出、进程是否一闪而过。有些 MCP Server 依赖外部服务，比如数据库 MCP 需要连接本地 MySQL，如果后端数据库没有启动，MCP Server 即使启动成功，也无法提供任何可用的工具。

再就是作用域过滤的问题。如果你在项目 A 里配置了 MCP，在项目 B 里使用时发现工具不可用，这不一定是配置失效，更可能是作用域不匹配。用claude mcp list查看时注意区分project和user的作用域标记，确认当前项目加载了哪一层配置。

5.4 常见报错速查表

这张表只是排查的起点。真实环境里的报错往往是多层原因叠加的，所以我每次排查都遵循同一个顺序：先确认底层环境（Node.js、npm、外部服务），再确认配置本身（路径、参数、作用域），最后确认网络或鉴权（远程场景）。按这个顺序走，绝大多数问题都能快速定位。

6. 最后再聊点配置心态与安全底线

6.1 配置验证的快捷方法，以及我常用的调试套路

很多人配置完 MCP 后，最大的疑问是“到底有没有配成功”。我不建议只盯着配置列表看，因为那只是静态状态。我会用一段对话来验证：让 Claude Code 做一件依赖这个 MCP 才能完成的小任务。比如刚配好文件系统 MCP，就直接让它“列出我指定目录下的文件”；刚配好数据库 MCP，就让它“查询某个表的总行数”。如果能得到符合预期的结构化结果，说明整个链路是通的。

调试时我也习惯分层观察：第一层是配置文件本身，看内容是否是期望的 JSON；第二层是 Claude Code 启动日志，看 MCP Server 的初始化状态；第三层是实际调用反馈，看工具返回的数据结构。如果你配的是本地 stdio 类型的 MCP，可以在终端手动运行启动命令，加个--help看看工具自己输出的提示，这个动作能帮你快速判断工具是否真的完整安装了。

我强烈建议你在配置过程中多做“最小化验证”，不要一次性把所有 MCP 都配上再统一测试。一次加一个，验证一个，通过后再加下一个。这样报错时你就能精确锁定是哪一步引起的，而不是面对五个 MCP 一起报错不知从何下手。

6.2 我的几点实操体会与安全止损建议

最后说几个平时文档里不太会专门提、但实际使用中非常重要的体会。

第一，MCP 的 tool 描述会占用上下文窗口。每个 MCP Server 注册后都会向模型暴露一批工具的名称和描述，挂载过多时，上下文里有效空间会被挤占，导致 Claude Code 的对话质量下降。这也是我为什么强调作用域和“按需挂载”的原因。如果一个项目的 MCP 列表超过五个，我会重新审视哪些真的需要长期挂载，哪些只是临时调试用完就删。

第二，不要把敏感凭据直接放进 MCP 配置。数据库连接串、API token、远程地址里的密钥，这些信息会随配置文件一起存在磁盘上，如果项目是托管在代码仓库里的，非常容易泄露。我的底线是：凡是包含凭据的 MCP 配置一律放 local 作用域，明确不提交到 Git，同时用环境变量注入而不是在 JSON 里明文保存。如果你接的是远程 MCP，token 要设置有效期并定期轮换，一旦怀疑泄露，马上吊销重建。

第三，不要盲目信任 MCP Server 的“便捷能力”。MCP 给了 AI 实际操作的权限，本质上放大了它的影响半径。接入一个不熟悉的第三方 MCP 之前，先搞清楚它能访问哪些资源、会向外部发送什么数据。安装来源不明的包、连接可信度低的远程服务，都可能导致凭据被盗或数据外泄。这个风险不是危言耸听，而是所有接入了大量工具型 AI 的开发者都需要具备的基本安全意识。

我自己的一个习惯是：把 MCP 配置分两套维护。一套是“日常开发常用”集合，放在 user 作用域，包含文件系统、Git 这些稳定的基础能力；另一套是“项目专用”集合，放在 project 或 local 作用域，里面才是数据库连接、浏览器自动化、调试工具这类场景相关的 MCP。这样既保证了开发效率，又不会让所有项目背上无意义的资源负担。经过一段时间使用下来，这套方式让我在多个项目间切换时非常顺畅，报错率也明显降低。配置 MCP 这件事本身的难度并不高，真正拉开体验差距的，是对工具边界的理解和排查问题的思路。希望这篇内容能让你在配置 Claude Code 的 MCP 时少走几个弯路。