Context7：把最新库文档直接塞进 LLM 提示词的 MCP 工具

它治的是幻觉 API，不是代码质量

Context7 解决的是一个具体且痛的问题：大语言模型的训练数据有截止日期，而库的 API 在持续变化。你让代理写一个 Next.js 中间件，它可能基于一年前的语法生成，甚至编造一个不存在的函数。Context7 的做法是把最新文档和版本化示例直接塞进提示词，让代理基于当前源码回答。它不改善代码逻辑，不优化架构，只负责让代理拿到对的参考资料。目标用户很明确：用 AI 编码编辑器写业务代码、但不想每次手动查文档的开发者。

两种模式，一条命令装好

Context7 提供两套接入方式。CLI + Skills 模式安装一个技能，让代理在需要时调用 ctx7 命令去取文档，不依赖 MCP 协议。MCP 模式则注册一个 Context7 MCP 服务器，代理原生调用两个工具。安装只需一条命令：npx ctx7 setup，它会走 OAuth 认证、生成 API key，并自动装好对应技能。你可以用 --cursor、--claude 或 --opencode 指定目标代理。想移除就运行 npx ctx7 remove。手动配置也简单，MCP 服务器地址是 https://mcp.context7.com/mcp，通过 Authorization: Bearer 头传 API key。整个安装过程对非技术用户也够友好，但对熟悉 MCP 的人来说，手动配置反而更透明。

两个 MCP 工具，职责分得很清楚

MCP 模式下只有两个工具。resolve-library-id 接收一个模糊的库名和用户问题，返回 Context7 兼容的库 ID，比如把 Supabase 解析成 /supabase/supabase。query-docs 则用这个 ID 和具体问题去取相关文档片段。两个工具都要求 query 参数，因为 Context7 用问题本身来排序文档相关性。这个设计意味着它不只是按库名抓取，而是按任务匹配内容。但这也带来一个约束：如果 query 写得含糊，返回的文档可能不聚焦。CLI 侧对应的是 ctx7 library 和 ctx7 docs 两个命令，行为与 MCP 工具一致。工具数量少是优点，代理不会在复杂工具集里迷路。

用斜杠语法和版本号，跳过匹配步骤

Context7 支持两种提示词技巧来提升精确度。一是用 use library /supabase/supabase 这样的斜杠语法，直接指定库 ID，跳过库名匹配那一步。二是直接提版本，比如「How do I set up Next.js 14 middleware?」，它会自动匹配对应版本的文档。这两个技巧都写进了 README，说明匹配步骤确实存在误判风险。如果你不指定，它得从你的问题里猜库名和版本，猜错的概率不是零。对常用库，建议总是带上库 ID，这是文档里明确推荐的做法。

安装后的规则配置，决定它是否真的生效

ctx7 setup 会装一个技能，让代理在遇到库相关问题时不需你显式要求就自动触发。但如果你不想用技能，也可以手动加规则。Cursor 在 Settings > Rules 里加，Claude Code 写在 CLAUDE.md 里，其他代理有对应位置。README 给的示例规则是：「Always use Context7 when I need library/API documentation...」。这条规则写得很宽泛，实际效果取决于代理是否严格遵守。如果你不配规则，就得每次在提示词里手动加 use context7，体验会打折扣。所以安装后第一件事应该是确认规则确实生效，否则这个工具很容易被忽略。

一个明确的边界：后端是私有的

仓库的免责声明写得很直白：这个仓库只托管 MCP 服务器的源码，API 后端、解析引擎和爬虫引擎都是私有的，不在仓库里。这意味着你无法自己跑一个完整的 Context7 服务，也不能扩展文档源。所有文档都来自官方维护的索引，你只能通过提交表单申请添加新库。这对企业用户是个重要考量：如果你需要内部库的文档，Context7 帮不上忙。另外，文档质量由各个库的维护者负责，Context7 不保证准确性。它把质量责任推给了上游，这在实际使用中意味着你仍然需要对代理的输出做抽查。

和替代方案比，差别在文档来源

Context7 的替代品有两类。一类是直接把官方文档作为上下文喂给代理，比如你手动把某库的 docs 文件夹拖进 Cursor 的上下文，或者用 rag 工具索引文档站点。这种做法的好处是你能控制来源，坏处是每次更新都要重新索引，而且没有版本感知。另一类是让代理联网搜索，比如 Cursor 的 Web Search 或 Perplexity 这类工具，它们能拿到最新页面，但搜索结果是整页内容，噪音大，而且不一定能按版本过滤。Context7 的差异点在于它维护了库 ID 和版本的映射，能精确返回某个版本的文档片段。代价是它只覆盖索引里的库，而联网搜索覆盖所有公开网页。如果你的库不在索引里，Context7 就是错的工具。

维护成本和许可证，两个现实问题

Context7 的维护成本主要在两边。客户端这边，npm 包更新频繁，最近一次发布是 2026 年 8 月的 @upstash/context7-mcp@4.0.4，说明迭代速度不慢，你需要偶尔升级 CLI 和 MCP 包来跟进工具变化。服务端那边，你什么都不用管，因为后端是托管的，但这也意味着你依赖 Upstash 的可用性，如果服务挂了，你的代理就失去文档源。许可证是 MIT，可以自由使用和修改，但注意 MCP 服务器源码虽开源，核心逻辑并不开源，所以修改空间有限。API key 是免费的，但速率限制是个未知数，README 只说「higher rate limits」，具体数字要看 dashboard。对个人开发者，免费额度应该够用，但团队高频使用前最好确认限制。

编辑结论

Context7 适合那些频繁依赖编码代理处理第三方库集成的开发者，尤其是使用 Cursor、Claude Code 或 OpenCode 的用户，它能显著减少幻觉 API 和过时示例。不适合需要完全离线工作、对文档来源有严格信任要求，或者只用一个固定库且文档已烂熟于心的团队。采用前先验证三件事：你的代理是否支持 MCP 或技能调用；你常用的库是否在 Context7 索引中，可通过 ctx7 library 命令查询；免费 API key 的速率限制是否满足你的日常使用频率。仓库明确说明解析引擎和爬虫引擎是私有的，这意味着你无法自行扩展文档源，只能依赖官方索引。如果你接受这个边界，Context7 是目前少有的、把版本化文档直接注入代理上下文的实用方案。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes