三款编程助手的 MCP 配置差异速查

同一个 MCP 服务，搬到 Claude Code、Cursor 和 Codex 时，配置不能直接照抄。dev.to 上这篇文章对照了三款工具的配置位置、环境变量和加载检查方法。最容易卡住迁移的，是远程服务声明和变量写法。不过，作者只检查了配置语法，没有在三款工具里实际运行。

目前能确认什么

MCP 是编程助手连接外部工具与数据源的协议。支持同一协议，不代表客户端采用同一套配置格式。

原文给出的项目级配置位置分别是：

• Claude Code：仓库根目录的 .mcp.json，使用 JSON。
• Cursor：.cursor/mcp.json，使用 JSON。
• Codex：.codex/config.toml，通过 [mcp_servers.<name>] 表配置服务；项目受信任后才加载。

环境变量也有三种写法。以远程服务的 Bearer Token 为例，Claude Code 使用 ${TEAM_DOCS_TOKEN}，Cursor 使用 ${env:TEAM_DOCS_TOKEN}；Codex 则用 bearer_token_env_var 指定变量名。

按原文说明，Claude Code 的远程 HTTP 服务还需要显式声明 "type": "http"。只填 url 会被当作缺少类型的配置。

我的判断

跨工具迁移配置，应当按各自规则重写。

排错时，我会先检查路径、变量语法和远程类型。Codex 还要检查项目是否已受信任，否则配置文件即使存在，也可能被跳过。Claude Code 和 Codex 可以分别用 claude mcp list、codex mcp list 检查加载情况，再排查连接和认证。

语法解析通过，只能证明文件格式正确。

作者明确没有验证工具内的实际运行，因此这些示例还不能当作已跑通的模板。当前节选也没有完整展示三款工具的同名配置覆盖规则，Cursor 的加载检查入口同样未展开；遇到服务被覆盖或变量未生效，仍需对应官方文档确认。