2026 年 OpenAI Codex 十大最佳 MCP 服务器

本指南介绍了十个值得连接到 Codex 的 MCP 服务器，以及三个经常出现在其他榜单中、但不应出现在你的列表里的服务器。第一个是 Bright Data MCP它填补了 Codex 自身无法弥补的缺口：读取设有防护机制的页面所呈现的实时网络内容。你将了解：

1. Codex 中的 MCP 支持在 2026 年究竟如何运作，包括发生了哪些变化，以及大多数指南仍然存在哪些错误。
2. 哪十个服务器值得使用，以及每个服务器对应的确切 TOML 配置。
3. 每个服务器在执行任何工作之前会带来哪些成本。
4. 应跳过哪些热门服务器，以及为什么其中两个属于安全问题，而不只是个人偏好。

先说明一下评选方法，因为这一类别中的大多数榜单对此都含糊其辞。我们无法获得这里所有供应商的凭据，因此本指南并不声称对这十个服务器都进行了完整的端到端测试。下方的每个配置块都取自供应商自己的文档或代码库，每个工具数量都是文档中记录的数量，而不是运行时的 tools/list 结果；如果某个供应商完全没有发布 Codex 使用说明，我们也会明确指出。

十大服务器概览

2026 年 Codex 中的 MCP 支持究竟是什么样

请从这里开始，因为目前在该主题下排名靠前的大量指南，描述的都是自 2025 年以来就已不存在的 Codex 版本。你会反复看到一种说法：Codex 只支持 stdio，无法连接远程 MCP 服务器。这个说法只正确了大约五周。Codex 0.44.0 于 2025 年 10 月 3 日加入了 Streamable HTTP 支持，而最初用于限制此功能的 experimental_use_rmcp_client 标志也在当年 12 月发布的 0.77.0 中被彻底删除。任何仍要求你设置该标志的文章，描述的都是一个不会产生任何效果的操作，而且一些供应商的文档页面也仍未跟上变化。

如今 Codex 支持 stdio 和 Streamable HTTP，并支持 bearer token、完整的 MCP OAuth（包括 Client ID Metadata Documents 和 Dynamic Client Registration），以及面向可信第一方服务器的 ChatGPT 会话身份验证。了解它不支持什么也同样重要：Codex 不支持 SSE 传输，也不支持 WebSocket 传输。只发布 SSE 端点的服务器需要在前面加一层 stdio 桥接，这正是从 Claude Code 教程复制的配置在 Codex 中失败的最常见原因。

服务器配置位于 ~/.codex/config.toml 的 [mcp_servers.<name>] 下，或者放在项目级 .codex/config.toml 中，而 Codex 只会在受信任的项目中读取后者。同一个文件供 CLI、IDE 扩展和 ChatGPT 桌面应用使用。传输方式由配置推断，而不是显式声明：为服务器提供 command它就通过 stdio 运行；提供 url它就通过 HTTP 运行。无需设置 type 字段。

# stdio
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

# remote HTTP, token from the environment
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

你也可以通过 CLI 完成同样的操作，无需手动编辑 TOML。codex mcp add <name> -- <command> 用于注册 stdio 服务器codex mcp add <name> --url <url> 用于注册远程服务器codex mcp login <name> 用于运行 OAuth 流程。在会话中/mcp 会列出实际建立连接的服务器；当某个服务器似乎毫无反应时，这是你首先应该检查的内容。

你添加的每个服务器在工作之前都会产生开销

这正是高效 Codex 配置与缓慢配置之间的区别，但其他榜单几乎完全没有提到这一点。每当会话打开时，Codex 都会启动所有已启用的 MCP 服务器，无论模型是否会调用其中任何工具。2026 年 9 月提交的一条 OpenAI Issue 说得很直白：打开本地会话时，Codex 会初始化并启动所有已启用的 MCP 服务器，即使根本不会使用其中任何服务器的工具。十个服务器意味着每次会话启动时都要创建十个进程或执行十次握手，而且每个服务器的工具定义都会在整个会话期间占用上下文。

工具数量让计算结果一目了然。官方 GitHub 服务器记录了大约 88 个工具，Playwright 约 71 个，Chrome DevTools 57 个，Notion 35 个。将这四个服务器一起安装后，你还没写下提示词，模型就已经需要从大约 250 个工具定义中进行选择。Codex 提供了三个大多数指南从未提及的控制手段，而它们决定了一个服务器究竟实用还是代价高昂。

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
# trim the surface to the toolsets you actually use
enabled_tools = ["search_code", "get_pull_request", "list_issues"]
# reads run unattended, writes stop and ask
default_tools_approval_mode = "writes"
# a chatty tool cannot blow up the context window
[mcp_servers.github.tools.search_code]
output_token_limit = 25000

enabled_tools 是允许列表disabled_tools 是在它之后应用的拒绝列表。default_tools_approval_mode 接受 auto、prompt、writes 或 approve而 writes 才是大多数人真正需要的设置：只读工具可以自动运行，任何会更改状态的操作则会暂停并请求批准。tools.<tool>.output_token_limit 用于限制单个工具可返回的内容量。Figma 自己的文档记录了一次返回超过 351,000 个 token 的设计上下文调用；Claude Code 通过环境变量应对这种情况，而 Codex 则在这里按工具进行配置。

在这些设置发挥作用之前，两个默认值就可能先给你带来麻烦。Codex 只允许服务器使用十秒启动，每次工具调用则限制为六十秒。通过 npx 或 uvx 安装的服务器在冷缓存状态下通常需要更长时间，而且失败时不会出现明显错误：会话只会报告从某个服务器汇总到零个工具，然后继续运行。2025 年 11 月，一名开发者在 Windows 上尝试 Serena、Context7 和 Playwright 后，在 r/codex 准确描述了这一体验：安装指南看起来像是只需打开 config.toml、添加一段配置，然后一切就能正常工作，这会让你以为自己漏掉了某个基础步骤。通常你漏掉的只有 startup_timeout_sec。

Codex 沙箱未覆盖的范围

Codex 提供沙箱和网络允许列表，因此人们很容易以为它们也适用于你连接的服务器。事实并非如此。配置参考文档在多处明确说明：网络代理功能不会过滤网络搜索、应用、MCP 或其他托管工具，而实验性网络域名列表也不会限制网络搜索、应用或 MCP 服务器。域名允许列表限制的是智能体自身的 shell 可以访问哪些内容，并不限制 MCP 服务器代表智能体访问哪些内容。

这并不是反对 MCP 的理由，而是提醒你应把每个服务器都视为拥有独立凭据和独立影响范围的组件。这也正是为什么上文的审批和允许列表设置在 Codex 中比在其他地方更重要。出于同样的原因，两个广受推荐的服务器被放在本指南末尾的“不要安装”部分，而不是排名之中。

1. Bright Data MCP：不受封锁地访问实时网络

Codex 已经可以读取 URL，对于不受保护的文档页面来说，这已经足够。真正的缺口出现在大多数商业任务实际面对的网站上。零售商、交易市场、招聘网站和社交平台向自动化客户端提供的页面与向浏览器提供的页面不同，而且这种失败很少表现为明确的错误。页面会正常返回、可以解析，却包含错误的内容；对于会信心十足地陈述结果的智能体来说，这是最糟糕的情况。

Bright Data MCP 将整套网络数据技术栈整合到一个端点之后：跨多个引擎搜索、从受机器人管理机制保护的页面抓取并返回干净的 Markdown、从一百多个平台提取结构化数据，以及在页面必须通过交互才能获取内容时执行浏览器自动化。它总共提供 69 个工具，是值得花五分钟用 enabled_tools 进行精简的服务器之一。每个 Bright Data 账户每月都可免费使用 5,000 次请求，且无需信用卡，足以让你通过真实任务对其进行充分评估。

[mcp_servers.brightdata]
url = "https://mcp.brightdata.com/mcp?pro=1"
bearer_token_env_var = "BRIGHTDATA_API_KEY"
startup_timeout_sec = 20
tool_timeout_sec = 120
default_tools_approval_mode = "auto"

其中两个设置是有意这样配置的。抓取受防护的页面可能需要比 Codex 默认的六十秒更长，因此提高了 tool_timeout_sec。此外，这里的每个工具都是对公共网络执行读取，而不是向你的系统写入内容，因此使用 auto 审批是安全的，并且可以消除每次调用都要确认的摩擦，避免浏览器类服务器用起来令人疲惫。使用托管服务器时无需安装任何内容；如果你更愿意通过 stdio 在本地运行，对应的软件包是 @brightdata/mcp。

如果你想查看这项配置的更详细版本，包括如何针对一个真实任务执行完整的端到端流程，请参阅我们的将 Codex 连接到 Bright Data指南。

2. Context7：与你安装版本匹配的文档

编码智能体浪费整个下午最常见的方式，就是信心十足地使用一个在两个次要版本之前就已更名的 API。Context7 会将库解析到特定版本并返回相应文档，而且整个过程只使用两个工具。在其他选项需要 88 个工具的榜单上，这种比例本身就足以说明一切。它是本榜单中开销最低却依然实用的服务器，而且应该第一个添加。

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

它可以匿名运行；使用 API 密钥则可提高速率限制，并享有每月 1,000 次调用的免费套餐。需要如实说明的是，它的质量会因库而异：开发者论坛中的批评指出，对于不太热门的软件包，它会反复返回同一小段单薄的 Markdown。对于广泛使用的框架，它提供的信息通常比模型的训练截止时间更可靠，而这才是关键用例。

3. GitHub MCP 服务器：工作的另一半

Codex 已经很擅长编辑磁盘上的代码库，但它看不到代码周围的一切：失败的 Actions 运行、解释某个函数为何显得奇怪的评审评论，以及描述实际需求的关联 Issue。官方 GitHub 服务器弥补了这个缺口，也是本榜单中真正需要管理工具预算的服务器：它在 22 个工具集中提供大约 88 个工具。

GitHub 提供了相应的控制方式：使用 --toolsets 或 GITHUB_TOOLSETS 环境变量仅加载所需的工具组，使用 --tools 单独选择工具，并使用 --read-only 彻底移除写入权限。请从只读模式开始。Invariant Labs 已演示过一条从公共 Issue 注入提示词并影响私有代码库的路径；虽然 GitHub 已提供缓解措施，但其文档也谨慎指出，锁定模式并不是授权边界。另一点也值得了解：许多开发者发现 gh CLI 能以更低成本覆盖相同需求，因为 Codex 本来就可以运行 shell 命令。

4. Chrome DevTools MCP：解释页面为何损坏，而不只是它能做什么

这个服务器出现在 OpenAI 自己的 Codex 文档中，却几乎未出现在其他地方，因此它是本榜单中最被低估的服务器。你需要正确理解它与 Playwright 的区别，因为二者并不是竞争关系。Playwright 用于操控应用：点击这里、填写那里、断言另一项结果。Chrome DevTools MCP 则用于解释应用：性能跟踪、映射到源代码的控制台错误、网络瀑布图，以及用于排查内存问题的十三个堆检查工具。当 Codex 编写的代码可以运行但速度缓慢时，这个服务器会告诉它原因。

它的文档列出了 57 个工具，而 --slim 可以大幅减少这一数量。顾名思义，它仅支持 Chrome。此外，使用情况统计信息默认会发送给 Google，因此如果你的环境对此有要求，请添加 --no-usage-statistics。

[mcp_servers.chrome_devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--slim", "--isolated", "--no-usage-statistics"]
startup_timeout_sec = 30

在实际使用中--isolated 标志并非可选项。浏览器操控服务器在 Codex 下会因浏览器配置文件已被占用而失败，即使已授予完整文件系统访问权限，也仍会发生这种情况。解决方法是让每个会话使用一个一次性配置文件；出于同样的原因，这也适用于下文的 Playwright。

5. Serena：使用符号级编辑，而不是文本搜索

Serena 将语言服务器置于 MCP 之后，使智能体能够处理符号而不是字符串。查找此函数的所有引用、在整个项目中重命名此类、只读取此方法的主体而不是整个文件。在大型代码库中，这与 grep 相比属于完全不同层次的操作，而且达到相同结果所消耗的 token 要少得多。

它之所以能进入本榜单，还有一个与 Codex 特别相关的原因：Serena 提供了 --context=codex 模式，可以禁用那些与 Codex 现有能力重复的自有工具。这正是本指南一直强调的上下文整洁性，而且由供应商直接完成，无需交给你处理。

[mcp_servers.serena]
command = "uvx"
args = ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "codex"]
startup_timeout_sec = 60

这里特意设置了较长的超时时间。Serena 会在首次运行时为项目建立索引，因此它最容易触发默认的十秒超时限制。

6. Sentry：了解生产环境中究竟发生了什么故障

将堆栈跟踪粘贴到提示词中是可行的，但让智能体自行获取 Issue，并连同版本、面包屑和发生频率一起读取，效果会更好，而且你也不再是流程中的瓶颈。Sentry 的远程服务器使用带 OAuth 的普通 Streamable HTTP，因此 codex mcp login sentry 就是全部配置。

这里需要澄清一点，因为其他榜单给人的暗示并不准确：Sentry 文档为 Claude Code、Cursor 和 VS Code 提供了配置标签页，但没有 Codex 标签页。OpenAI 在 Codex 文档中推荐了它，而且 Codex 完全支持其传输方式，因此它确实可用——但 Sentry 没有人编写过 Codex 使用说明，你不应期待直接复制粘贴即可完成配置。将端点限定为 /mcp/{org}/{project} 可以隐藏发现工具，并缩小暴露面。

7. Postgres MCP Pro：不只是连接，还能分析查询计划

大多数数据库 MCP 服务器只是让智能体能够运行 SQL，而这个服务器让智能体能够理解和推理 SQL。它可以解释查询计划，对照 pg_stat_statements 分析工作负载以找出真正产生高成本的查询，还能模拟假设性索引，让智能体在你实际创建索引之前先测试想法。它通过九个工具完成这些工作，而且由于通过 stdio 运行，因此避开了本榜单中远程 OAuth 的所有潜在故障模式。

这里有两个需要如实说明的限制。维护者尚未发布 Codex 使用说明——一个相关请求自 2026 年 1 月起一直无人回应——不过你可以轻松自行编写 stdio 配置块。此外，在将它连接到任何重要数据库之前，请先通过 --access-mode=restricted 将其连接到副本。

8. Playwright：操控应用

Playwright MCP 通过无障碍树而不是像素来操控浏览器，因此它比基于截图的自动化更具确定性，并支持 Chromium、Firefox 和 WebKit。对于端到端测试和复现已报告的错误，它是显而易见的选择。

它之所以只排在第八位，是因为一个不同寻常的信号：Microsoft 自己的 README 现在建议编码智能体不要使用 MCP 服务器，转而推荐 token 效率更高、更适合高吞吐量智能体的 Playwright CLI 和技能，并将 MCP 定位于专门的智能体循环。当供应商亲自告诉你，其服务器并不适合你的用例时，这一点就应该反映在排名中。请添加 --isolated并准备应对审批摩擦：一个获得大量社区支持的未解决 Issue 报告称，即使设置了 approval_policy = "never"每次调用仍会要求确认，而服务器上的 default_tools_approval_mode = "auto" 可以解决这一问题。

9. Figma：设计上下文，而不是截图

将 PNG 交给智能体并要求它制作组件，只能得到大致正确的结果。Figma 服务器则会向它提供变量、token、布局约束和组件结构，输出结果因而不再只是近似。它通过带 OAuth 的远程 HTTP 提供 29 个文档中记录的工具。

这些限制确实存在，值得你在依赖它进行规划之前检查。你需要 Dev 或 Full 席位；View 席位每月只能调用工具 20 次。Figma 将连接限制为其自有目录中的客户端，Codex 目前位于该列表中，但它终究受列表约束。此外，这也是最需要设置 output_token_limit 的服务器——Figma 文档记录过单次设计上下文响应超过 351,000 个 token。

10. Linear：无需复制粘贴即可获取工单

只需一行配置即可消除一项虽小却持续存在的负担：先运行 codex mcp add linear --url https://mcp.linear.app/mcp然后运行 codex mcp login linear。智能体可以直接读取 Issue、验收标准和评论线程，并在完成工作后更新工单状态。

请注意，这与 Linear 的第一方 Codex 集成并不相同，后者的工作方向正好相反——在 Issue 中提及 Codex，以派发云端任务。MCP 服务器用于在 CLI 或 IDE 扩展中执行本地工作。如果你看到 Linear 自己的文档提到 experimental_use_rmcp_client 标志，请忽略它；该标志自 2025 年 12 月起就已不存在。

不要安装的服务器

这三个服务器出现在大多数同类榜单中。其中两个存在安全问题，另一个则纯属重复；将它们排除在外不会削弱你的 Codex 配置，反而会让它变得更好。

• Filesystem MCP。 Codex 已经拥有受其自身审批系统管理的原生文件工具。添加此服务器会重复这些功能，同时将文件访问移入该系统之外的进程，因此你获得的监督反而更少。它还曾出现过沙箱逃逸漏洞，包括 CVE-2025-53109 和 CVE-2025-53110；你绝不会希望读取磁盘的组件存在这类漏洞。
• Slack。 官方服务器不接受 Dynamic Client Registration，并要求使用目录中发布的或内部 Slack 应用，这实际上排除了 Codex CLI。旧的 npm 软件包已弃用，而且带有数据外泄安全公告。广受欢迎的社区替代方案使用浏览器会话 Cookie 进行身份验证，这很可能违反你的工作区政策。
• 社区版 Atlassian 服务器。 它存在 CVE-2026-27825，属于可导致远程代码执行的任意文件写入漏洞，严重性评分为 9.1，此外还有一个独立的 SSRF 问题。Atlassian 已提供官方 Rovo 服务器，而它不存在这些问题。

完成连接并检查是否成功

请一次添加一个服务器，并在添加下一个之前确认其运行正常，因为启动失败通常不会产生明显提示。在会话中运行 /mcp查看实际连接了哪些服务器；如果某个服务器已配置却未出现在该列表中，说明它加载失败，而不是已经成功加载。如果服务器缺失，请首先提高 startup_timeout_sec因为十秒不足以完成冷缓存状态下的 npx 或 uvx 下载。如果工具已经出现，但 Codex 从不调用它们，这是一种已知行为，并不代表配置损坏：在提示词中明确提及一次服务器或工具名称，Codex 就会开始尝试使用它。

还有两点经常让人浪费整个下午。项目级 .codex/config.toml 只会在受信任的项目中被读取，因此在一个目录中有效的配置，可能在另一个目录中悄无声息地不起作用。此外，如果你通过插件清单而不是 config.toml 配置服务器，其中的 OAuth 字段使用 camelCase，而 config.toml 中的所有字段都使用 snake_case。

常见问题

Codex 是否支持远程 MCP 服务器？

支持。Streamable HTTP 于 2025 年 10 月 3 日随 Codex 0.44.0 发布，并支持 bearer token 和完整 OAuth，包括 CIMD 与 Dynamic Client Registration。曾用于限制此功能的 experimental_use_rmcp_client 标志已在 2025 年 12 月的 0.77.0 中被移除，因此任何仍要求你设置该标志的指南都已经过时。Codex 不支持 SSE 或 WebSocket 传输。

我应该在 Codex 中安装多少个 MCP 服务器？

应该比你想安装的更少。每次会话打开时，Codex 都会启动所有已启用的服务器，无论是否会使用其中的工具，而且每个服务器的工具定义都会在整个会话期间消耗上下文。四个经过工具列表精简的服务器，会胜过十个保持默认配置的服务器。使用 enabled_tools 缩小每个服务器的工具范围，并使用 enabled = false 暂停那些你只偶尔需要的服务器。

为什么我的 MCP 服务器在 Codex 中没有显示工具？

几乎总是因为十秒的启动超时限制。通过 npx 或 uvx 安装的服务器在冷缓存状态下可能需要更长时间，而 Codex 只会报告汇总到零个工具，而不是显示错误。将 startup_timeout_sec 提高到 30 或 60，然后重试。如果是浏览器类服务器，请添加 --isolated；它可以解决即使授予完整访问权限也会发生的配置文件锁定故障。

Codex 沙箱会限制 MCP 服务器可以访问的内容吗？

不会，而且这一点经常被误解。Codex 的配置参考文档指出，其网络代理不会过滤 MCP 或其他托管工具，实验性网络域名列表也不会限制 MCP 服务器。域名允许列表管理的是智能体自身的 shell，而不是连接的服务器代表它获取的内容。请将每个服务器都视为拥有独立凭据和独立影响范围的组件。

Codex 能否抓取屏蔽机器人的网站？

仅凭自身能力无法做到。Codex 可以获取 URL，但启用了机器人管理机制的网站会向自动化客户端返回不同的页面，而且失败通常是静默发生的，而不是显示错误。Bright Data MCP 通过单一端点提供解锁、多引擎搜索和来自一百多个平台的结构化提取功能，每月可免费使用 5,000 次请求，且无需信用卡。