人工智能AI Agent工具调用【免费下载链接】specificationSpecification and documentation for the Model Context Protocol项目地址https://gitcode.com/gh_mirrors/specification2/specification点击查看免费下载本文介绍plugins/mcp-spec插件它是为 Claude Code 与 Claude Cowork 设计的一套 MCP 规范研究工具集包含/search-mcp-github跨 GitHub Issues/PR/Discussions 检索 MCP 演进决策与/draft-sep按 SEP 治理流程起草规范增强提案两个技能。读完本文你将掌握插件的安装启用方法、两个技能的工作原理与完整调用流程以及它们与仓库内seps/、docs/community/sep-guidelines.mdx、scripts/render-seps.ts等治理与自动化设施的联动关系。插件定位给 Claude 的 MCP 规范研究工具箱在 Model Context ProtocolMCP规范仓库中plugins/mcp-spec是一个面向 Claude 的插件Plugin其定位在 plugins/mcp-spec/README.md 中描述得非常直白为研究和贡献 MCP 规范提供一组可复用的 Skills。它解决的是两个非常具体的痛点检索历史决策难MCP 的规范演进散落在 GitHub 的 Issues、Pull Requests、组织级讨论和规范级讨论中靠人工翻页既慢又容易漏掉已关闭的旧讨论。起草提案流程重SEPSpecification Enhancement Proposal需要经过门槛判断、作者访谈、现状调研、模板填充、PR 编号回填等一系列规范化步骤人工操作容易遗漏。插件通过两个用户可主动调用的 Skill 把上述流程标准化、自动化。从仓库结构看插件本体非常轻量plugins/mcp-spec/ ├── README.md └── skills/ ├── draft-sep/ │ └── SKILL.md └── search-mcp-github/ └── SKILL.md每个 Skill 都是一个带 YAML frontmatter 的SKILL.md文件其中user_invocable: true声明了它们可以由用户显式触发arguments定义了入参两个 Skill 都要求一个必填的topic/idea参数。安装与启用在 Claude Code 中安装在 Claude Code 中通过 marketplace 命令安装/plugin marketplace add modelcontextprotocol/modelcontextprotocol在 Claude Cowork 中安装在 Claude Cowork 中按以下路径操作Customize Browse Plugins Personal Plus Button Add marketplace from GitHub然后添加modelcontextprotocol/modelcontextprotocol这个 marketplace 即可。运行前置条件需要特别注意的是/draft-sep技能要求必须在本地克隆的规范仓库或其 fork根目录下运行因为它要读取seps/TEMPLATE.md并向seps/目录写入提案文件。要获得本地副本可以克隆本镜像仓库git clone https://gitcode.com/gh_mirrors/specification2/specification克隆后进入仓库根目录seps/TEMPLATE.md与seps/目录即就位。/search-mcp-github技能则对工作目录没有此要求只要环境中配置了ghCLI 即可。Skill 一/search-mcp-github —— 全量检索 MCP 的决策历史该技能用于跨 MCP 的 GitHub discussions、issues 与 pull requests 检索某个主题的相关信息是理解为什么 MCP 是这样设计的这一问题的入口。检索范围四类来源根据 plugins/mcp-spec/skills/search-mcp-github/SKILL.md技能会同时检索以下四类来源Org 级 Discussionsorgs/modelcontextprotocol/discussions跨组织范围的讨论Spec 级 Discussionsmodelcontextprotocol/modelcontextprotocol/discussions规范仓库内的讨论Spec 级 Issuesmodelcontextprotocol/modelcontextprotocol/issuesSpec 级 Pull Requestsmodelcontextprotocol/modelcontextprotocol/pulls。一个关键细节是技能同时检索 open 和 closed 状态的 issue/PR。README 明确提示这对理解过去的决策与历史背景很重要——很多设计决策的最终结论恰恰沉淀在已关闭的讨论中。使用方法与示例/search-mcp-github Tool Annotations技能内部会优先调用mcp-docsMCP 服务器的SearchModelContextProtocol工具确认当前规范内容这是权威来源应最先使用随后用gh search prs/gh search issues检索规范仓库的 PR 与 Issue再通过 GitHub GraphQL API 检索讨论。检索词变体camelCase 与空格分隔缺一不可这是该技能最有价值的一条经验GitHub 搜索不会切分 camelCase token。ToolAnnotations与Tool Annotations会返回几乎完全不同的结果因此两个变体都必须搜索camelCase如ToolAnnotations、inputSchema匹配代码与 schema 中的标识符空格分隔如Tool Annotations、input schema匹配自然语言讨论文本。同时建议跳过 kebab-case 变体如tool-annotations——GitHub 按连字符分词其行为与空格分隔形式近似但结果更嘈杂。讨论检索使用 GraphQL APIGitHub 没有gh search discussions命令需要走 GraphQL API。SKILL.md 给出了两个可直接复用的查询模板# Spec 仓库级讨论 gh api graphql -f queryquery { search(query: \repo:modelcontextprotocol/modelcontextprotocol topic\, type: DISCUSSION, first: 20) { nodes { ... on Discussion { title url body author { login } authorAssociation category { name } answer { author { login } authorAssociation body } } } } } # Org 级讨论 gh api graphql -f queryquery { search(query: \org:modelcontextprotocol topic\, type: DISCUSSION, first: 20) { nodes { ... on Discussion { title url body author { login } authorAssociation category { name } answer { author { login } authorAssociation body } } } } }查询会返回讨论的标题、正文、作者、作者关联级别authorAssociation、所属分类以及被采纳的答案answer。深挖单个 PR理解为什么而非是什么当某个 PR 与主题高度相关、且需要理解变更动机而非仅了解变更内容时技能会进入深挖deep dive模式按三层结构翻阅PR 通用对话repos/modelcontextprotocol/modelcontextprotocol/issues/{pr_number}/comments即不绑定到具体代码行的讨论行内评审评论repos/modelcontextprotocol/modelcontextprotocol/pulls/{pr_number}/comments即评审时落在具体代码行上的意见顶层评审意见repos/modelcontextprotocol/modelcontextprotocol/pulls/{pr_number}/reviews即伴随 approve / request-changes / comment 结论提交的整体评审。每个评论都带author_association字段用于识别维护者身份。输出格式规范技能的输出有严格的格式约定保证结果可被引用、可回溯PR- #123 - PR Title (**Merged/Closed/Open** date)附一句摘要Issue- #456 - Issue Title (**Open/Closed** date)附一句摘要Discussion- #789 - Discussion Title (date)附内容摘要。维护者引语Notable maintainer quotes当维护者author_association为MEMBER或OWNER的评论揭示了设计意图、设定了方向、解释了理由技能会直接引用原文并署名、加脚注例如These would require a SEP. I think the general question here is about the taxonomy of hints. [^1] — dsp-ant值得引用并保留的引语类型包括解释为什么做出某个决策、为未来工作设定方向、拒绝或重定向某个方案、澄清某个特性的预期语义。所有引用与论断最后都要汇总为脚注例如[^1]: [#616 inline review comment by dsp-ant](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/616#discussion_r...) [^2]: [#185 ToolAnnotations](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/185)总体策略SKILL.md 将完整检索流程归纳为六步生成检索词变体 → 用SearchModelContextProtocol查当前规范 → 依据新信息扩展检索词 → 用ghCLI 检索 GitHub → 聚合结果 → 以摘要结果、关键洞见与直接署名的方式输出。Skill 二/draft-sep —— 按治理流程起草规范增强提案/draft-sep的目标是研究和起草一份符合 SEP 治理流程的规范增强提案。它会先判断想法是否值得走 SEP然后访谈作者、核查现有规范覆盖情况与先例再按模板填充必填与可选章节写入seps/0000-{slug}.md可选地打开草稿 PR、回填 SEP 编号并运行npm run generate:seps与npm run format:docs保证 CI 保持绿色。/draft-sep add websocket transport该技能将整个过程拆成六个按顺序执行的 Phase在门槛、访谈与研究完成之前不允许动笔。前置条件仓库环境准备/draft-sep必须在本地克隆或 fork根目录运行。正式开始前需完成三件事确认工作目录下存在seps/TEMPLATE.md若不存在提示用户先gh repo fork克隆仓库并从根目录重跑确定 canonical remote——即指向规范本体仓库而非 fork的 remote。查看git remote -v若origin指向本体则 canonical remote 为origin若origin指向 fork则寻找upstream没有就添加git remote add upstream https://github.com/modelcontextprotocol/modelcontextprotocol.git执行git fetch {canonical}并确保本地main与{canonical}/main同步让研究阶段能看到最新的 SEP、schema 与MAINTAINERS.md。Phase 6 中以{canonical}作为分支起点、origin作为推送目标——对维护者而言两者是同一个 remote对 fork 贡献者而言是两个 remote。另外SKILL.md 特别强调SEP 指南建议先在 Discord 或 Working/Interest Group 中讨论想法再起草。若用户尚未在任何地方讨论过该想法技能会明确告知并询问是否继续——冷启动的 SEP 合法但更容易停滞若 6 个月内找不到 sponsorCore Maintainers 可能关闭 PR 并标记为dormant。Phase 1 —— 门槛判断Gate在访谈与调研之前先根据一句话{idea}判断是否值得走 SEP**应当重定向不继续**的情形Bug 修复或拼写修正文档澄清为已有特性补充示例不改变行为的 minor schema 修复。这些情况应引导用户走普通 PR 或 bug 报告表单。应当继续的情形新的协议特性或对现有特性的修改破坏性变更breaking change治理或流程变更任何争议大到需要设计文档与历史记录的内容。拿不准时指南建议先到 Discord 询问避免把时间浪费在可能不值得的草案上。Phase 2 —— 六问访谈Interview动笔前必须向作者问清六个问题答案直接进入草案SEP 类型Standards Track核心协议特性、Extensions Track扩展而非核心见 SEP-2133、Informational指南/设计说明或 Process治理/流程变更。多数 SEP 是 Standards Track。若选 Extensions Track还必须确认负责的 Working Group 与 Extension Maintainers——SEP-2133 将其设为硬性要求且 Extensions Track SEP 在评审前必须在官方 SDK 中至少有一个参考实现。是否破坏性变更决定 Backward Compatibility 章节的分量。原型状态存在两个不同的门槛SEP 进入accepted前必须有可运行的原型进入final前必须有完整的参考实现。原型只需证明可行性、可运行不必生产级但绝不能只是伪代码。在哪里讨论过Discord 线程、WG/IG 会议或 GitHub Discussion——该链接会成为 Rationale 章节的共识证据。若答案是没讨论过需标记见上文。作者与 sponsor记录作者姓名、邮箱与 GitHub 用户名sponsor 必须是 Core Maintainer 或 Maintainer——它是 SEP 进入draft状态的授予者。有 sponsor 则记录其裸用户名gh pr create --reviewer需要不带的 handle没有则 preamble 写Sponsor: None并按 docs/community/sep-guidelines.mdx 的指引在 PR 上 1-2 位相关维护者来源见 MAINTAINERS.md、在相关 Discord 频道分享两周无回应再到#general询问。安全影响提案是否触及攻击面——新传输层、认证流程、数据暴露、信任边界seps/TEMPLATE.md 中的 Security Implications 章节是必填的即使未发现也要明确说明理由。Phase 3 —— 六步研究Research每步都要记录发现它们将直接喂给草案各章节当前规范覆盖优先用SearchModelContextProtocol工具查规范现状未配置该服务器时回退到grep -rn {keyword} docs/specification/draft/。这构成 Motivation 章节现有规范为何不足的另一半。GitHub 先例调用/search-mcp-github {idea}重点找触及同一面的已合并 PR、提出过类似需求的已关闭 Issue、维护者设定方向或拒绝过类似方案的讨论。若类似提案曾被拒绝该背景至关重要——新 SEP 必须解释发生了什么变化。重叠 SEPgrep -l -i {keyword} seps/*.md若已有 SEP 覆盖该领域正确做法通常是扩展或取代它而非另立平行提案。 4.设计原则与路线图契合度阅读 docs/community/design-principles.mdx 与 docs/development/roadmap.mdx识别提案服务于哪些原则、又与哪些原则存在张力并核对是否符合 Core Maintainer 当前优先级——不在当前优先级的提案更容易在评审中拖延。两者都进 Rationale 章节。 5.Schema 触点grep -n {affected-type} schema/draft/schema.ts对 Standards/Extensions Track SEP找出将被新增或修改的具体类型在 Specification 章节按名引用。 6.范本 SEPgrep -l Status.*Final seps/*.md | head -3阅读两三个 Final 状态的 SEP对齐其细节填充程度。Phase 4 —— 草稿撰写Draft阅读 seps/TEMPLATE.md 并按顺序填充每个章节写入seps/0000-{slug}.md{slug}为小写连字符形式的 idea截断到约 50 字符与现有seps/*.md文件名模式一致0000占位符是 SEP 指南约定的惯例。模板中---分隔线以上的内容是全部必填的——即使写 none identified 也要给出理由不能省略章节Additional Optional Sections 之下的标题才是可选的。Preamble 填写要点Status留空或省略——状态变更应由 sponsor 操作作者不应自行设置Type来自 Q1 的四种类型之一Created当天日期YYYY-MM-DD格式Author(s)Name email (github-username)Sponsorgithub-username或字面量NonePR先填https://github.com/modelcontextprotocol/modelcontextprotocol/pull/{NUMBER}占位符Phase 6 再回填真实编号。Phase 5 —— 检查点Checkpoint技能向用户报告草案文件路径、各章节内容的一句话摘要然后询问现在打开草稿 PR还是先停在这里由用户编辑文件未得到是之前不得进入 Phase 6。Phase 6 —— 打开 PR 与编号回填SEP-1850 确立的是基于 amend 的流程先用0000-占位符开 PR随后立即重命名并 amend使最终历史是携带真实编号的单一提交。命令序列如下git fetch {canonical} git checkout -b sep/{slug} {canonical}/main git add seps/0000-{slug}.md git commit -m SEP: {title} git push -u origin sep/{slug} gh pr create --repo modelcontextprotocol/modelcontextprotocol --base main \ --title SEP: {title} --body {one-paragraph summary} --draft --reviewer {sponsor-username}{canonical}即前置条件中确定的 remoteorigin永远是推送目标若sep/{slug}分支已存在如检查点后重入本阶段则复用而非新建Q5 答案为None时省略--reviewergh提示默认仓库时先执行gh repo set-default modelcontextprotocol/modelcontextprotocol再重试。拿到gh pr create输出的 PR 编号{N}后回填git mv seps/0000-{slug}.md seps/{N}-{slug}.md # 编辑文件标题行将 SEP-{NUMBER} 替换为 SEP-{N}并在 preamble 填入 PR 链接 npm run generate:seps npm run format:docs git add seps/{N}-{slug}.md docs/seps/ docs/docs.json git commit --amend --no-edit git push --force-with-lease其中npm run generate:seps会把docs/seps/{N}-{slug}.mdx渲染出来并更新docs/docs.json这是render-seps.ymlCI 检查所必需的npm run format:docs则让markdown-format.yml检查保持绿色。amend 使重命名与内容修改合并为单次提交符合 SEP-1850 的要求。若 Q5 答案为NonePR 打开后的下一步是寻找 sponsor——在 PR 上 1-2 位 MAINTAINERS.md 中的相关维护者并在相关 Discord 频道分享。6 个月的计时从此开始。仓库侧联动SEP 渲染与 CI 自动化/draft-sep末尾执行的npm run generate:seps并不是表面功夫它对应仓库中真实存在的自动化脚本 scripts/render-seps.ts。从源码看该脚本承担三件事读取seps/目录下所有符合{number}-{slug}.md命名约定的 SEP 文件0000-占位符草稿、TEMPLATE.md、README.md会被跳过用正则解析标题、Status、Type、Author(s)、Sponsor、PR 等元数据为每个 SEP 生成带状态徽章的docs/seps/{number}-{slug}.mdx页面并为 Final 状态的 SEP 注入历史记录、以现行规范为准的提示生成docs/seps/index.mdx索引页并重写docs/docs.json把 SEP 按状态Final/Accepted/In-Review/Draft/Withdrawn/Rejected/Superseded/Dormant分组挂到导航的 SEPs 标签页。脚本支持--check模式对应npm run check:seps把期望输出写入临时目录、用 Prettier 格式化后与现有文件逐字节比对不一致即退出码 1从而在 CI 中强制保证seps/与docs/seps/的同步。这与 package.json 中声明的脚本体系generate:seps、format:docs、check:seps、check:docs:links等共同构成了写 SEP → 渲染文档 → 格式与链接检查的完整流水线。草案的结构与命名规则同样有据可查文件结构模板见 seps/TEMPLATE.mdAbstract、Motivation、Specification、Rationale、Backward Compatibility、Security Implications、Reference Implementation 为必填主线而PR 编号即 SEP 编号、0000-占位符、amend 重命名这一工作流正是 seps/1850-pr-based-sep-workflow.md 所形式化的 Process 类 SEP 内容。技能中反复引用的 sponsor 角色、状态流转Draft → In-Review → Accepted → Final以及Rejected/Withdrawn/Superseded/Dormant等终态、dormant 的 6 个月规则均可在这两份文档与 docs/community/sep-guidelines.mdx 中找到一一对应的原文。适用场景与使用建议综合来看这套插件最适合三类场景规范研究者用/search-mcp-github检索某个特性如 Tool Annotations、OAuth、传输层的完整决策链——包括被拒绝的方案与维护者的原始表述避免只看当前规范、不知历史缘由的盲区提案作者用/draft-sep把一个想法规范地推进为符合治理流程的 SEP 草案六步研究确保 Motivation、Rationale、Schema 触点、参考实现等要素齐全贡献者与维护者协作通过技能强制的先讨论再起草、sponsor 确认、0000-编号回填与 CI 联动让整个提案流程在版本控制与自动化检查的约束下可追踪、可回滚、可评审。需要提醒的边界是/draft-sep的运行前提是本地克隆仓库根目录含seps/TEMPLATE.md且其最终推送目标是 MCP 规范本体仓库——对于在本镜像上研究学习的读者可在本地 fork 中完整演练六个 Phase验证草案与渲染流程再决定是否向官方提交。赞分享人工智能AI Agent工具调用【免费下载链接】specificationSpecification and documentation for the Model Context Protocol项目地址https://gitcode.com/gh_mirrors/specification2/specification点击查看免费下载相关推荐Atuin 内置 MCP Server 接入指南让 Claude Code、Cursor 等 AI 工具直接检索你的 Shell 历史Atuin 内置 MCP Server 接入指南让 Claude Code、Cursor 等 AI 工具直接检索你的 Shell 历史 Atuin 内置了一个CLI后端数据库在 MCP 规范仓库中使用 draft-sep 技能起草 Specification Enhancement Proposal 的完整指南在 MCP 规范仓库中使用 draft sep 技能起草 Specification Enhancement Proposal 的完整指南 本文面向希望在 Mo人工智能AI Agent工具调用基于 mcp-use 的 Skills over MCP 实战用 SKILL.md 为 MCP Server 内置操作手册基于 mcp use 的 Skills over MCP 实战用 SKILL.md 为 MCP Server 内置操作手册 Skills over MCP 允后端MCP 服务MCP ClientsAI Agent人工智能上一篇F´ 框架遥测组件字典解析以 TestTlm 为例掌握通道定义与字符串遥测实现下一篇如何快速掌握通达信数据读取面向新手的终极Python解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考