Claude Code接入8个MCP Server，打造全能AI开发助手

1. 别急着写提示词，先给 Claude Code 装好“手”和“眼睛”

最近一直在折腾 Claude Code，越用越觉得一个道理：真正让 Claude 从“聊天机器人”变成“干活搭子”的，不是提示词模板，而是它能访问什么、能操作什么。原生的 Claude Code 当然已经能读文件、改代码、跑命令，但它的能力边界基本被限定在项目目录和终端里。一旦你想让它查个网页、翻个文档、提个 Issue、连一下数据库，它立刻就哑火了。

我给 Claude Code 接上 8 个 MCP Server 之后，体验完全是两个级别。如果说原版 Claude Code 是一个刚入职的“实习程序员”，手上有台终端但不知道往哪走；那接满 MCP 之后就相当于给这个实习程序员配了整套办公环境——有会议纪要、有代码仓库、有浏览器、有文档库、有数据库客户端，甚至连部署工具都备好了。这篇文章就把我这套组合拳完整拆开，每个 Server 解决什么问题、怎么装、怎么配、有哪些坑，全写清楚。

先说下适用范围。如果你只是偶尔拿 Claude Code 写个脚本、问个问题，那这篇文章的很多内容暂时用不上；但只要你打算让它处理真实项目——尤其是涉及前端页面、第三方 API、GitHub 协作、数据库读写或者项目结构重构——那这 8 个工具里至少有一半会对你有帮助。我下面写的配置方式基于 Claude Code 当前的 CLI 版本，按步骤走基本都能复现。

2. 先把基础打牢：MCP 是什么，Claude Code 里到底怎么接

2.1 MCP 的本质是“外接能力”，不是新语言

MCP 的全称叫 Model Context Protocol，是 Anthropic 提出的一个开放协议，目的是让 AI 模型能够标准化地调用外部工具。你不需要把它理解成什么高深的框架，简单说，它就是一个“USB 接口”——Claude Code 是主机，MCP Server 是外设，插上 U 盘能拷文件，插上摄像头就能看画面。每个 MCP Server 都会丢给 Claude 一份“工具清单”，Claude 发现“哦我可以调用这个工具拿到搜索结果”，然后在回答问题时自主决定什么时候调、怎么调。

这个设计带来的优势是巨大的。传统的 AI 编程助手把所有功能写死在提示词里，你能干什么、不能干什么，全取决于厂商做了多少集成。但 MCP 把“能力边界”开放给了开发者和社区，任何人写一个 Server，Claude 就能瞬间多一个技能。这对工程师来说等于做了一次“能力解耦”，你不用再等官方版本更新支持某个工具了。

2.2 Claude Code 的 MCP 配置入口

Claude Code 对 MCP 的支持有两种方式：一是通过.mcp.json文件做项目级配置，二是通过claude mcp add命令做用户级配置。两种方式各有适用场景：

• 项目级配置写在当前项目的.mcp.json里，跟着代码仓库走，团队成员 clone 下来就能直接用；
• 用户级配置关联到你的全局环境，对所有项目生效，适合那些“个人开发环境必备”的工具。

我个人的习惯是：开发类工具（GitHub、Filesystem、Context7）走用户级配置，因为它们在任何项目里都能用；而项目相关的、带环境变量的（数据库、云服务）走项目级配置，避免把密钥之类的东西提交到代码库。

2.3 一条命令搞定 MCP Server 接线

Claude Code 的 MCP 配置非常直接，比如装官方文件系统 MCP：

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ~/workspace

这个命令的意思是：注册一个名为filesystem的 MCP Server，通过npx运行官方包，并且只允许它访问~/workspace目录。之后你重新启动 Claude Code 或者在会话里执行/mcp，就能看到这个 Server 已经在列表里了，状态是 connected。

如果你想删掉，执行：

claude mcp remove filesystem

如果想查看当前所有 MCP Server 的连接状态，直接在 Claude Code 的输入框里输入/mcp回车，它会列出每个 Server 的名字、类型、工具数量和连接状态。这个命令在排查问题时特别有用，我能直接看到是哪个 Server 挂了。

另外要注意，MCP Server 的启动条件五花八门。有的需要 Node 环境，有的需要 Python 环境，有的要 Docker，还有的会读取本地配置文件。我的建议是，不管装哪个 Server，先把它的依赖环境跑通，再用/mcp检查状态，不要一口气堆七八个再一起排错，那样出了问题很难定位。

3. 第一个武器：GitHub MCP Server，把 Claude 变成真正的协作者

3.1 为什么 Claude Code 需要一个 GitHub 专用连接器

原生的 Claude Code 虽然能执行git命令，但它只能操作本地仓库，无法访问 GitHub 上的 Issue、PR、Release、代码搜索这些远程资源。举个例子，我想让 Claude 帮我梳理一个开源项目的最新 Release 变更，原生环境下它只能看着 README 猜，根本拿不到精确数据。而接上 GitHub MCP Server 之后，Claude 可以直接调用 GitHub API，做到“拉取 Issue 列表—分析标签—定位关联代码—提出修改方案”这一整条链路。

这个 Server 还有一个很实际的用法：让 Claude 读懂“组织仓库”里的工程规范。很多团队的 README 写得不够详细，但 Issue 和 PR 里充满了上下文。Claude 能直接搜索那些 Issue，并从中总结出代码风格偏好、模块划分习惯，然后照着这一套规范去写新代码。

3.2 安装 GitHub MCP Server 的两种方案

官方推荐的做法是配置 OAuth 令牌，但国内网络环境访问 token 服务时偶有波动，所以我更推荐用个人访问令牌（PAT）方式：

第一步：生成 GitHub Personal Access Token

登录 GitHub，进入 Settings → Developer settings → Personal access tokens → Tokens (classic)，生成一个新 token，勾选以下权限：

• repo：读写仓库、Issue、PR
• read:org：读取组织信息
• workflow：如果需要操作 GitHub Actions，就勾这一项

Token 生成后立刻复制保存，只显示一次。

第二步：写入 Claude Code 配置

claude mcp add github --env GITHUB_TOKEN=你的TOKEN -- npx -y @modelcontextprotocol/server-github

这里把 Token 放进环境变量里传给 MCP Server，而不是硬编码进某个文件，相对更安全。配置完成后，执行/mcp看状态，如果显示 connected，表示 GitHub 已经和 Claude Code 握手成功。

3.3 我总结的高频实战场景

• Issue 处理：让 Claude 列出所有带bug标签的未处理 Issue，按紧急程度排序，并给出每个 Issue 对应的可能代码位置；
• PR 总结：读一个 PR 的所有改动文件，概括改动意图，找出潜在风险点；
• Release 对比：对比两个版本之间的 Release Notes，生成升级影响分析。

我的实际体验是，GitHub Server 连接后，Claude 对项目“背景知识”的掌握度有了质变。以前它是站在代码库里看问题，现在等于有了整个组织的协作全貌。这个 Server 是目前 8 个里我用得最频繁的一个，没有之一。

4. 第二个武器：Playwright MCP Server，让 Claude 真正“看见”网页

4.1 原版的盲区：Claude 看不到页面渲染结果

很多前端工程师用 Claude Code 写页面时会遇到一个尴尬：Claude 改完代码，我本地跑起来看一眼，发现布局乱了、接口报错了，又得把报错信息粘回去让它再改。如此反复几轮，效率极低，因为 Claude 从头到尾都“看不见”浏览器里发生了什么。

Playwright MCP Server 解决的就是这个问题。它给 Claude 提供了一个可操作的浏览器环境，Claude 能主动打开 URL、点击按钮、填写表单、截图、读取控制台日志，甚至录制整个页面的运行轨迹。装上它之后，Claude 第一次从“纯文本世界的程序员”变成了“带眼睛的测试工程师”。

4.2 安装 Playwright MCP Server

需要先装 Playwright 的浏览器内核，然后通过 npx 启动 Server：

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

注意，第一行的浏览器内核安装非常关键，如果跳过，Server 能启动但无法打开任何网页。装好后，在 Claude Code 里输入/mcp，确认 playwright 是 connected 状态。

4.3 一个物超所值的自动化用例

我在写一个后台管理系统的登录页时，让 Claude 做了这样一件事：打开本地开发服务器，访问登录页面，输入测试账号密码，点击登录，等待 3 秒后截图，并把页面上出现的所有错误信息反馈给我。

Claude 的整个流程是：

1. 调用browser_navigate打开http://localhost:5173/login；
2. 调用browser_click点击账号输入框，输入固定测试账号；
3. 重复操作密码框；
4. 点击登录按钮；
5. 等待页面响应，截图并保存到项目目录；
6. 读取控制台网络请求，把 4xx、5xx 错误汇总输出。

这在以前，我得手动打开浏览器、摆好断点、翻控制台日志，来回折腾 20 分钟。现在一条指令，30 秒后拿到截图和错误列表。虽然它不是百分之百代替人工测试，但做“冒烟测试”和“桌面验收”完全够用。

4.4 几个容易踩的坑

• 端口冲突：如果本地服务器监听的端口被其他进程占用，页面打开会失败，Claude 会报 “net::ERR_CONNECTION_REFUSED”，这时候手动检查端口占用再放行；
• 权限弹窗：涉及文件下载或者浏览器通知的页面，可能会被系统的权限弹窗卡住，需要在浏览器上下文里预设acceptDownload参数，或者直接初始化为默认拒绝；
• 长流程容易超时：默认超时时间较短，遇到数据量大的表格页，页面迟迟加载不完会中断，此时可以让 Claude 先调用接口接口延时，或者扩大超时配置。

5. 第三个武器：Context7 MCP Server，解决“知识过期”的难题

5.1 大模型训练数据是“过期的”，但文档库不是

无论是 Claude 还是 GPT，它们的训练数据都有截止日期。我在实际开发中经常遇到这种情况：Claude 给的 API 写法在某个版本之后已经废弃了，但它还在按老版本推荐。比如 React 19 发布后，很多旧的生命周期写法变了，Claude 不知道，就按老写法生成，编译直接报错。

Context7 解决的正是这个问题。它本质上是一个“文档检索中台”，把当下最新的 SDK 文档、框架文档、API 文档抓取、索引、更新，然后通过 MCP 暴露给 Claude。Claude 在回答问题时，如果发现拿不准最新用法，会主动去 Context7 检索对应库的官方文档，拿到最新版本的信息再作答。

5.2 安装与使用

Context7 的安装非常简单，一条命令：

claude mcp add context7 -- npx -y @upstash/context7-mcp

装好之后，Claude Code 里可以直接让它“帮我查一下 Next.js 15 的 middleware 最新写法”，它会按以下步骤执行：

1. 调用 context7 的search_documentation工具，搜索 “Next.js middleware”；
2. 返回多个相关文档片段，并附上来源 URL；
3. Claude 综合信息后给出新的实现代码，并且会标注参考来源。

5.3 我用它跳过的最大的坑

之前我需要用某个云服务商的 Java SDK 接入对象存储。那 SDK 的版本更新很快，网上搜到的中文教程至少落后了三个大版本。我直接让 Claude 去查 Context7 上的官方 Java SDK 文档，它很快就基于最新 API 写出了完整的上传、下载、断点续传代码，跑起来一次通过。

如果你经常需要对接第三方 SDK 或者框架的新版本，Context7 应该是必备项。它不像其他 Server 那样“看得见摸得着”，但“信息准确”这个价值往往被低估。代码报错还能调试，信息源错了就真的是无头苍蝇。这个工具的作用就是把“无头苍蝇”的概率降到最低。

6. 第四个武器：Fetch MCP Server，给 Claude 补上“联网搜索”能力

6.1 它和 Context7 的区别

有人会问，Context7 不是已经能查文档了吗，为什么还要一个 Fetch？这俩定位完全不同。Context7 只做“文档检索”，输入的是技术文档；而 Fetch 是一个通用网页抓取器，任何 URL 都能拿，能解析 HTML、提取正文、抓接口返回的 JSON，甚至支持模拟请求头。换句话说，Fetch 负责“信息获取”，Context7 负责“技术知识获取”。

Fetch 在 Claude Code 中的典型场景是：我给你一个链接，你帮我总结这个网页说了什么；或者我给你一个 API 的 OpenAPI 文档，你解析出来然后生成本地调用代码。后者我在日常开发里用得非常多。

6.2 配置 Fetch MCP Server

Fetch 是官方维护的 TypeScript SDK 示例之一，安装方式：

claude mcp add fetch -- npx -y mcp-server-fetch

装好后，直接输入一个网址，Claude 会调用fetch工具去拉取网页内容。支持的协议包括http、https，并且能处理重定向。

6.3 半自动化接口对接实操

有一次我要对接一个第三方支付平台的回调解析逻辑，对方只给了一个在线 OpenAPI 文档链接。我把链接丢给 Claude，让它“解析这个 OpenAPI 文档，提取 webhook 回调的签名校验字段，写出 Java 实现”。Claude 先抓取页面，从中提取出 OpenAPI JSON，再解析出回调参数和验签算法，最后生成了一版完整的签名校验代码。整个流程大概两分钟。要是人工去看文档再手写，半小时起步，还容易漏字段。

不过 Fetch 也有局限：遇到需要 JS 渲染才能显示内容的 SPA 页面，它抓取到的 HTML 可能是空壳，因为数据是异步加载的。这种情况我通常改用 Playwright，让浏览器先渲染完成再抓取，两个工具配合，基本覆盖所有页面类型。

7. 第五个武器：Filesystem MCP Server，把“文件操作权限”精装修

7.1 为什么不直接用原生的文件操作能力

Claude Code 原生就支持读取和修改项目目录内的文件，那为什么还需要 Filesystem MCP？关键在于“目录边界”和“结构化操作”。原生模式下，Claude 只被允许访问当前项目目录，你没法让它批量浏览一个任意路径、生成文件索引、同时读取多个分散位置的配置。而 Filesystem 可以指定多个允许访问的根目录，Claude 能在这些目录之间自由穿梭，完成跨目录分析。

这个工具最典型的场景是“全仓库代码审计”。比如一个 monorepo 项目有 20 多个子包，我想让 Claude 分析每个子包的依赖版本和健康状态。原生的文件遍历能力有限，而 Filesystem Server 提供了更丰富、更结构化的文件树浏览方式，Claude 能一步步展开目录、读取每个 package.json、汇总成一张依赖矩阵表。

7.2 安装方式

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ~/workspace ~/projects

这里~/workspace和~/projects是允许访问的根目录，多个路径用空格隔开。如果有绝对路径权限需求（比如读 VSCode 配置），可以再加一个路径进去。

7.3 注意事项：别把整个根目录放进去

我见过有人直接把/设为访问根目录，这非常危险。因为 Claude 可能误删文件或修改系统配置，虽然它通常会先问一句，但多一层安全边界总是好的。我把 Filesystem 的访问范围严格限定在个人工作区和几个常用目录，其他系统路径一概不让碰。

实际上，Filesystem MCP 更适合的场景是“批量文件处理”。比如让 Claude 把所有 MD 文件标题统一格式、按日期重命名、生成项目文档目录索引，这些重复性劳动用原生命令写几个命令也能做，但 Claude 配合 Filesystem 后能一次性生成完整方案并执行，省去了人工写脚本和调试的时间。

8. 第六个武器：SQLite MCP Server，让 Claude 直接操作数据库

8.1 本地数据库不该是 Claude 的盲区

很多工具类项目会使用 SQLite 作为本地存储。但 Claude Code 原生不能直接操作数据库，你最多让它生成 SQL 语句，自己再去 DBeaver 里执行。装上 SQLite MCP Server 后，Claude 可以直接连库、查表结构、执行查询、写入数据，甚至做简单的数据迁移。

这个 Server 对我的价值在于数据分析类任务。之前做一个数据清洗脚本，我需要搞清楚一个 2GB 的 SQLite 表里到底有哪些异常值。我让 Claude 打开数据库、列出所有表名和字段、按条件分组统计、找出数据质量问题，它在几分钟内就执行了一轮完整的探索性数据分析。

8.2 安装与配置

使用 uv 方式安装：

claude mcp add sqlite -- uvx mcp-server-sqlite --db-path ~/data/mydatabase.db

这里--db-path指定数据库文件的绝对路径。如果你有一个.db文件，用这种方式直接连上去即可。

8.3 一个更激进的用法：自动生成数据维护脚本

我经常让 Claude 完成这类任务：“把 orders 表中所有 2024 年之前且 status 为 cancelled 的订单，导入到一个归档表里，然后从原表中删除。”Claude 会先查看表结构，再生成 SQL，然后执行，并用explain query plan验证是否走了索引，最后报告处理行数和耗时。整个过程我只需要在旁边看着，非常省心。

有一点必须提醒：写操作是不可逆的。我在让 Claude 执行 DELETE 或者 UPDATE 之前，一定会先让它跑一条SELECT COUNT(*)确认影响行数，再要求它用事务包裹写语句。这个习惯帮我在一次清空测试数据的任务里躲过了误删生产数据的风险。

8.4 权限与隔离的建议

SQLite MCP Server 不支持细粒度权限控制，它能访问你指定的那个数据库文件，并且拥有完全读写权限。所以千万不要用一个生产环境数据库来测试，一定要用本地副本或测试库。等验证没问题后，再在受控环境下对生产库执行同样的操作。

9. 第七个武器：Chrome DevTools MCP Server，给 Claude 一个“调试台”

9.1 当一个开发者同时拥有浏览器和调试器

Chrome DevTools MCP Server 和 Playwright 看起来像，但定位有差异。Playwright 更适合“自动化操作”，比如点击、跳转、截图；而 Chrome DevTools MCP 更像是给 Claude 一个 Chrome 开发者工具的接口，用来做性能检测、网络流量分析、DOM 结构探测、JavaScript 执行报错收集。

我最常用的场景是性能优化。让 Claude 打开一个页面，记录 Page Load 时间、Largest Contentful Paint、网络请求数量、JS 错误数量，然后和代码库结合起来分析性能瓶颈。它不像手工打开 DevTools 那样需要一个一个面板找，而是直接把数据打包给 Claude，Claude 再结合项目代码给出优化建议。

9.2 安装配置

claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest

这个 Server 的启动依赖 Chrome DevTools 协议，默认会自己拉起一个 Chrome 实例。如果你是 macOS，首次运行大概率会弹链接端口提示，选择允许即可。

9.3 调试案例：定位页面白屏

有一个项目上线后偶发性白屏，控制台报一个第三方脚本的跨域错误。我用 Claude Code 接入 Chrome DevTools MCP，让它打开线上页面、抓取控制台日志、定位报错脚本、分析网络请求中被 Blocked 的第三方资地址域名、再结合代码查看防抖逻辑是否被异常打断。最终在一个小时内锁定了问题根源：一个 Promise 异常没有被捕获，导致后续渲染函数没有执行。

如果完全靠人工去复现白屏条件，可能需要抓瞎很久。Chrome DevTools MCP 让这个过程变得可编程、可复现，尤其适合处理“只在小概率条件下出现”的 Bug。

9.4 性能开销提醒

Chrome DevTools MCP 会启动一个真实的浏览器进程，内存占用通常在 500MB 以上。如果你的开发机器配置不高，同时开着 IDE、Docker、浏览器和多个 Server，可能会卡顿。我的建议是：只在需要调试时临时启用，平时可以用/mcp将它断开连接，不用的工具别一直挂着。

10. 第八个武器：Serverless MCP Server，把“最后一公里”也交给 Claude

10.1 从写代码到部署，一次对话完成

接完前 7 个工具后，Claude 已经能干到“把代码写好、本地测试通过”这一步了。但真正的交付往往在云端：把函数部署上去、配置触发规则、查看日志、回滚版本。如果每次都要切到云控制台手动操作一遍，体验还谈不上完整。

Serverless MCP Server 就是用来打通这一环的。它通过统一接口对接主流云厂商的无服务器产品，让 Claude 能够执行部署函数、读取函数配置、拉取最近日志、调整并发数量、触发版本回滚等操作。

10.2 安装配置

不同的云厂商配置方式不同，但核心逻辑一致：提供访问凭据，然后让 Server 通过 CLI 或 API 操作云端资源。以 AWS Lambda 为例：

claude mcp add serverless --env AWS_ACCESS_KEY_ID=你的KEY --env AWS_SECRET_ACCESS_KEY=你的SECRET --env AWS_REGION=ap-southeast-1 -- npx -y serverless-mcp

在使用前，建议先创建一个只有该函数操作权限的 IAM 用户，不要把管理员密钥交给 MCP Server。这属于最基本的访问控制原则，但很多人一开始图省事，用了个高权限密钥，后面出问题才开始慌张。

10.3 部署任务的完整流水线

我现在经常用一句指令完成整个部署流程：从代码提交到云端发布：

“把当前改动提交并推送，然后构建前端项目，再部署到 Lambda，并查看部署日志确认是否成功。”

Claude 的执行链路会是：

1. 用bash执行git add/commit/push；
2. 触发项目构建命令；
3. 调用 Serverless MCP 执行部署；
4. 拉取云端日志，检查 CloudWatch 里是否有关键错误；
5. 返回部署结果摘要和当前版本号。

这一套链路接完，Claude Code 就不再只是一个代码编辑器，而是一个有完整开发运维能力的“远程工程师”。

10.4 关于云厂商选择的建议

全组件的 Serverless MCP Server 已经隐去了厂商差异，但不同云平台在函数冷启动、队列、日志方面的表现还是有差异。建议优先选择你团队正在用的云平台。如果只是个人项目，可以选择免费额度较多的服务，把成本控制在最低。MCP 生态里社区贡献者一直在集成新平台，现在能接的厂商已经不少，找一个自己熟的接入即可。

11. 从“能用”到“好用”：MCP 组合拳的管理心得

11.1 8 个 Server 的定位对照表

装完 8 个工具后，我整理过一张对照表，方便自己按场景调用，这里分享给各位：

Server 名称	能力定位	典型使用场景	配置复杂度
GitHub	代码托管与协作	Issue/PR 处理、版本对比	中（需 Token）
Playwright	浏览器自动化	页面交互测试、截图、控制台日志	中（需装内核）
Context7	最新技术文档检索	查新版 SDK/框架用法	低
Fetch	通用网页抓取	总结网页、解析 OpenAPI	低
Filesystem	结构化文件访问	跨目录分析、批量文件处理	低
SQLite	本地数据库操作	查询、写入、数据迁移	低
Chrome DevTools	浏览器性能调试	白屏问题、性能瓶颈、网络分析	中（需浏览器）
Serverless	云函数部署运维	部署、日志、回滚	高（云端凭据）

11.2 组合使用的顺序与节奏

并不是每个任务都要把 8 个 Server 全部启用。我的习惯是常驻 3 个基础工具：GitHub、Context7、Filesystem，它们在任何项目中都有用且资源占用低。Playwright 和 Chrome DevTools 则按需启用——做前端任务时拉起来，做完就断开，保持环境干净。Serverless、SQLite 和 Fetch 则视具体需求决定。

组合使用的顺序也很重要。比如要完成“优化一个有性能问题的官网页面”这个任务，我会安排 Claude 用 Chrome DevTools 先测量指标，再让 Claude 定位代码，改完后用 Playwright 跑一遍冒烟测试，最后由 Serverless 把新版本部署上去。这个链路其实就是真实开发者面对问题的处理顺序，MCP 只是让 Claude 能够完整地执行这个过程。

11.3 配置好之后，Claude Code 的日常体验

接完这套 MCP，我最大的感受是：对话式的开发不再只是“生成代码”，而是真正进入了“执行任务”的模式。我可以连续说：

打开项目目录，查看最近 5 个 commit 和最近的 Issue，帮我分析一下有没有关联，然后跑一遍测试，让我看看覆盖率，如果低于 80% 就把未覆盖的关键函数列出来。”

Claude 会依次调用 GitHub（查 Issue）、Filesystem（读文件）、Bash（跑测试），然后把结果汇总。这种跨工具的调度能力，在没有 MCP 之前是做不到的。现在它不只是一个自动补全工具，而是一个有手、有眼、有工具的工程助理。

12. 常见报错与排查实录

12.1 报错：MCP Server 无法连接 / disconnected

现象：执行/mcp看到某个 Server 状态是 disconnected。

排查思路：

• 先确认启动方式依赖的运行时是否正常。比如基于 npx 启动的 Server，Node.js 版本是否满足要求。建议使用 Node 18 以上；
• 如果 Server 依赖浏览器（Playwright、Chrome DevTools），检查浏览器内核是否安装完整。可以手动跑一遍启动命令，看终端有没有报错提示；
• 网络因素。某些 Server 启动时需要拉取远程配置或注册远程服务，网络不稳定会失败。重试一次即可；
• 检查环境变量是否传到位。GitHub、Serverless 这类需要密钥的工具，密钥缺失会导致握手失败。

经验：我现在排查任何 MCP 问题，第一件事就是启动 Claude Code 后用/mcp查看连接状态，同时打开一个独立终端，手动执行 npx 命令，看进程能否正常守护运行。这个笨办法能过滤掉大部分环境问题。

12.2 报错：Claude 默认无法调用某个 MCP 工具

现象：工具列表里能看到 MCP Server，但 Claude 就是不主动调用。

原因：Claude 只有在认为某个工具与当前任务相关时才会使用。如果你没有明确提示，它可能忽略。另一个原因是工具描述不够具体，或者任务上下文里没有诱导它使用工具的信息。

解决方法：直接告诉它“你可以用 GitHub MCP 去查一下这个 Issue”。MCP 的调用决定权仍在 Claude 手里，有时候需要给它一点提示，这一点其实和跟真人协作很像，你不说，对方可能不知道用哪个工具。

12.3 报错：权限受限 / 文件越界

现象：Claude 尝试访问一个不在允许列表里的路径，被拒绝。

原因：Filesystem MCP 对根目录有严格限制，不在配置里的路径一律不允许访问。

解决方法：在配置时将常用目录都加进去。但注意，添加路径时尽量精确到项目级，不要把整个 home 目录或系统根目录都开放，安全第一。

12.4 报错：浏览器自动化跑不动，或无头模式不稳定

现象：Playwright 启动浏览器后，偶尔会出现超时、元素找不到、或者点击无响应。

原因：常见原因有三个：页面依赖了较慢的第三方接口、测试环境网络波动、或者选择器写得不稳。另外一个常见原因是浏览器进程残留，导致新实例无法正常启动。

解决方法：

• 先杀掉残留的浏览器进程，再让 Claude 重试；
• 让 Claude 等待某个固定元素出现后再继续操作；
• 增加超时时间；
• 对于依赖大量异步加载的页面，优先用wait_for_selector等显式等待方式，而不是固定 sleep。

12.5 报错：Serverless 部署经常卡在权限上

现象：Claude 执行部署时，提示 AccessDenied 或 Unauthorized。

原因：大多数情况下是云平台的 IAM 权限配置没有覆盖所需操作，比如只给了函数权限但没给日志权限。

解决方法：在配置云端凭据时，同时授予函数操作、日志读取、服务发现三项权限。再不行，直接用一个更宽的只读策略 + 特定资源限制策略来调试，定位到底缺了哪个 API 权限。

13. 我踩过的那些坑，以及最后想说的

前前后后折腾了一个多星期，期间也有过想放弃的时刻。最痛苦的其实是生态还在快速迭代，很多 Server 的配置方式过一两个月就变了，网上的教程永远滞后。所以“装不上”不一定是你的问题，更可能是新版本把参数改了。遇到这类情况，我的习惯是直接看 GitHub 仓库的 README 和 release notes，比任何教程都靠谱。

选 Server 也不用盲目追求数量。很多人一上来就装十几个 MCP，结果资源占用爆表、对话上下文被工具描述填满、连 Claude 自己都搞不清该用哪个。真正值得长期使用的，是你日常开发流程里反复要碰的那几个。我这 8 个是经过筛选留下来的，不代表多多益善。

另外，安全始终要放在心上。MCP Server 本质上是给 Claude 打开了更多操作权限，权限越大，出错成本越高。我的原则是：能用最小权限就不用大权限，能在测试环境跑就不在生产环境跑，能加事务就不裸执行写语句。这样才能既享受 AI 编程的效率提升，又不会把自己带进坑里。

最后说个小技巧：MCP Server 是支持动态启停的，不用长期全部挂着。比如我在写完代码需要验收时启动 Playwright，验收完就/mcp删掉或断开。Claude Code 的会话会变干净，上下文也更聚焦。工具是按需调用的，不是越多越好的装饰品。