在 Codex 中接入 Context7 MCP

Context7 用来查询第三方库、框架和 SDK 的当前文档。我会在 API、配置项或迁移方法可能变化时使用它；普通重构、业务逻辑排错和仓库内代码查询不需要先绕到外部文档。

配置远程 MCP

在 ~/.codex/config.toml 中添加：

[mcp_servers.context7]
url = "https://mcp.context7.com/mcp"

使用 API Key 时，通过请求头传递。真实值不要写进文章、仓库或截图：

[mcp_servers.context7]
url = "https://mcp.context7.com/mcp"

[mcp_servers.context7.http_headers]
Authorization = "Bearer YOUR_CONTEXT7_API_KEY"

保存后新开 Codex 会话，再检查：

codex mcp list

在交互界面中也可以用 /mcp 查看当前任务实际加载的服务。配置文件里有条目，不等于当前会话已经重载。

两个核心工具

Context7 MCP 主要提供：

• resolve-library-id：把库名解析为 Context7 的库 ID。
• query-docs：针对具体库 ID 和问题取回文档。

已经知道准确库 ID 时，直接指定它可以少一次匹配。例如查询 Next.js 时，问题里同时写清版本、功能和期望配置，比只写“查一下 Next.js”更容易得到可用结果。

不要把 MCP 和 Skill 混在一起

Context7 目前支持两种工作方式：

• MCP 给 Codex 注册原生文档查询工具。
• CLI 与 Skill 通过 ctx7 命令和工作说明完成同类查询，不要求启用 MCP。

documentation-lookup Skill 只是告诉 Agent 何时查、怎样缩小问题，它不会凭空注册 MCP 服务。安装和使用记录统一放在我如何使用 Agent Skill中。

我的使用边界

适合调用 Context7 的情况：

• 框架或 SDK 的当前配置；
• 跨版本迁移；
• 已知 API 名称但参数可能变化；
• 官方文档分散，且需要针对一个具体问题取片段。

不适合的情况：

• 项目代码已经给出答案；
• 只需要运行 rg、类型检查或测试；
• 问题与第三方库无关；
• 用户已经给出明确资料并要求以它为准。

我曾把 Context7 写成全局强制前置步骤，结果库相关问题几乎都会触发查询，工具输出又持续占用上下文。现在只在事实确实会变化、或者用户明确要求时使用。

参考资料

• Context7
• Codex MCP