Context7 MCP 规则文件解析让 AI 编码 Agent 自动获取最新库文档的 resolve-library-id 与 query-docs 工作流【免费下载链接】context7Context7 Platform -- Up-to-date code documentation for LLMs and AI code editors项目地址: https://gitcode.com/gh_mirrors/co/context7规则文件 是 Context7 提供给 AI 编码 AgentClaude Code、Cursor、Codex 等的一条使用守则当用户询问任何库、框架、SDK、API、CLI 工具或云服务时Agent 必须优先调用 Context7 MCP 的resolve-library-id和query-docs两个工具拉取实时文档而不是依赖可能过时的训练数据。读完本文你将理解这条规则的适用边界、四步查文档流程、库 ID 的选取标准以及它在 MCP 服务端源码 中的落地方式——工具描述、参数别名容错、调用次数限制都与你写进 Agent 配置的内容一一对应。一、这条规则解决什么问题规则文件的第一段明确了触发条件原文要点如下触发场景用户询问库、框架、SDK、API、CLI 工具或云服务时都要用 Context7 MCP 获取当前文档——包括 React、Next.js、Prisma、Express、Tailwind、Django、Spring Boot 这类“人人都熟”的知名库。具体涵盖 API 语法、配置、版本迁移、库相关的调试、安装配置说明和 CLI 工具用法为什么不能靠模型记忆即使 Agent 自认为知道答案也应查询——训练数据可能未反映近期变更优先级对于库文档类问题优先于网络搜索。规则同时划定了负面清单以下场景不应使用重构refactoring、从零写脚本、调试业务逻辑、代码审查以及通用编程概念。这条边界与 MCP 服务端内置的 instructions 完全一致。在 MCP 服务器入口 中服务器注册时携带的 instructions 字段内容与规则文件开头两段几乎逐字相同——也就是说即使 Agent 没有加载规则文件MCP 协议握手时也会从服务端收到同样的“何时该用、何时不该用”的指引。规则文件相当于把这份指引前置到 Agent 的配置层让 Agent 在决定要不要调工具之前就完成判断。规则文件还通过 ctx7 setup 分发CLI 以 MCP 模式配置 Agent 时会在 Agent 的 rules 目录写入这条规则文件、在 skills 目录写入 context7-mcp skill并写入 MCP 服务器配置.mcp.json/.cursor/mcp.json/.opencode.json等实现“一条命令完成规则 技能 服务器”的完整接线。二、四步工作流程从库名到可引用的文档规则文件的 Steps 部分定义了严格的调用顺序每一步都有明确的输入输出步骤 1总是先调resolve-library-id除非用户直接提供了/org/project格式的精确库 ID否则第一步必须是用库名 想在文档中查什么两个参数调用resolve-library-id。从服务端源码看工具注册处该工具的输入只有两个字段且都带强约束的描述文本参数说明服务端 schema 定义query想在库文档中查什么。用于按“用户想完成的事”给库结果排序禁止包含 API 密钥、密码、凭据、个人数据或专有代码等敏感信息libraryName要搜索的库名。要求使用带正确标点的官方名称——例如写Next.js而不是nextjsCustomer.io而不是customerioThree.js而不是threejs服务端还有一段值得注意的容错实现LLM 客户端经常“照抄”工具描述里的措辞而不是 schema 的字面键名比如传userQuery或question这类幻觉参数会先被 Zod 校验拦下。因此源码在 schema 外层包了一层 参数别名重写query的别名userQuery/question以及query-docs中libraryId的别名context7CompatibleLibraryID/libraryID/libraryName都会在验证前被静默映射回规范键名。这是“规则文档教 Agent 规范调用”与“服务端兜底非法调用”的双层防线。步骤 2按五个维度挑选最佳匹配规则要求从返回结果中按以下优先级选出 ID 格式为/org/project的最佳库精确名称匹配exact name match描述相关性description relevance代码片段数量code snippet count——越多说明文档覆盖越全来源信誉source reputationHigh/Medium 优先基准分benchmark score越高越好。这五个维度直接来自服务端工具描述中的“Selection Process”工具描述原文。每个候选库的返回字段在 ai-sdk 版工具文档 中给出了完整示例- Title: React Documentation - Context7-compatible library ID: /reactjs/react.dev - Description: The library for web and native user interfaces - Code Snippets: 1250 - Source Reputation: High - Benchmark Score: 98 - Versions: 19.0.0, 18.3.1, 18.2.0 ---------- - Title: React Native - Context7-compatible library ID: /facebook/react-native - Description: A framework for building native applications using React - Code Snippets: 890 - Source Reputation: High - Benchmark Score: 95 - Versions: 0.76.0, 0.75.4规则同时给出了结果不理想时的补救策略换一种库名或改写查询再试例如用next.js而不是nextjs如果用户提到了具体版本应改用版本特定的 ID。此外服务端在工具描述末尾写死了调用预算同一个问题最多调用 3 次resolve-library-id3 次后仍找不到就采用手头最好的结果对应源码——这是对“反复试探式搜索”的明确约束。步骤 3用query-docs按单一概念查询选定库 ID 后用query-docs传入libraryId 要在文档中查什么且查询应限定在单一概念内。规则与 queryDocs 工具文档 对此的表述一致好查询How to set up authentication with JWT in Express.js、React useEffect cleanup function examples——具体、有细节、单主题差查询太模糊auth、hooks这类单词级查询差查询太宽泛routing and auth and caching in Next.js——多主题混合。关键原则如果问题跨越多个不同概念例如路由、认证、缓存应针对同一 libraryId 分多次query-docs调用每个概念一次除非问题本身就是“这些概念如何交互”。原因是混合查询会稀释排序效果dilute ranking每个主题都只能拿到浅层结果。query-docs同样受“每个问题最多 3 次”的预算约束工具描述。版本场景下库 ID 支持/org/project/version形式如/vercel/next.js/v14.3.0-canary.87版本列表来自步骤 2 的解析结果服务端 schema 中也直接以该格式举例libraryId 字段描述。步骤 4基于拉取的文档作答最后一步只有四个字用拉取到的文档来回答。配合 context7-mcp skill 中更细化的“Step 4”要求还应做到使用当前准确信息回答、附上文档中的相关代码示例、在相关时注明库版本、多个匹配时优先官方主包而非社区分支。三、规则与配套工件的关系规则、Skill、MCP 服务器三层分工这条规则文件不是孤立的。同一个 Context7 仓库中围绕“查文档”这件事存在三层互补工件规则文件属于其中“Agent 行为约束”层工件位置作用规则文件本文主题rules/context7-mcp.md告诉 Agent 何时该用 Context7、何时不该用以及四步流程CLI 版规则rules/context7-cli.md同一套流程的无 MCP 版本用npx ctx7latest library name query和npx ctx7latest docs libraryId query替代两个 MCP 工具额外要求每问不超过 3 条命令、查询不含敏感信息、配额报错时提示ctx7 login或设置CONTEXT7_API_KEYSkillskills/context7-mcp/SKILL.md以 frontmatter 声明触发条件询问库/框架/API/代码示例时激活把四步流程展开为可执行的技能说明MCP 服务器packages/mcp/src/index.ts真正实现resolve-library-id内部调用searchLibraries与query-docs内部调用fetchLibraryContext见 lib/api.ts两者规则文件与 CLI 规则的正面清单、负面清单完全对齐区别只在“调 MCP 工具”还是“跑 CLI 命令”。选择哪一份取决于 Agent 的配置模式ctx7 setup --mcp写入 MCP 规则ctx7 setup --cli则安装引导 Agent 使用ctx7 library/ctx7 docs命令的docsskill见 CLI 文档 Setup 章节。四、落地实践认证、限制与可验证细节认证与额度规则文件本身不处理认证但整个工作流依赖额度。从源码与文档可确认的认证途径环境变量CONTEXT7_API_KEYstdio 模式下与--api-key标志二选一启动参数解析ai-sdk 工具同样在缺省时回落到该环境变量resolveLibraryId 文档匿名使用MCP 模式不带 key 时会走匿名档命中更低速率限制CLI 模式下ctx7 library/ctx7 docs免登录可用登录ctx7 login或设CONTEXT7_API_KEY可提升限额CLI 文档。工具语义标注两个工具在服务端都声明了readOnlyHint: true、destructiveHint: false、openWorldHint: true、idempotentHint: trueannotations 字段——即只读、可重复调用、访问外部世界。这对 Agent 框架意味着这两个调用可以安全地并行或重试不会产生副作用。与规则的自检对齐如果你正在维护自己的 Agent 配置可以对照以下三点验证规则是否真正生效依据均来自本仓库路径可直接核对顺序Agent 是否在没有拿到/org/project形式 ID 前就不调用query-docs——服务端query-docs的描述明确要求先 resolve对应描述规则文件第 1 步也如此规定查询质量查询是否被拆成单一概念、是否为描述性语句而非单个词——规则与 schema 描述反复强调调用预算单个问题内resolve-library-id与query-docs各自不超过 3 次——规则文件中 CLI 版显式写明MCP 版写在各工具描述里。五、小结rules/context7-mcp.md 用不到 10 行文本定义了一套完整的“文档新鲜度”保障机制触发条件任何库/框架/SDK/API/CLI/云服务问题知名库也不例外→边界重构、从零写脚本、业务逻辑调试、代码审查、通用概念除外→流程resolve-library-id 解析 → 五维度选 ID → 单概念 query-docs → 基于文档作答→约束每问题各工具至多 3 次、版本查询用/org/project/version、查询不含敏感信息。它与 MCP 服务端实现工具描述、参数别名容错、只读标注、context7-mcp skill、CLI 版规则 构成同一套语义的四种载体。理解这条规则的最佳方式是把它读成“Agent 与 Context7 之间的协议契约”规则层约束 Agent 的决策schema 层兜住 Agent 的表达误差服务端层提供实时文档——三层叠加才能把“训练数据滞后”这一根本问题转化为可执行、可验证的工程流程。【免费下载链接】context7Context7 Platform -- Up-to-date code documentation for LLMs and AI code editors项目地址: https://gitcode.com/gh_mirrors/co/context7创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Context7 MCP 规则文件解析：让 AI 编码 Agent 自动获取最新库文档的 resolve-library-id 与 query-docs 工作流
Context7 MCP 规则文件解析让 AI 编码 Agent 自动获取最新库文档的 resolve-library-id 与 query-docs 工作流【免费下载链接】context7Context7 Platform -- Up-to-date code documentation for LLMs and AI code editors项目地址: https://gitcode.com/gh_mirrors/co/context7规则文件 是 Context7 提供给 AI 编码 AgentClaude Code、Cursor、Codex 等的一条使用守则当用户询问任何库、框架、SDK、API、CLI 工具或云服务时Agent 必须优先调用 Context7 MCP 的resolve-library-id和query-docs两个工具拉取实时文档而不是依赖可能过时的训练数据。读完本文你将理解这条规则的适用边界、四步查文档流程、库 ID 的选取标准以及它在 MCP 服务端源码 中的落地方式——工具描述、参数别名容错、调用次数限制都与你写进 Agent 配置的内容一一对应。一、这条规则解决什么问题规则文件的第一段明确了触发条件原文要点如下触发场景用户询问库、框架、SDK、API、CLI 工具或云服务时都要用 Context7 MCP 获取当前文档——包括 React、Next.js、Prisma、Express、Tailwind、Django、Spring Boot 这类“人人都熟”的知名库。具体涵盖 API 语法、配置、版本迁移、库相关的调试、安装配置说明和 CLI 工具用法为什么不能靠模型记忆即使 Agent 自认为知道答案也应查询——训练数据可能未反映近期变更优先级对于库文档类问题优先于网络搜索。规则同时划定了负面清单以下场景不应使用重构refactoring、从零写脚本、调试业务逻辑、代码审查以及通用编程概念。这条边界与 MCP 服务端内置的 instructions 完全一致。在 MCP 服务器入口 中服务器注册时携带的 instructions 字段内容与规则文件开头两段几乎逐字相同——也就是说即使 Agent 没有加载规则文件MCP 协议握手时也会从服务端收到同样的“何时该用、何时不该用”的指引。规则文件相当于把这份指引前置到 Agent 的配置层让 Agent 在决定要不要调工具之前就完成判断。规则文件还通过 ctx7 setup 分发CLI 以 MCP 模式配置 Agent 时会在 Agent 的 rules 目录写入这条规则文件、在 skills 目录写入 context7-mcp skill并写入 MCP 服务器配置.mcp.json/.cursor/mcp.json/.opencode.json等实现“一条命令完成规则 技能 服务器”的完整接线。二、四步工作流程从库名到可引用的文档规则文件的 Steps 部分定义了严格的调用顺序每一步都有明确的输入输出步骤 1总是先调resolve-library-id除非用户直接提供了/org/project格式的精确库 ID否则第一步必须是用库名 想在文档中查什么两个参数调用resolve-library-id。从服务端源码看工具注册处该工具的输入只有两个字段且都带强约束的描述文本参数说明服务端 schema 定义query想在库文档中查什么。用于按“用户想完成的事”给库结果排序禁止包含 API 密钥、密码、凭据、个人数据或专有代码等敏感信息libraryName要搜索的库名。要求使用带正确标点的官方名称——例如写Next.js而不是nextjsCustomer.io而不是customerioThree.js而不是threejs服务端还有一段值得注意的容错实现LLM 客户端经常“照抄”工具描述里的措辞而不是 schema 的字面键名比如传userQuery或question这类幻觉参数会先被 Zod 校验拦下。因此源码在 schema 外层包了一层 参数别名重写query的别名userQuery/question以及query-docs中libraryId的别名context7CompatibleLibraryID/libraryID/libraryName都会在验证前被静默映射回规范键名。这是“规则文档教 Agent 规范调用”与“服务端兜底非法调用”的双层防线。步骤 2按五个维度挑选最佳匹配规则要求从返回结果中按以下优先级选出 ID 格式为/org/project的最佳库精确名称匹配exact name match描述相关性description relevance代码片段数量code snippet count——越多说明文档覆盖越全来源信誉source reputationHigh/Medium 优先基准分benchmark score越高越好。这五个维度直接来自服务端工具描述中的“Selection Process”工具描述原文。每个候选库的返回字段在 ai-sdk 版工具文档 中给出了完整示例- Title: React Documentation - Context7-compatible library ID: /reactjs/react.dev - Description: The library for web and native user interfaces - Code Snippets: 1250 - Source Reputation: High - Benchmark Score: 98 - Versions: 19.0.0, 18.3.1, 18.2.0 ---------- - Title: React Native - Context7-compatible library ID: /facebook/react-native - Description: A framework for building native applications using React - Code Snippets: 890 - Source Reputation: High - Benchmark Score: 95 - Versions: 0.76.0, 0.75.4规则同时给出了结果不理想时的补救策略换一种库名或改写查询再试例如用next.js而不是nextjs如果用户提到了具体版本应改用版本特定的 ID。此外服务端在工具描述末尾写死了调用预算同一个问题最多调用 3 次resolve-library-id3 次后仍找不到就采用手头最好的结果对应源码——这是对“反复试探式搜索”的明确约束。步骤 3用query-docs按单一概念查询选定库 ID 后用query-docs传入libraryId 要在文档中查什么且查询应限定在单一概念内。规则与 queryDocs 工具文档 对此的表述一致好查询How to set up authentication with JWT in Express.js、React useEffect cleanup function examples——具体、有细节、单主题差查询太模糊auth、hooks这类单词级查询差查询太宽泛routing and auth and caching in Next.js——多主题混合。关键原则如果问题跨越多个不同概念例如路由、认证、缓存应针对同一 libraryId 分多次query-docs调用每个概念一次除非问题本身就是“这些概念如何交互”。原因是混合查询会稀释排序效果dilute ranking每个主题都只能拿到浅层结果。query-docs同样受“每个问题最多 3 次”的预算约束工具描述。版本场景下库 ID 支持/org/project/version形式如/vercel/next.js/v14.3.0-canary.87版本列表来自步骤 2 的解析结果服务端 schema 中也直接以该格式举例libraryId 字段描述。步骤 4基于拉取的文档作答最后一步只有四个字用拉取到的文档来回答。配合 context7-mcp skill 中更细化的“Step 4”要求还应做到使用当前准确信息回答、附上文档中的相关代码示例、在相关时注明库版本、多个匹配时优先官方主包而非社区分支。三、规则与配套工件的关系规则、Skill、MCP 服务器三层分工这条规则文件不是孤立的。同一个 Context7 仓库中围绕“查文档”这件事存在三层互补工件规则文件属于其中“Agent 行为约束”层工件位置作用规则文件本文主题rules/context7-mcp.md告诉 Agent 何时该用 Context7、何时不该用以及四步流程CLI 版规则rules/context7-cli.md同一套流程的无 MCP 版本用npx ctx7latest library name query和npx ctx7latest docs libraryId query替代两个 MCP 工具额外要求每问不超过 3 条命令、查询不含敏感信息、配额报错时提示ctx7 login或设置CONTEXT7_API_KEYSkillskills/context7-mcp/SKILL.md以 frontmatter 声明触发条件询问库/框架/API/代码示例时激活把四步流程展开为可执行的技能说明MCP 服务器packages/mcp/src/index.ts真正实现resolve-library-id内部调用searchLibraries与query-docs内部调用fetchLibraryContext见 lib/api.ts两者规则文件与 CLI 规则的正面清单、负面清单完全对齐区别只在“调 MCP 工具”还是“跑 CLI 命令”。选择哪一份取决于 Agent 的配置模式ctx7 setup --mcp写入 MCP 规则ctx7 setup --cli则安装引导 Agent 使用ctx7 library/ctx7 docs命令的docsskill见 CLI 文档 Setup 章节。四、落地实践认证、限制与可验证细节认证与额度规则文件本身不处理认证但整个工作流依赖额度。从源码与文档可确认的认证途径环境变量CONTEXT7_API_KEYstdio 模式下与--api-key标志二选一启动参数解析ai-sdk 工具同样在缺省时回落到该环境变量resolveLibraryId 文档匿名使用MCP 模式不带 key 时会走匿名档命中更低速率限制CLI 模式下ctx7 library/ctx7 docs免登录可用登录ctx7 login或设CONTEXT7_API_KEY可提升限额CLI 文档。工具语义标注两个工具在服务端都声明了readOnlyHint: true、destructiveHint: false、openWorldHint: true、idempotentHint: trueannotations 字段——即只读、可重复调用、访问外部世界。这对 Agent 框架意味着这两个调用可以安全地并行或重试不会产生副作用。与规则的自检对齐如果你正在维护自己的 Agent 配置可以对照以下三点验证规则是否真正生效依据均来自本仓库路径可直接核对顺序Agent 是否在没有拿到/org/project形式 ID 前就不调用query-docs——服务端query-docs的描述明确要求先 resolve对应描述规则文件第 1 步也如此规定查询质量查询是否被拆成单一概念、是否为描述性语句而非单个词——规则与 schema 描述反复强调调用预算单个问题内resolve-library-id与query-docs各自不超过 3 次——规则文件中 CLI 版显式写明MCP 版写在各工具描述里。五、小结rules/context7-mcp.md 用不到 10 行文本定义了一套完整的“文档新鲜度”保障机制触发条件任何库/框架/SDK/API/CLI/云服务问题知名库也不例外→边界重构、从零写脚本、业务逻辑调试、代码审查、通用概念除外→流程resolve-library-id 解析 → 五维度选 ID → 单概念 query-docs → 基于文档作答→约束每问题各工具至多 3 次、版本查询用/org/project/version、查询不含敏感信息。它与 MCP 服务端实现工具描述、参数别名容错、只读标注、context7-mcp skill、CLI 版规则 构成同一套语义的四种载体。理解这条规则的最佳方式是把它读成“Agent 与 Context7 之间的协议契约”规则层约束 Agent 的决策schema 层兜住 Agent 的表达误差服务端层提供实时文档——三层叠加才能把“训练数据滞后”这一根本问题转化为可执行、可验证的工程流程。【免费下载链接】context7Context7 Platform -- Up-to-date code documentation for LLMs and AI code editors项目地址: https://gitcode.com/gh_mirrors/co/context7创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考