02 · 用 MCP 接上你的工具

它解决的问题

Codex 能看到你的仓库，但看不到你的 Jira、你的 Sentry、你的 Figma、你公司那套内部服务。 每次都靠你复制粘贴，等于让它隔着一层玻璃干活。

MCP（模型上下文协议）就是把这层玻璃打开——给它一组能调的工具， 让它自己去查工单、翻日志、读设计稿。

两种服务器形态

STDIO 服务器：作为本地进程跑（用一条命令启动）。支持环境变量。 大部分开源 MCP 服务器是这种。

Streamable HTTP 服务器：通过地址访问。支持：

• Bearer Token 身份验证
• OAuth 身份验证，包括客户端 ID 元数据文档（CIMD）和动态客户端注册（DCR）
• 对受信任的第一方服务器，可以用当前 ChatGPT 会话做身份验证

另外 Codex 会读取服务器初始化时返回的 instructions 字段， 当成适用于整个服务器的指引。如果你自己维护 MCP 服务器， 前 512 个字符要能独立看懂——那是 Codex 决定怎么用这个服务器时最先看到的东西。

三种配置方式

配置都存在 config.toml 里，默认 ~/.codex/config.toml； 也可以放项目级的 .codex/config.toml（仅限受信任的项目）。 桌面应用、CLI 和 IDE 扩展共享这份配置，配一次三边都能用。

CLI

codex mcp add <server-name> --env VAR1=VALUE1 -- <stdio 启动命令>

比如加 Context7：

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

其他常用命令：

codex mcp list                    # 看已配置的服务器
codex mcp login <server-name>     # OAuth 服务器登录
codex mcp --help                  # 全部命令

在 TUI 里输入 /mcp 看当前活动的服务器。

桌面应用 / IDE 扩展

桌面应用：设置 → MCP 服务器 → 添加服务器，填名字、选 STDIO 或 Streamable HTTP、 给命令或 URL，保存后重新启动。 IDE 扩展：齿轮图标菜单 → MCP 服务器，流程一样，最后重新启动扩展。

列表里会标出哪些已启用、哪些需要 OAuth。需要登录时点身份验证。

直接写 config.toml

要更细的控制就自己写。每个服务器一个 [mcp_servers.<name>] 表。

STDIO 的选项：

选项	说明
command	必需，启动服务器的命令
args	传给服务器的参数
env	给服务器设的环境变量
env_vars	允许转发的环境变量
cwd	启动时的工作目录
experimental_environment	设为 remote 时，若有远程执行器环境就通过它启动

env_vars 可以是普通变量名，也可以指定来源：

env_vars = ["LOCAL_TOKEN", { name = "REMOTE_TOKEN", source = "remote" }]

字符串条目和 source = "local" 从 Codex 本地环境取值； source = "remote" 从远程执行器环境取值，需要远程 MCP stdio。

Streamable HTTP 的选项：

选项	说明
url	必需，服务器地址
auth	oauth（默认，用已存的 MCP OAuth 凭据）或 chatgpt（对受信任的第一方源用当前 ChatGPT 会话，失败回退到 OAuth）
bearer_token_env_var	存 Bearer Token 的环境变量名，会放进 Authorization
http_headers	标头名 → 静态值
env_http_headers	标头名 → 环境变量名（值从环境取）
http_headers_helper	本地命令，输出 {"X-Auth": "..."} 这样的 JSON

http_headers_helper 是接内部系统时最有用的一个： 公司的令牌通常有有效期，静态标头写死了会过期，让 helper 每次现取就行。

几个现成的服务器

• OpenAI 文档 MCP：搜索和阅读 OpenAI 开发者文档
• Context7：连到各种库的最新文档
• Playwright：控制和检查浏览器
• Chrome 开发者工具
• Sentry：访问线上日志
• GitHub：管 PR 和议题这些 git 管不到的东西
• Figma：本地 / 远程

安全上要想清楚的三件事

一、STDIO 服务器是在你机器上跑的进程。 codex mcp add x -- npx -y some-package 等于同意在本地跑一个第三方包。装之前看一眼这个包是谁维护的。

二、项目级配置只在受信任的项目里加载。 这个限制是有道理的： .codex/config.toml 是跟着仓库来的，一个你 clone 下来的陌生仓库不该有权在你机器上启动进程。 别为了图方便随手把项目标成受信任。

三、MCP 工具返回的内容是数据，不是指令。 工单标题、日志内容、 网页正文都可能带着「忽略之前的指令」这类东西。 Codex 的审批机制在这里就是最后一道闸：如果一个动作会产生副作用， 它应该停下来问你——04 篇里 approval_policy 的 mcp_elicitations 那一档管的就是这个。

顺带一提，声明了破坏性标注的应用/MCP 工具调用始终需要审批； 但如果该工具同时声明了读取标注，则以读取标注为准。

相关官方文档

• 模型上下文协议
• 配置参考资料
• MCP 服务器（把 Codex 自己作为 MCP 服务器暴露出去）
• 智能体审批与安全