别再手写 mcp.json 了。你大概率也经历过这个场景在某个群里看到有人分享一个好用的 MCP Server比如 GitHub MCP 或者 Playwright MCP你兴冲冲点开官方文档复制了一段 JSON打算丢进 Cursor 或者 Claude Code 里。结果要么是 command 写错要么是缺了 env 里的 API Key要么是 Windows 和 macOS 的路径写法不一样折腾半小时MCP 面板里依然红彤彤一片。我干脆把这些资源做了一个聚合站不光把全网能找到的 MCP Server 都收进来还针对 Cursor、Claude Code 做了配置模板化和一键写入。写这篇博文的初衷就是想把“为什么这么设计”和“实操中到底怎么用”讲清楚顺便把我踩过的坑一并交代了。1. mcp.json 到底是什么为什么你会写出一堆玄学配置1.1 MCP 相当于给 AI 配了一排“外接设备”MCP 的全称是 Model Context Protocol模型上下文协议。很多刚开始接触 AI 编程的人会把 MCP 理解成“给 AI 插 U 盘”这个类比其实很接近你的 AI 编辑器Cursor、Claude Code本身只具备读代码、写代码的能力想让它操作浏览器、查询数据库、读写 GitHub 仓库就得给它挂上对应的“外接设备”。不过更准确的说法是MCP 是一个通信标准规定 AI 客户端和外部工具之间如何交换请求和结果。拆开看MCP 有三个角色MCP Client也就是 Cursor、Claude Code 这类 AI 编程工具负责发起请求。MCP Server一个本地或远程的服务进程真正去执行“查资料”“跑命令”“调接口”之类的操作。协议层消息采用 JSON-RPC 2.0 格式通过 stdio标准输入输出或者 HTTP 传输。在 mcp.json 这个文件里你不用关心协议细节只要声明“我要挂载哪些 Server”以及这些 Server 怎么启动。比如下面这个例子{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_TOKEN: 你的令牌 } } } }这段配置的意图很直白告诉 AI 编辑器帮我启动一个名为 github 的 MCP Server启动方式是通过 npx 拉取并运行modelcontextprotocol/server-github这个 npm 包同时给我注入一个环境变量 GITHUB_TOKEN。1.2 mcp.json 的字段拆解command、args、env 各自干什么我见过好多人在网上问“配置到底怎么写”其实字段并不复杂理解每个字段的含义就能少踩一半坑。字段作用说明command启动 MCP Server 的可执行程序常见的是npx、uvx、python也可能是某个二进制的绝对路径args传给命令的参数通常是-y加包名或者脚本路径env环境变量用于传入密钥、Token 等有些服务必须带 Token 才能启动比如 GitHub 的 MCP 如果缺了GITHUB_TOKEN会直接退出typeServer 的连接方式默认是stdio远程服务会写成sse或httpurl远程 MCP 服务的地址type 为sse/http时必填还有一种远程类型的配置长这样{ mcpServers: { playwright: { type: http, url: https://your-host.com/mcp } } }这种就不需要本地起进程AI 客户端直接通过 HTTP 请求远程服务。很多人忽略的是command在不同平台的差异。macOS 上npx可能装在/usr/local/bin/npxWindows 上可能叫npx.cmd。如果 Cursor 在启动 MCP Server 时找不到命令你需要写成绝对路径。这个问题在你手动配置的时候会遇到我后面会讲怎么用脚本统一处理。1.3 手写配置会踩哪些坑结合我自己的经历和群里问得最多的问题手写 mcp.json 的坑基本集中在四类。第一密钥环境变量容易漏。比如 GitHub MCP Server你要是没配 GITHUB_TOKENnpx 能顺利启动进程但进程会因为缺少认证直接退出或者一直报 401。这种问题最恶心的地方在于它不是一开始就报错而是等你用“查 issue”之类的工具时才暴露。第二平台差异。同一段配置在 macOS 能跑拿到 Windows 上就失效。原因通常是命令路径、shell 环境或者 npx 缓存策略不同。新版 Cursor 对 stdio 类型 Server 的启动环境做了较多限制有时候还会因为 SHELL 环境问题导致npx找不到。第三版本更新带来的字段漂移。这个我 2024 年最有感触很多 MCP Server 包从 0.x 快速迭代启动参数、命令名称变过一次。你保存的配置可能一个月后就不能用了不是写错了是上游改了。第四不同工具的配置格式不统一。Cursor、Claude Code、Trae、Codex 的配置各有差异同一个 MCP Server在 Cursor 能用不代表能直接粘贴进 Claude Code。你要自己维护一份“多工具适配”的配置心累得很。这也是我下决心做聚合站的原因既然全网的 MCP Server 信息本来就散落在各个文档里不如我把它集中起来把适配工作做成自动化的。2. 聚合站项目的设计思路从“整理文档”到“一次配置”2.1 为什么我不满足于“收集到 GitHub repo”最初的想法确实很朴素搞一个 awesome-mcp 列表收集各种 MCP Server 的地址和说明。但做了一周后我发现列表仓库解决不了实际使用问题。文档型仓库有三大毛病信息结构不统一。有人写“安装命令”有人写“配置 JSON”有人只给一个链接。真要照着配你还得自己把命令转换成 Cursor 认识的 mcp.json 格式这一步就是大部分人的门槛。检索效率低。当资源量超过 300 条以后靠 README 目录跳转找东西很痛苦更别说按“是否支持 SSE”“是否需要 Token”这类条件筛选了。更新滞后。很多 MCP Server 的维护很活跃今天改命令、明天改环境变量。如果靠人肉维护 README很快会变成一堆死链。所以我决定做一个真正的站点核心目标定成四件事统一资源收录、结构化字段、按工具生成配置、一键写入。2.2 数据从哪来资源收集与更新机制做收录的第一步是定字段。我每条资源至少包含以下信息名称与唯一 ID用于在配置管理中定位资源。一句话简介避免打开详情页才发现不是自己想要的。类型stdio 还是 SSE/HTTP。启动命令包括 command、args 的完整模板。环境变量清单哪些是可选的哪些是必须的。官方地址GitHub 或文档首页。适用客户端Cursor、Claude Code、通用等。维护状态活跃、归档、废弃。资源来源方面我每天会去扫这些地方GitHub 的 awesome-mcp 仓库、MCP 官方 registry、各社区的热门分享以及 GitHub 上按“mcp server”搜索的新仓库。初步收集后用半自动脚本抓取 README提取其中的安装和配置部分再由人工审核字段是否完整。你可能关心一个实际问题聚合站里的配置模板到底是谁生成的答案是两级生成。基础模板由资源维护者提供但我这边会手动跑一遍确认命令能启动、工具能返回结果后才标记为“已验证”。没验证的资源也不会删除只会标注“待验证”避免误导用户。2.3 一键配置到底是怎么“一键”的这是聚合站最核心的部分。用户在详情页选中 Cursor 或者 Claude Code 后点一个按钮就能拿到配置甚至可以自动写入本地文件。原理并不复杂把每一条 MCP 资源的元数据存成一套中性格式然后根据目标工具各自生成对应的配置片段。具体来说一套中性格式大致是{ name: github, description: Operate GitHub issues, PRs, repos, transport: stdio, command: { executable: npx, args: [-y, modelcontextprotocol/server-github] }, env: { GITHUB_TOKEN: }, envRequired: [GITHUB_TOKEN] }生成 Cursor 配置时直接拼装成mcpServers结构生成 Claude Code 配置时可以通过命令claude mcp add的等价参数拼接。所谓一键其实有三种实现方式我分开说。第一种最保守的一键生成 JSON用户自己粘贴到配置文件。适合企业对安全要求高的场景公司可能有统一配置管理不希望有脚本往开发者机器上写文件。第二种自动写入网页加载时尝试读取本地文件或者提供一个脚本把配置写入 Cursor 或 Claude Code 对应的存储位置。社区里有人用本地服务监听端口的方式实现也有人直接用浏览器 File System Access API。第三种命令行工具用户安装一个小 CLI通过mcpx add github --cursor这样的命令把配置写入正确位置。这种方式最适合多客户端用户参数也更灵活。聚合站上线第一版时我主推的是一键复制加引导式写入。复制解决的问题是格式正确性写入解决的问题是路径正确性。3. Cursor 和 Claude Code 的配置逻辑到底差在哪3.1 Cursor 的两种配置入口与优先级Cursor 支持两种 MCP 配置方式。第一种是项目级配置文件放在.cursor/mcp.json。只要项目根目录存在这个文件Cursor 会自动加载并且会在 Team 协作者之间同步。适合团队统一使用某些 MCP Server避免每个人手敲一遍。第二种是全局配置在 Cursor 设置界面的 MCP 页面里配置。官方路径是 Settings MCP Add。这种配置对当前用户的所有项目生效。这两者同时存在时优先级有点反直觉。项目级配置会覆盖全局配置中的同名 Server。我曾经专门验证过全局配置了一个名为github的 Server项目级又配置了一个同名的最终 Cursor 加载的是项目级那个。实际使用中我建议把通用的、非项目绑定的 Server比如代码检索类放全局把跟当前项目强关联的比如特定数据库连接放.cursor/mcp.json并提交进 Git 仓库方便团队共用。3.2 Claude Code 的配置方式Claude Code 的配置思路和 Cursor 不一样它对“作用域”有明确定义。你可以在项目根目录放一个.mcp.json项目级也可以直接用命令添加。Claude Code 的claude mcp add命令支持几种 scope# 项目级写入当前项目的 .mcp.json claude mcp add github -- npx -y modelcontextprotocol/server-github # 用户级写入当前用户的全局配置 claude mcp add github -s user -- npx -y modelcontextprotocol/server-github # 本地级仅对当前机器当前项目生效 claude mcp add github -s local -- npx -y modelcontextprotocol/server-github如果你更喜欢直接改文件Claude Code 的用户级配置保存在用户目录下的~/.claude.json其中包含mcpServers字段。3.3 同一份 MCP 元数据如何生成两种配置讲了这么多下面用表格看下同一份元数据在不同工具的差异。维度CursorClaude Code配置文件.cursor/mcp.json或全局设置.mcp.json、~/.claude.json或claude mcp add命令字段格式command、args、env命令式 配置式环境变量写法统一写进env对象用--env KEYVALUE参数或写进配置文件默认类型默认stdio默认stdio是否需要区分 scope不需要分项目级/全局需要明确local、project、user三级 scope聚合站的配置生成逻辑本质上就是在做这种“映射”。我维护一个工具适配器每种工具对应一个渲染函数输入中性格式元数据输出该工具可识别的配置片段。以 Claude Code 为例生成命令时我会把env里的多个变量展开成参数claude mcp add github -s project \ --env GITHUB_TOKENyour_token \ -- npx -y modelcontextprotocol/server-github这个参数是从claude mcp add --help里确认过的不同版本略有差异你是 1.x 还是 2.x 需以--help显示为准。4. 站点核心功能与实测记录4.1 首页与检索体验设计聚合站的首页我坚持做成“搜索优先”而不是“分类目录优先”。因为用户带着明确问题来的时候目录浏览是一种负担。检索上做的是关键词匹配加标签过滤标签包括按类型stdio / SSE / streamable HTTP。按领域GitHub、数据库、浏览器、文件、设计、运维等。按客户端兼容性Cursor 已验证、Claude Code 已验证、未验证。搜索结果页展示三个信息名称、一句话简介、所需环境变量数量。这个设计当初有个小故事一开始我想把“是否需要 Token”直接标在结果卡片上但发现有些 Server 的 Token 是可选而非必须于是改成显示“配置复杂度”标签分为简单、中、困难三档。4.2 配置向导选工具、生成配置、一键写入配置向导是这个站使用率最高的功能实际操作流程如下。第一步用户在资源详情页点击“配置到 Cursor”或“配置到 Claude Code”。第二步站点根据工具类型渲染出对应的配置区块并展示出来。对于需要填写环境变量的 Server页面上会出现输入框比如 GITHUB_TOKEN、API_KEY。填写完毕后再点击生成避免出现空 Token 导致 Server 启动失败。第三步根据用户选择提供两种操作如果选择“复制配置”则直接复制 JSON 或命令到剪贴板。如果选择“写入本地”则弹出引导协助写入对应配置文件。关于写入本地文件我需要强调一个安全设计站点脚本不收集、不上传任何 Token。用户填的 Token 只在浏览器本地完成拼接写入行为也由用户自己确认触发。在对接本地文件写入时我用了一个很轻的方案提供一个小型本地 CLI负责往.cursor/mcp.json或.mcp.json追加配置。CLI 收到的是浏览器传过去的配置文本不做额外网络请求所以 Token 不会出本机。这也是很多人在使用同类工具时最容易忽略的点。盗取开发者环境变量的攻击手法并不罕见所以我在站点醒目的位置加了提示并且默认关闭“自动写入”开关必须手动点击确认。4.3 实测从聚合站配置一个 GitHub MCP我用一个真实例子走一遍完整流程。假设我想在 Cursor 里配置 GitHub MCP用来操作仓库和 issue。第一件事在聚合站搜索框输入 github结果列表里找到标记“Cursor 已验证”的条目。打开详情页后看到环境变量要求是 GITHUB_TOKEN。我把自己的 Token 粘贴进输入框站点生成如下 JSON{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_TOKEN: ghp_xxxx } } } }我在项目根目录创建.cursor/mcp.json目录和文件把上面的内容写进去。重启 Cursor 后在 MCP 面板里看到 github 这个 Server 的状态为绿色。然后我打开 Cursor 的对话面板输入“列出这个仓库最近 5 个 issue”AI 直接把请求发给了 GitHub MCP Server返回了真实的 issue 列表。到这里MCP 配置全链路是通的。同样的资源如果想配到 Claude Code聚合站会生成另一段命令cd /path/to/your/project claude mcp add github -s project \ --env GITHUB_TOKENghp_xxxx \ -- npx -y modelcontextprotocol/server-github执行完用claude mcp list检查能看到 github 出现在项目级 scope 中。整个流程下来我自己最满意的点是“环境变量必填检查”。过去手写配置很容易漏掉 GITHUB_TOKEN写完后还要花时间排查。现在向导步骤里如果不填 Token 就直接点了生成站点会明确提示缺失项比在编辑器里面对红色报错要友好得多。5. 常见问题与排查技巧实录5.1 配置了 MCP 但 Cursor 显示加载失败这是遇到最多的一个问题你在 Cursor 的 MCP 面板里添加了 Server状态却一直是红色或黄色。大概率是以下三个原因之一。第一command对应的可执行文件不在 Cursor 的搜索路径中。Cursor 在某些系统环境下不会继承你 Shell 里的 PATH导致npx或者uvx找不到。解决办法是把 command 替换成绝对路径比如 macOS 上执行which npx得到/Users/yourname/.nvm/versions/node/v18.20.4/bin/npx然后配置成{ mcpServers: { github: { command: /Users/yourname/.nvm/versions/node/v18.20.4/bin/npx, args: [-y, modelcontextprotocol/server-github] } } }第二环境变量缺失。如果 Server 初始化需要读取某些环境变量你没写在env里进程会启动失败或者运行异常。排查手段是先手动打开终端的 MCP Server观察启动输出。第三本地进程启动时没有 Node 环境。如果你的 MCP Server 是基于 Node 的而 Cursor 内置的 Node 版本太低或没装也会失败。这种通常是 Node 版本冲突用node -v检查本机版本再和 Server 要求的版本对比。5.2 Claude Code 提示 Permission denied 或无法启动Claude Code 的 MCP Server 启动本质是在你的机器上执行命令所以权限问题很常见。我用claude mcp add添加后第一次调用时报了 Permission denied。排查后发现问题出在npx缓存目录的访问权限上。一般是运行claude mcp add时用的用户身份和实际执行 npx 命令的用户不一致导致的。可以试试清理 npm 缓存并重新设置目录权限npm config get cache sudo chown -R $(whoami) $(npm config get cache)另一个常见问题是用了yarn或pnpm作为启动器但 Claude Code 执行命令时找不到对应包管理器。这类问题的排查思路是一致的找到报错日志看它卡在哪个命令上再手动在终端里跑一遍相同的命令。5.3 同一个 MCP Server 在 Cursor 能用、在 Claude Code 不能用这问题我查过一次发现不是配置错误而是 Claude Code 对 stdio 类型的 MCP Server 有额外的环境要求。它需要command对应的可执行文件在子进程环境中可见。换句话讲你用zsh或bash时能跑通但 Claude Code 启动 MCP Server 时用的是自己的子进程环境不一定加载了你的 Shell 配置。解决方法有两个一是把 command 写成绝对路径二是在启动 Claude Code 前在 Shell 里export PATH确保npx可见。如果你用的是direnv之类的工具确认.envrc在交互式 Shell 和子进程里都会被加载。5.4 快速排查表现象常见原因排查方向Cursor MCP 面板显示红色command 找不到 / env 缺失检查 PATH、检查环境变量Claude Code 工具不响应npx 缓存权限 / Node 版本手动执行启动命令观察报错添加后提示 unknown transport远程服务类型写错确认是 sse 还是 httpMCP Server 能启动但工具调用超时远程服务地址不通 / Token 过期用 curl 测试 URL 连通性配置修改后不生效Cursor 未重启 / scope 冲突重启编辑器检查同名 Server 优先级这个表我原本是放到项目 README 里的后来发现直接放在站点帮助页阅读量比 README 高不少。可见大家真正关心的是自救而不是看文档。6. 聚合站的边界与后续规划目前聚合站已经收录了 600 多个 MCP 资源覆盖大部分主流场景。但说实话做这个项目越久我越意识到 MCP 生态还远未成熟。有些 Server 只是实验品三天两头改接口我标记了“已验证”也只能保证收录当天的状态可用。所以只要是自动适配生成配置的地方我都加了“验证时间”字段降低对用户的误导。另一个边界是聚合站的一键配置主要解决“格式怎么生成”“文件写到哪”的问题不解决“哪些 MCP 值得装”。所以我最近在做的功能是使用频率统计和社区的“好用”投票希望帮用户区分出真正在生产环境跑过的 Server 和只是写着玩的 Demo。给想自己搭类似工具的人一个建议别一上来就想把 Cursor、Claude Code、Trae、Codex 全部支持。先吃透一个工具的配置规则比如 Cursor 的.cursor/mcp.json把字段、路径、优先级都搞清楚再做第二个。适配器架构要提前设计否则每加一个工具你的代码就会多出很多 if else。最后分享一个我的使用习惯。我并不会把聚合站里所有 MCP 都配进编辑器而是在项目开始时按需配置。配置太多会显著拖慢 Cursor 的启动速度而且 AI 在选择工具时也会迷茫。现在我的个人配置里长期启用的只有三四个剩下都是这个项目要用哪个就临时加哪个。这和我做聚合站最初的判断是一致的比堆积资源更重要的是知道哪条配置真正有用。