企业官网建设流程全解析

• AI 插件
• 开发工具
• 插件系统

在claude-plugins-official仓库的mcp-server-dev插件中，skills/build-mcp-server/references/versions.md是一份特殊的"版本敏感声明台账"。它不讲解任何一条 API 的用法，而是把整套 MCP 服务器开发技能里所有与版本、日期、CDN 钉住、Schema 版本相关的断言集中到一张表里，并给出逐条可执行的验证命令，供技能维护者在更新时优先核对。本文以该文档为骨架，结合build-mcp-server、build-mcp-app、build-mcpb三个技能及其 reference 文件的源码细节，说明这张核对表背后的每条声明为什么存在、落在哪些文件里，以及如何用官方命令快速验证，帮助你正确维护或审阅这套 Claude Code 插件技能。

一、这份文档的定位：技能库的"版本敏感声明台账"

mcp-server-dev是 README.md 中描述的一组用于"设计并构建与 Claude 无缝协作的 MCP 服务器"的技能集合，入口技能build-mcp-server负责引导开发者依次完成用例探查、部署模型选型、工具设计模式选型、框架选型和脚手架交接五个阶段，并可进一步转交build-mcp-app（在会话内渲染交互式 UI 组件）与build-mcpb（把本地 stdio 服务器连同运行时打包发布）。

这类技能文档有一个共性风险：正文里散布着大量与时间强相关的断言——某个 npm 包的 CDN 钉住版本、某条 MCP 规范草案的升级状态、某个 CLI 的最低版本要求、某个远程模板的仓库路径。这些声明一旦过时，就会让技能给出错误指导。versions.md的存在意义正是把这类声明从各个正文文件中"抽出来"集中登记，形成一张可逐条复核的表格：

"Every version-sensitive claim in this skill, in one place. When updating the skill, check these first."（本技能中所有版本敏感声明，集中一处。更新技能时，先核对这些。）

这是技能维护的最佳实践：版本声明集中化（version-pin ledger）。修改技能正文前先对照台账，避免只改了正文、漏了另一处引用，或只更新了一处导致全技能自相矛盾。

二、逐条解读台账中的六个版本声明

台账表格使用Claim | Where stated | Last verified三列结构，登记了 2026-03 验证的六类声明。

1.@modelcontextprotocol/ext-apps@1.2.2CDN 钉住

@modelcontextprotocol/ext-apps是 MCP app（在聊天界面内联渲染表单、选择器、确认对话框等交互组件）所依赖的 SDK。build-mcp-app技能在 SKILL.md 中定义了"标准 MCP 服务器 + 附加 UI 资源"的架构，其 UI 层就是通过ui://资源与ext-apps运行时协作实现的。

该声明在正文里出现 4 次（SKILL.md 与 widget-templates.md 各若干处），意味着任何一次版本升级都需要同步修改全部 4 处引用，否则会出现"主文档已升级、模板示例仍引用旧版 CDN"的不一致。验证命令（见第三节）用npm view查询最新版本号，与台账中的1.2.2对比即可判断是否过期。

2. Claude Code ≥ 2.1.76（elicitation 能力）

Elicitation 是 MCP 规范原生的"工具执行中途向用户索取结构化输入"能力：服务端发送一份扁平 JSON Schema，宿主渲染原生表单，用户填写后服务端继续执行——零 UI 代码。

台账指明该能力的最低宿主版本是 Claude Code 2.1.76，相关声明精确到行号：elicitation.md（宿主支持状态表）与 build-mcp-server/SKILL.md（Phase 1 第 4 问）、SKILL.md（Elicitation 部署模型小节）。

为什么这份声明如此重要？因为 elicitation 有一个残酷的兼容性现实（elicitation.md 明确记载）：SDK 在客户端未声明 elicitation 能力时会直接抛出CapabilityNotSupported，没有内置的优雅降级。因此技能强制要求"先检查clientCapabilities.elicitation，再决定是否调用elicitInput()，并提供纯文本兜底方案"。台账里钉住 2.1.76 这个最低版本，正是为了让技能能准确告知用户"你的 Claude Code 是否够新"。

3. MCP 规范 2025-11-25 中 CIMD / DCR 的状态

这指向认证参考文档 auth.md 中的三个关键结论（分别对应其第 20、24、41 行附近）：

• CIMD（Client ID Metadata Document）被规范提升为 SHOULD（推荐）：MCP 宿主把客户端元数据发布在一个 HTTPS URL 上，并以该 URL 作为client_id；授权服务器获取文档、校验后直接走授权码流程，无需注册端点、无需存储客户端记录。
• DCR（Dynamic Client Registration）被降级为 MAY（可选）：宿主向registration_endpointPOST 元数据完成动态注册的旧流程，退居向后兼容的备选方案。
• 客户端优先级顺序：预注册 → CIMD（若授权服务器通告client_id_metadata_document_supported）→ DCR（若有registration_endpoint）→ 提示用户。

这条台账声明意味着：技能文档里所有关于"推荐 CIMD、DCR 仅作兼容"的表述都以 2025-11-25 版规范为准。规范一旦再次修订，必须先改台账、再改 auth.md 中对应的三处表述。

4. MCPB manifest schema v0.4

MCPB 是把本地 stdio 服务器连同运行时打包、让用户无需安装 Node/Python 即可使用的分发格式。manifest-schema.md 记录了 manifest 的字段定义，其中明确：清单需校验于github.com/anthropics/mcpb/schemas/mcpb-manifest-v0.4.schema.json，且schema 使用additionalProperties: false，未知键会被直接拒绝，建议在 manifest 中显式声明"$schema"以获得编辑器校验。

台账钉住 v0.4，提醒维护者：一旦上游 schema 升到 v0.5，manifest-schema.md 中所有字段表、manifest_version建议值（"0.4"）、server.type取值（node/python/binary）与${__dirname}、${user_config.<key>}等替换变量说明都需要整体复核。

5. CloudflareagentsSDK /McpAgentAPI

Cloudflare Workers 是技能推荐的"两条命令从零到线上 URL"的最快部署路径（deploy-cloudflare-workers.md 开篇即称 "Fastest path from zero to a livehttps://MCP URL. Free tier, no credit card to start, two commands to deploy."）。

该文档的核心实现是McpAgent包装类：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { McpAgent } from "agents/mcp"; import { z } from "zod"; export class MyMCP extends McpAgent { server = new McpServer( { name: "my-service", version: "0.1.0" }, { instructions: "Prefer search_items before get_item — IDs aren't guessable." }, ); async init() { this.server.registerTool( "search_items", { description: "Search items by keyword. Returns up to `limit` matches.", inputSchema: { query: z.string().describe("Search keywords"), limit: z.number().int().min(1).max(50).default(10), }, annotations: { readOnlyHint: true }, }, async ({ query, limit }) => { const results = await upstreamApi.search(query, limit); return { content: [{ type: "text", text: JSON.stringify(results, null, 2) }] }; }, ); } } export default { fetch(request: Request, env: Env, ctx: ExecutionContext) { const url = new URL(request.url); if (url.pathname === "/mcp") { return MyMCP.serve("/mcp").fetch(request, env, ctx); } return new Response("Not found", { status: 404 }); }, };

McpAgent是 Cloudflare 对 streamable-HTTP 传输、会话路由与 Durable Object 管道的封装——开发者只需操作与 Express 脚手架完全一致的McpServer实例，因此tool-design.md与server-capabilities.md中的全部指导无需改动即可复用。台账钉住agentsSDK 与McpAgentAPI 的形态，提醒维护者关注该 SDK 的演进。

6. CF 模板路径cloudflare/ai/demos/remote-mcp-authless

同一文档中的脚手架命令依赖该模板存在且可用：

npm create cloudflare@latest -- my-mcp-server \ --template=cloudflare/ai/demos/remote-mcp-authless cd my-mcp-server

该模板自带agents、zod依赖与可运行的wrangler.jsonc。台账把它单列一条，是因为远程模板路径可能被上游移动或删除——验证命令直接通过 GitHub API 检查该路径下的src/index.ts是否仍存在（见第三节），一旦 404 就必须更新脚手架命令。

三、How to verify：三条命令逐项复核台账

versions.md的"如何验证"一节给出了三条 Bash 命令，分别对应台账中的三类外部依赖。这些命令设计得可离线审阅、可重复执行，是维护这套技能的核心操作。

1. 验证 ext-apps 最新版本

npm view @modelcontextprotocol/ext-apps version

npm view <pkg> version直接输出 npm registry 上该包的最新版本号。将输出与台账中的1.2.2对比：若不一致，说明 CDN 钉住版本已过期，需要同步更新 build-mcp-app/SKILL.md 与 widget-templates.md 中全部 4 处引用，并更新台账的 "Last verified" 日期。

2. 验证 Cloudflare 模板仍存在

gh api repos/cloudflare/ai/contents/demos/remote-mcp-authless/src/index.ts --jq '.sha'

使用 GitHub CLI 的gh api请求 Cloudflare 的ai仓库中该模板的src/index.ts文件内容元数据，并用--jq '.sha'只提取文件 blob 的 SHA。只要命令返回一个 SHA 值而不是 404 错误，就说明模板路径仍然有效；这是对远程模板存活性最直接的探测。

3. 验证 MCPB schema 可达性

curl -sI https://raw.githubusercontent.com/anthropics/mcpb/main/schemas/mcpb-manifest-v0.4.schema.json | head -1

curl -sI发送 HEAD 请求（-I，静默模式-s），| head -1只保留响应首行——即 HTTP 状态行。返回HTTP/2 200说明 schema 仍可访问；返回 404 则意味着上游 schema 路径已变动，需要同步修订 manifest-schema.md。

需要指出的是：这三条命令在验证外部依赖时非常高效，但台账中关于Claude Code 版本（≥2.1.76）与 MCP 规范状态（2025-11-25）的两条声明无法用命令探测，只能依赖官方发布公告与规范文本的人工核对——这正是台账保留 "Last verified" 列的意义：让读者知道每条声明的时效窗口。

四、从源码看这些声明为什么值得被"钉住"

把台账与技能正文对照阅读，可以更清楚地理解每条版本声明背后的实际影响面。

Elicitation：最低版本直接决定兜底逻辑

elicitation.md 的宿主支持状态表记载：Claude Code 自 v2.1.76 起支持（form与url两种模式），Claude Desktop 未确认，claude.ai 未知。而 SDK 在客户端未通告能力时会直接抛CapabilityNotSupported，因此技能的规范模式是：

server.registerTool("delete_all", { description: "Delete all items after confirmation", inputSchema: {}, }, async ({}, extra) => { const caps = server.getClientCapabilities(); if (caps?.elicitation) { const r = await server.elicitInput({ mode: "form", message: "Delete all items? This cannot be undone.", requestedSchema: { type: "object", properties: { confirm: { type: "boolean", title: "Confirm deletion" } }, required: ["confirm"], }, }); if (r.action === "accept" && r.content?.confirm) { await deleteAll(); return { content: [{ type: "text", text: "Deleted." }] }; } return { content: [{ type: "text", text: "Cancelled." }] }; } // Fallback: return text asking Claude to relay the question return { content: [{ type: "text", text: "Confirmation required. Please ask the user: 'Delete all items? This cannot be undone.' Then call this tool again with their answer." }] }; });

如果台账把版本从 2.1.76 上移，而技能正文仍要求用户做能力检查与兜底，两者并不冲突——但反过来，如果技能正文因旧版本号而误判"所有 Claude Code 都不支持 elicitation"、从而引导用户放弃这个规范原生的输入方案，损失就大了。台账的价值正是把这类"宿主版本决定功能可用性"的声明钉死，避免维护者凭印象改文档。

CIMD/DCR：规范状态决定 OAuth 选型建议

auth.md 中，Claude 的 MCP 客户端支持的认证类型表列出了oauth_dcr、oauth_cimd、oauth_anthropic_creds、custom_connection、none五类，并明确"不支持用户粘贴的 bearer token（static_bearer）与无用户同意的纯机器间client_credentials"。CIMD 之所以被优先推荐，是因为它免去了注册端点与客户端记录存储，其授权服务器职责包括：

1. 在/.well-known/oauth-authorization-server提供 RFC 8414 授权服务器元数据，并通告client_id_metadata_document_supported: true；
2. 提供指向该元数据的 MCP 受保护资源元数据文档；
3. 在授权时把client_id当作 HTTPS URL 拉取并校验客户端元数据；
4. 校验进入/mcp的 bearer token。

台账里"规范 2025-11-25 把 CIMD 提为 SHOULD、DCR 降为 MAY"这条声明，直接决定了技能所有 OAuth 场景的推荐排序。规范一旦演进，影响面是整个 auth.md 的认证类型表与服务器职责清单。

MCPB schema：版本决定清单字段与替换变量

manifest-schema.md 的字段表中，manifest_version必填且建议值为"0.4"；server对象使用type（node/python/binary）、entry_point与mcp_config，其中mcp_config.args与mcp_config.env支持${__dirname}（解包后 bundle 目录的绝对路径）与${user_config.<key>}（安装时用户输入值）两类替换变量。schema 的additionalProperties: false意味着任何未登记字段都会导致校验失败——这也解释了为什么版本台账必须存在：schema 升级往往伴随字段增删，而字段增删又会连锁影响所有示例 manifest 与user_config文档。

Cloudflare 部署：SDK 与模板是"外部契约"

deploy-cloudflare-workers.md 同时依赖两类外部契约：agentsSDK 的McpAgentAPI，以及cloudflare/ai仓库中的模板路径。前者决定init()/registerTool()的写法，后者决定脚手架命令能否成功拉取。台账把两者分列两条，正是因为它们的失效模式不同：SDK API 变动是"代码编译错误"，模板路径失效是"脚手架命令 404"，需要不同的验证手段（前者靠发布公告，后者靠gh api探测）。

五、维护建议：把"版本台账"机制复制到自己的技能里

versions.md虽然只有一页表格加三行命令，但它代表了一个可复用的工程实践，值得任何长期维护的 Claude Code 技能库借鉴：

1. 集中登记：把正文中所有与版本号、日期、Schema 版本、远程路径相关的断言集中到一张versions.md表格，用Claim | Where stated | Last verified三列记录声明内容、落点文件（精确到行号更佳）与验证时间。
2. 先核对再修改：把该文档定位为更新技能的"入口检查点"——任何正文改动前先读台账，避免出现多处引用不同步。
3. 给每条声明配验证命令：能通过npm view、gh api、curl -sI等命令探测的，附上可执行命令；依赖人工核对规范/公告的，保留Last verified列明确时效。
4. 按失效模式区分验证方式：包版本看 registry，模板路径看仓库内容，Schema 看 HTTP 可达性，宿主功能版本看官方发布——一种验证方式无法覆盖所有声明类型。

结语

versions.md 是mcp-server-dev技能库中最小却最关键的维护文档。六条声明分别钉住了ext-apps@1.2.2CDN、Claude Code ≥2.1.76、MCP 规范 2025-11-25 的 CIMD/DCR 状态、MCPB manifest v0.4、CloudflareagentsSDK 的McpAgentAPI 与remote-mcp-authless模板路径，每条都精确指向正文落点并配有验证手段。无论你是这套技能的维护者，还是想为自己的技能库建立类似的版本管理机制，都可以从这份台账开始：先核对，再修改，用命令验证，让文档里的每个版本断言都经得起时间检验。

• AI 插件
• 开发工具
• 插件系统