MCP Registry 生态系统愿景以 server.json 为核心的元注册表设计——官方注册表、社区子注册表与多生态包体系【免费下载链接】registryA community driven registry service for Model Context Protocol (MCP) servers.项目地址: https://gitcode.com/GitHub_Trending/registry43/registry本文基于 MCP Registry 仓库的生态设计文档 ecosystem-vision.md完整解读该项目的生态系统定位MCP 注册表如何作为元注册表metaregistry连接 npm、PyPI、Docker、NuGet、Cargo 等包生态官方注册表与社区子注册表Smithery、PulseMCP 等如何分工以及server.json数据模型如何统一描述服务器的身份、分发包、运行时与元数据。读完本文你将理解 MCP Registry 在整个 Model Context Protocol 生态中的架构角色并能对照仓库源码数据模型、路由、包校验器验证这套设计的具体落地方式。一、生态系统全景规范与官方注册表两大支柱MCP Registry 为 MCP 客户端提供 MCP 服务器列表相当于 MCP 服务器的应用商店未来还可能托管客户端列表等更多能力。项目本身由两个部分组成MCP Registry 规范一份 API 规范允许任何人自行实现一个注册表。完整的 OpenAPI 定义见 openapi.yaml。官方 MCP 注册表遵循该规范、部署在registry.modelcontextprotocol.io的托管注册表。它是公开 MCP 服务器的权威数据源authoritative repository——服务器作者只需发布一次所有消费者MCP 客户端、聚合器、市场都引用同一份规范化数据。该官方注册表由 MCP 开源社区拥有得到 Anthropic、GitHub、PulseMCP、Microsoft 等主要生态贡献者的支持。整个注册表围绕server.json格式构建——一种跨发现discovery、初始化initialization、打包packaging场景的标准服务器描述格式。官方仓库中这套设计的落地位置可以对照确认设计要素仓库对应实现注册表 API 规范openapi.yaml、official-registry-api.mdserver.json 格式规范generic-server-json.md、server.schema.json路由与端点v0.go同时注册/v0与/v0.1两套路由数据模型pkg/model/types.go、pkg/model/constants.go包存在性与归属校验internal/validators/registries/发布 CLIcmd/publisher/main.goREADME 中也标注了该 API 的当前状态v0.1 API 已进入冻结期2025-10-24 公告在冻结期内不做破坏性变更为集成方提供稳定契约这正对应设计文档中生态预期对稳定 API 的诉求。路由源码 RegisterV0_1Routes 显示/v0.1与/v0当前挂载同一组处理器servers、edit、status、publish、validate、auth 等体现了 v0 继续演进、v0.1 冻结并行的策略。设计文档还预期生态系统最终呈现为一张分层结构图官方文档内嵌的生态示意图读者可直接查看 ecosystem-diagram.excalidraw.svg 了解各层关系。理解这张图的关键一句话是MCP 注册表是元注册表。它托管关于包的元数据但不托管包本身的代码或二进制相反它引用其他包注册表NPM、PyPI、Docker 等来获取实际工件。二、核心定位注册表 vs 包注册表元注册表辨析设计文档给出了一个关键区分包注册表npm、PyPI、Docker Hub 等托管实际的代码/二进制MCP 注册表只托管指向这些包的元数据。原文档用一个直观的类比MCP Registry: weather-server v1.2.0 is at npm:weather-mcp NPM Registry: [actual weather-mcp package code]也就是说MCP Registry 回答的是这个 MCP 服务器在哪里、如何运行而不是这个包的字节在哪里。从仓库源码看这一元定位不是口号而是写进了数据模型和校验逻辑中1数据模型层面pkg/model/constants.go 定义注册表支持的上游包注册表类型与默认基地址// Registry Types - supported package registry types const ( RegistryTypeNPM npm RegistryTypePyPI pypi RegistryTypeOCI oci RegistryTypeNuGet nuget RegistryTypeMCPB mcpb RegistryTypeCargo cargo )即 npm、pypi、oci、nuget、mcpb、cargo 六类分发渠道同时定义了远程传输协议类型stdio、streamable-http、sse和运行时提示npx、uvx、docker、dnx。这些常量正是引用外部注册表这一设计在类型系统中的直接投影packages数组中的每一项本质上是一条对外部包注册表的指针附带运行所需的参数与环境变量描述。2校验层面正因为 MCP Registry 不托管工件它必须确保指针指向的东西真实存在且归属正确。以 NPM 为例ValidateNPM 会强制registryBaseUrl必须精确匹配官方 NPM 地址防止指向伪造镜像要求identifier与version必须为具体值版本区间如^1.2.3会被拒绝见 pkg/model/types.go 的字段文档实际发起 HTTP 请求拉取{baseURL}/{identifier}/{version}的元数据校验包声明的mcpName字段与所发布的服务器名一致以此证明包归属见 validateNPMPackage。PyPI 采用类似的归属令牌机制包的 README 中必须包含mcp-name: 服务器名令牌校验器通过 PyPI JSON API 抓取包描述并做边界锚定的令牌匹配见 pypi.go。这类实现共同印证了元注册表的一个隐含约束元数据必须能被上游事实核验否则只存指针的注册表就无法建立可信度。三、官方注册表 vs 社区子注册表分层数据流设计文档对两类注册表职责的划分如下官方 MCP 注册表registry.modelcontextprotocol.io公开可用服务器的规范化来源canonical source社区所有由可信贡献者背书聚焦可发现性与基础元数据。子注册表Subregistries如 Smithery、PulseMCP 等通过精选curation、评分、增强元数据来增值从官方注册表做 ETL 获取基础数据再叠加自有标注服务特定社区或使用场景。文档明确指出官方注册表预期会收到来自这些子注册表 ETL 任务的大量 API 请求因此列表端点被设计为可高效、稳定地翻页。这一点在 API 规范 generic-registry-api.md 中有完整定义核心读端点GET /v0.1/servers带游标分页列出所有服务器、GET /v0.1/servers/{serverName}/versions列版本、GET /v0.1/servers/{serverName}/versions/{version}取特定版本latest为特殊值写端点POST /v0.1/publish发布新服务器可选实现、PUT/PATCH状态端点可选官方注册表将其中部分实现为管理端点游标分页规则首次请求省略cursor后续请求使用上一页响应中的nextCursor当nextCursor为 null 或空时表示结束。规范强调游标必须被视为不透明字符串不得手工构造或修改默认无需认证子注册表可按 registry authorization 规范 自行选择认证方式所有请求响应均为application/json。列表端点的典型响应形态摘自规范{ servers: [ { server: { name: io.modelcontextprotocol/filesystem, description: Filesystem operations server, version: 1.0.2 }, _meta: { io.modelcontextprotocol.registry/official: { status: active, publishedAt: 2025-01-01T10:30:00Z, isLatest: true } } } ], metadata: { count: 10, nextCursor: com.example/my-server:1.0.0 } }在仓库中这套端点由 internal/api/handlers/v0/ 下的处理器实现servers、publish、status、edit、validate 等并在 v0.go 中统一注册到/v0与/v0.1两个前缀。官方 vs 社区的分层因此在工程上就体现为任何子注册表都是这套通用 API 规范的合法实现者或消费方——官方注册表负责数据权威性与规范化子注册表负责增值消费两者通过冻结期的 v0.1 API 解耦。四、服务器如何表示server.json 的四大要素设计文档将每个服务器条目归纳为四类信息并统一存放于标准化的server.json格式中工作在发现、安装与执行全链路要素含义对应字段pkg/model/types.goIdentity身份唯一名称如io.github.user/server-namename逆向 DNS 命名空间校验规则见 internal/validators/constants.go禁止多斜杠、限定格式Packages包从哪里下载npm、pypi、docker 等packages[].registryType / registryBaseUrl / identifier / versionRuntime运行时如何执行参数、环境变量packages[].transport / runtimeArguments / packageArguments / environmentVariables / runtimeHintMetadata元数据描述、仓库、版本等description / title / websiteUrl / repository / version一个最小而完整的 npm 服务器示例来自 server.json 格式规范 的示例该示例同时被 tests/integration/main.go 用作集成测试输入{ $schema: https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json, name: io.modelcontextprotocol.anonymous/brave-search, description: MCP server for Brave Search API integration, title: Brave Search, websiteUrl: https://anonymous.modelcontextprotocol.io/examples, repository: { url: https://github.com/modelcontextprotocol/servers, source: github }, version: 1.0.2, packages: [ { registryType: npm, registryBaseUrl: https://registry.npmjs.org, identifier: modelcontextprotocol/server-brave-search, version: 1.0.2, transport: { type: stdio }, environmentVariables: [ { name: BRAVE_API_KEY, description: Brave Search API Key, isRequired: true, isSecret: true } ] } ], _meta: { io.modelcontextprotocol.registry/publisher-provided: { tool: npm-publisher, version: 1.0.1 } } }对四大要素的源码级展开4.1 身份命名空间即所有权服务器名采用namespace/name的逆向 DNS 风格如io.github.user/server-name。注册表在发布时校验命名空间归属——以 README 的说明为例发布io.github.domdomegg/my-cool-mcp必须以domdomegg身份登录 GitHub或其仓库的 GitHub Action 中执行对应 GitHub OAuth / GitHub OIDC 两种认证方式发布me.adamjones/my-cool-mcp必须通过 DNS 或 HTTP challenge 证明拥有adamjones.me域名。发布 CLI 支持的多认证方式GitHub OAuth、GitHub OIDC、DNS 验证、HTTP 验证实现于 cmd/publisher/auth/ 与 internal/api/handlers/v0/auth/使身份这一要素从命名约定升级为可验证的所有权断言。4.2 包指向外部注册表的指针packages数组支持同一服务器同时分发到多个渠道。从 Package 类型定义 可看到其语义registryType决定其余字段的解释方式npm/pypi/nuget/cargo 使用identifier包名versionoci 使用完整镜像引用如ghcr.io/owner/repo:tag版本内嵌于 identifiermcpb 使用下载 URL且fileSha256为必填用于完整性校验模式约束为^[a-f0-9]{64}$registryBaseUrl用于 npm、pypi、nuget、cargo默认值即 constants.go 中的官方地址oci 与 mcpb 不使用version必须是具体版本版本区间^1.2.3、~1.2.3、1.2.3、1.x会被显式拒绝错误定义见 constants.go 中的ErrVersionLooksLikeRangeruntimeHint提示客户端选择运行时npx、uvx、docker、dnx等当存在runtimeArguments时应提供。4.3 运行时参数、环境变量与传输协议Transport类型types.go统一了本地包与远程服务的传输描述支持三种类型stdio客户端本地拉起进程streamable-http/sse连接远程端点支持headers可含isSecret凭据与variablesURL 模板变量用于多租户部署等场景。参数体系由Argumentpositional位置参数 /named命名参数与KeyValueInput环境变量/请求头构成二者均继承Input基础类型提供isRequired、default、choices、isSecret、format含filepath语义、placeholder等描述字段variables映射支持{curly_braces}占位符替换例如 Docker 挂载参数typebind,src{source_path},dst{target_path}。这套结构的目的是让元数据本身足以驱动客户端完成交互式配置——用户不需要读代码即可知道启动这个服务器需要哪些输入。4.4 元数据仓库引用与扩展位repository字段types.go除 URL 外还支持sourcegithub/gitlab、id宿主服务侧仓库 ID用于检测仓库删除后重建的复活攻击GitHub 下可用gh api repos/owner/repo --jq .id获取以及 monorepo 场景的subfolder。_meta扩展位允许发布者使用逆向 DNS 命名空间附加自定义元数据向官方注册表发布时自定义元数据须放在io.modelcontextprotocol.registry/publisher-provided键下详见 generic-server-json.md。当前 schema 版本为2025-12-11CurrentSchemaVersion历史版本 schema 均保留在 internal/validators/schemas/ 中体现了格式版本化这一对生态兼容至关重要的设计选择。五、生态系统如何运转发布、发现与 ETL 的闭环把前述各部分串起来生态数据流形成如下闭环发布作者构建服务器并发布到既有包生态npm、PyPI 等在包中嵌入归属声明npm 的mcpName、PyPI README 的mcp-name令牌随后使用仓库自带的mcp-publisherCLImake publisher构建入口 cmd/publisher/main.go提交server.json到POST /v0/publish。注册表端通过 internal/validators/ 完成 schema 校验、命名空间所有权校验、以及前述的上游包存在性/归属核验。发现MCP 客户端或聚合器调用GET /v0.1/servers等公开读端点拉取元数据读端点为 CDN 缓存与高频轮询而设计参见 tech-architecture.md 中的数据流描述注意该文档顶部已标注其部分内容与当前部署存在漂移实际部署架构以 deploy/README.md 和 official-registry-api.md 为准。消费子注册表以 ETL 方式从官方注册表同步规范化数据游标分页即为该场景优化叠加精选、评分与增强元数据后服务各自社区最终 MCP 客户端从子注册表或官方注册表获取数据按server.json的 packages/runtime 描述下载并启动服务器。演进官方注册表作为权威数据源接受社区治理由 Stacklok、PulseMCP、TeamSpark、Ravenmail 等机构的成员组成的 Registry Working Group 维护见 READMEAPI 按 v0 → v0.1冻结→ v1GA的路线演进发布节奏见 roadmap.md 与 releasing.md。六、小结与延伸阅读生态愿景文档的核心论点可以浓缩为三条注册表是规范与官方实现的二元组合注册表是引用外部包生态的元注册表而非工件仓库server.json是贯穿发现、安装与执行的统一数据契约。这三点在仓库中均有可直接核对的实现规范文档docs/reference/api/、docs/reference/server-json/、冻结的 v0.1 路由v0.go、数据模型与校验器pkg/model/、internal/validators/。若想继续深入推荐路径想理解发布全流程quickstart.mdx作者指南→ cmd/publisher/README.md想实现一个自己的子注册表generic-registry-api.md openapi.yaml想理解官方注册表的额外约束认证、扩展元数据、管理端点official-registry-api.md 与 official-registry-requirements.md想看本地如何跑起整个系统README 的 Quick startmake dev-compose启动带 PostgreSQL 的开发环境docker-compose.yml 提供配置参考。【免费下载链接】registryA community driven registry service for Model Context Protocol (MCP) servers.项目地址: https://gitcode.com/GitHub_Trending/registry43/registry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MCP Registry 生态系统愿景：以 server.json 为核心的元注册表设计——官方注册表、社区子注册表与多生态包体系
MCP Registry 生态系统愿景以 server.json 为核心的元注册表设计——官方注册表、社区子注册表与多生态包体系【免费下载链接】registryA community driven registry service for Model Context Protocol (MCP) servers.项目地址: https://gitcode.com/GitHub_Trending/registry43/registry本文基于 MCP Registry 仓库的生态设计文档 ecosystem-vision.md完整解读该项目的生态系统定位MCP 注册表如何作为元注册表metaregistry连接 npm、PyPI、Docker、NuGet、Cargo 等包生态官方注册表与社区子注册表Smithery、PulseMCP 等如何分工以及server.json数据模型如何统一描述服务器的身份、分发包、运行时与元数据。读完本文你将理解 MCP Registry 在整个 Model Context Protocol 生态中的架构角色并能对照仓库源码数据模型、路由、包校验器验证这套设计的具体落地方式。一、生态系统全景规范与官方注册表两大支柱MCP Registry 为 MCP 客户端提供 MCP 服务器列表相当于 MCP 服务器的应用商店未来还可能托管客户端列表等更多能力。项目本身由两个部分组成MCP Registry 规范一份 API 规范允许任何人自行实现一个注册表。完整的 OpenAPI 定义见 openapi.yaml。官方 MCP 注册表遵循该规范、部署在registry.modelcontextprotocol.io的托管注册表。它是公开 MCP 服务器的权威数据源authoritative repository——服务器作者只需发布一次所有消费者MCP 客户端、聚合器、市场都引用同一份规范化数据。该官方注册表由 MCP 开源社区拥有得到 Anthropic、GitHub、PulseMCP、Microsoft 等主要生态贡献者的支持。整个注册表围绕server.json格式构建——一种跨发现discovery、初始化initialization、打包packaging场景的标准服务器描述格式。官方仓库中这套设计的落地位置可以对照确认设计要素仓库对应实现注册表 API 规范openapi.yaml、official-registry-api.mdserver.json 格式规范generic-server-json.md、server.schema.json路由与端点v0.go同时注册/v0与/v0.1两套路由数据模型pkg/model/types.go、pkg/model/constants.go包存在性与归属校验internal/validators/registries/发布 CLIcmd/publisher/main.goREADME 中也标注了该 API 的当前状态v0.1 API 已进入冻结期2025-10-24 公告在冻结期内不做破坏性变更为集成方提供稳定契约这正对应设计文档中生态预期对稳定 API 的诉求。路由源码 RegisterV0_1Routes 显示/v0.1与/v0当前挂载同一组处理器servers、edit、status、publish、validate、auth 等体现了 v0 继续演进、v0.1 冻结并行的策略。设计文档还预期生态系统最终呈现为一张分层结构图官方文档内嵌的生态示意图读者可直接查看 ecosystem-diagram.excalidraw.svg 了解各层关系。理解这张图的关键一句话是MCP 注册表是元注册表。它托管关于包的元数据但不托管包本身的代码或二进制相反它引用其他包注册表NPM、PyPI、Docker 等来获取实际工件。二、核心定位注册表 vs 包注册表元注册表辨析设计文档给出了一个关键区分包注册表npm、PyPI、Docker Hub 等托管实际的代码/二进制MCP 注册表只托管指向这些包的元数据。原文档用一个直观的类比MCP Registry: weather-server v1.2.0 is at npm:weather-mcp NPM Registry: [actual weather-mcp package code]也就是说MCP Registry 回答的是这个 MCP 服务器在哪里、如何运行而不是这个包的字节在哪里。从仓库源码看这一元定位不是口号而是写进了数据模型和校验逻辑中1数据模型层面pkg/model/constants.go 定义注册表支持的上游包注册表类型与默认基地址// Registry Types - supported package registry types const ( RegistryTypeNPM npm RegistryTypePyPI pypi RegistryTypeOCI oci RegistryTypeNuGet nuget RegistryTypeMCPB mcpb RegistryTypeCargo cargo )即 npm、pypi、oci、nuget、mcpb、cargo 六类分发渠道同时定义了远程传输协议类型stdio、streamable-http、sse和运行时提示npx、uvx、docker、dnx。这些常量正是引用外部注册表这一设计在类型系统中的直接投影packages数组中的每一项本质上是一条对外部包注册表的指针附带运行所需的参数与环境变量描述。2校验层面正因为 MCP Registry 不托管工件它必须确保指针指向的东西真实存在且归属正确。以 NPM 为例ValidateNPM 会强制registryBaseUrl必须精确匹配官方 NPM 地址防止指向伪造镜像要求identifier与version必须为具体值版本区间如^1.2.3会被拒绝见 pkg/model/types.go 的字段文档实际发起 HTTP 请求拉取{baseURL}/{identifier}/{version}的元数据校验包声明的mcpName字段与所发布的服务器名一致以此证明包归属见 validateNPMPackage。PyPI 采用类似的归属令牌机制包的 README 中必须包含mcp-name: 服务器名令牌校验器通过 PyPI JSON API 抓取包描述并做边界锚定的令牌匹配见 pypi.go。这类实现共同印证了元注册表的一个隐含约束元数据必须能被上游事实核验否则只存指针的注册表就无法建立可信度。三、官方注册表 vs 社区子注册表分层数据流设计文档对两类注册表职责的划分如下官方 MCP 注册表registry.modelcontextprotocol.io公开可用服务器的规范化来源canonical source社区所有由可信贡献者背书聚焦可发现性与基础元数据。子注册表Subregistries如 Smithery、PulseMCP 等通过精选curation、评分、增强元数据来增值从官方注册表做 ETL 获取基础数据再叠加自有标注服务特定社区或使用场景。文档明确指出官方注册表预期会收到来自这些子注册表 ETL 任务的大量 API 请求因此列表端点被设计为可高效、稳定地翻页。这一点在 API 规范 generic-registry-api.md 中有完整定义核心读端点GET /v0.1/servers带游标分页列出所有服务器、GET /v0.1/servers/{serverName}/versions列版本、GET /v0.1/servers/{serverName}/versions/{version}取特定版本latest为特殊值写端点POST /v0.1/publish发布新服务器可选实现、PUT/PATCH状态端点可选官方注册表将其中部分实现为管理端点游标分页规则首次请求省略cursor后续请求使用上一页响应中的nextCursor当nextCursor为 null 或空时表示结束。规范强调游标必须被视为不透明字符串不得手工构造或修改默认无需认证子注册表可按 registry authorization 规范 自行选择认证方式所有请求响应均为application/json。列表端点的典型响应形态摘自规范{ servers: [ { server: { name: io.modelcontextprotocol/filesystem, description: Filesystem operations server, version: 1.0.2 }, _meta: { io.modelcontextprotocol.registry/official: { status: active, publishedAt: 2025-01-01T10:30:00Z, isLatest: true } } } ], metadata: { count: 10, nextCursor: com.example/my-server:1.0.0 } }在仓库中这套端点由 internal/api/handlers/v0/ 下的处理器实现servers、publish、status、edit、validate 等并在 v0.go 中统一注册到/v0与/v0.1两个前缀。官方 vs 社区的分层因此在工程上就体现为任何子注册表都是这套通用 API 规范的合法实现者或消费方——官方注册表负责数据权威性与规范化子注册表负责增值消费两者通过冻结期的 v0.1 API 解耦。四、服务器如何表示server.json 的四大要素设计文档将每个服务器条目归纳为四类信息并统一存放于标准化的server.json格式中工作在发现、安装与执行全链路要素含义对应字段pkg/model/types.goIdentity身份唯一名称如io.github.user/server-namename逆向 DNS 命名空间校验规则见 internal/validators/constants.go禁止多斜杠、限定格式Packages包从哪里下载npm、pypi、docker 等packages[].registryType / registryBaseUrl / identifier / versionRuntime运行时如何执行参数、环境变量packages[].transport / runtimeArguments / packageArguments / environmentVariables / runtimeHintMetadata元数据描述、仓库、版本等description / title / websiteUrl / repository / version一个最小而完整的 npm 服务器示例来自 server.json 格式规范 的示例该示例同时被 tests/integration/main.go 用作集成测试输入{ $schema: https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json, name: io.modelcontextprotocol.anonymous/brave-search, description: MCP server for Brave Search API integration, title: Brave Search, websiteUrl: https://anonymous.modelcontextprotocol.io/examples, repository: { url: https://github.com/modelcontextprotocol/servers, source: github }, version: 1.0.2, packages: [ { registryType: npm, registryBaseUrl: https://registry.npmjs.org, identifier: modelcontextprotocol/server-brave-search, version: 1.0.2, transport: { type: stdio }, environmentVariables: [ { name: BRAVE_API_KEY, description: Brave Search API Key, isRequired: true, isSecret: true } ] } ], _meta: { io.modelcontextprotocol.registry/publisher-provided: { tool: npm-publisher, version: 1.0.1 } } }对四大要素的源码级展开4.1 身份命名空间即所有权服务器名采用namespace/name的逆向 DNS 风格如io.github.user/server-name。注册表在发布时校验命名空间归属——以 README 的说明为例发布io.github.domdomegg/my-cool-mcp必须以domdomegg身份登录 GitHub或其仓库的 GitHub Action 中执行对应 GitHub OAuth / GitHub OIDC 两种认证方式发布me.adamjones/my-cool-mcp必须通过 DNS 或 HTTP challenge 证明拥有adamjones.me域名。发布 CLI 支持的多认证方式GitHub OAuth、GitHub OIDC、DNS 验证、HTTP 验证实现于 cmd/publisher/auth/ 与 internal/api/handlers/v0/auth/使身份这一要素从命名约定升级为可验证的所有权断言。4.2 包指向外部注册表的指针packages数组支持同一服务器同时分发到多个渠道。从 Package 类型定义 可看到其语义registryType决定其余字段的解释方式npm/pypi/nuget/cargo 使用identifier包名versionoci 使用完整镜像引用如ghcr.io/owner/repo:tag版本内嵌于 identifiermcpb 使用下载 URL且fileSha256为必填用于完整性校验模式约束为^[a-f0-9]{64}$registryBaseUrl用于 npm、pypi、nuget、cargo默认值即 constants.go 中的官方地址oci 与 mcpb 不使用version必须是具体版本版本区间^1.2.3、~1.2.3、1.2.3、1.x会被显式拒绝错误定义见 constants.go 中的ErrVersionLooksLikeRangeruntimeHint提示客户端选择运行时npx、uvx、docker、dnx等当存在runtimeArguments时应提供。4.3 运行时参数、环境变量与传输协议Transport类型types.go统一了本地包与远程服务的传输描述支持三种类型stdio客户端本地拉起进程streamable-http/sse连接远程端点支持headers可含isSecret凭据与variablesURL 模板变量用于多租户部署等场景。参数体系由Argumentpositional位置参数 /named命名参数与KeyValueInput环境变量/请求头构成二者均继承Input基础类型提供isRequired、default、choices、isSecret、format含filepath语义、placeholder等描述字段variables映射支持{curly_braces}占位符替换例如 Docker 挂载参数typebind,src{source_path},dst{target_path}。这套结构的目的是让元数据本身足以驱动客户端完成交互式配置——用户不需要读代码即可知道启动这个服务器需要哪些输入。4.4 元数据仓库引用与扩展位repository字段types.go除 URL 外还支持sourcegithub/gitlab、id宿主服务侧仓库 ID用于检测仓库删除后重建的复活攻击GitHub 下可用gh api repos/owner/repo --jq .id获取以及 monorepo 场景的subfolder。_meta扩展位允许发布者使用逆向 DNS 命名空间附加自定义元数据向官方注册表发布时自定义元数据须放在io.modelcontextprotocol.registry/publisher-provided键下详见 generic-server-json.md。当前 schema 版本为2025-12-11CurrentSchemaVersion历史版本 schema 均保留在 internal/validators/schemas/ 中体现了格式版本化这一对生态兼容至关重要的设计选择。五、生态系统如何运转发布、发现与 ETL 的闭环把前述各部分串起来生态数据流形成如下闭环发布作者构建服务器并发布到既有包生态npm、PyPI 等在包中嵌入归属声明npm 的mcpName、PyPI README 的mcp-name令牌随后使用仓库自带的mcp-publisherCLImake publisher构建入口 cmd/publisher/main.go提交server.json到POST /v0/publish。注册表端通过 internal/validators/ 完成 schema 校验、命名空间所有权校验、以及前述的上游包存在性/归属核验。发现MCP 客户端或聚合器调用GET /v0.1/servers等公开读端点拉取元数据读端点为 CDN 缓存与高频轮询而设计参见 tech-architecture.md 中的数据流描述注意该文档顶部已标注其部分内容与当前部署存在漂移实际部署架构以 deploy/README.md 和 official-registry-api.md 为准。消费子注册表以 ETL 方式从官方注册表同步规范化数据游标分页即为该场景优化叠加精选、评分与增强元数据后服务各自社区最终 MCP 客户端从子注册表或官方注册表获取数据按server.json的 packages/runtime 描述下载并启动服务器。演进官方注册表作为权威数据源接受社区治理由 Stacklok、PulseMCP、TeamSpark、Ravenmail 等机构的成员组成的 Registry Working Group 维护见 READMEAPI 按 v0 → v0.1冻结→ v1GA的路线演进发布节奏见 roadmap.md 与 releasing.md。六、小结与延伸阅读生态愿景文档的核心论点可以浓缩为三条注册表是规范与官方实现的二元组合注册表是引用外部包生态的元注册表而非工件仓库server.json是贯穿发现、安装与执行的统一数据契约。这三点在仓库中均有可直接核对的实现规范文档docs/reference/api/、docs/reference/server-json/、冻结的 v0.1 路由v0.go、数据模型与校验器pkg/model/、internal/validators/。若想继续深入推荐路径想理解发布全流程quickstart.mdx作者指南→ cmd/publisher/README.md想实现一个自己的子注册表generic-registry-api.md openapi.yaml想理解官方注册表的额外约束认证、扩展元数据、管理端点official-registry-api.md 与 official-registry-requirements.md想看本地如何跑起整个系统README 的 Quick startmake dev-compose启动带 PostgreSQL 的开发环境docker-compose.yml 提供配置参考。【免费下载链接】registryA community driven registry service for Model Context Protocol (MCP) servers.项目地址: https://gitcode.com/GitHub_Trending/registry43/registry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考