尧图网站建设 
MCP Registry 贡献者指南从发布 server 到提交代码的完整工作流【免费下载链接】registryA community driven registry service for Model Context Protocol (MCP) servers.项目地址: https://gitcode.com/GitHub_Trending/registry43/registryMCP Registry模型上下文协议社区注册表的贡献指南覆盖了两个方向将你的 MCP server 发布到注册表以及直接向注册表代码库本身提交代码。本文基于仓库根目录的 CONTRIBUTING.md结合 Makefile、data/seed.json、README.md 与发布流程文档 quickstart.mdx系统梳理如何正确发布一个 MCP server与如何本地搭建开发环境、运行完整检查两条主线帮助你在动手前避免最常见的误区尤其是误改 seed 数据并掌握可复制的本地开发命令。第一件事不要把 server 提 PR 到 seed.json这是官方贡献指南中优先级最高的一条警告Do NOT open a pull request to add your server todata/seed.json.data/seed.json是仅供本地开发使用的种子数据。修改它不会把你的 server 发布到注册表上。这个文件的实际形态是一个ServerJSON数组以 data/seed.json 中的第一条记录为例每条记录包含name如io.github.domdomegg/airtable-mcp-server、description、repository、version、packages含registryType、identifier、transport、environmentVariables等字段与发布 API 接受的server.json结构一致——它存在的意义是让本地开发环境可以加载一份小型、可离线验证的数据集。为什么 seed.json 只影响本地环境从源码可以印证这一机制。注册表启动时通过环境变量MCP_REGISTRY_SEED_FROM指定种子数据来源该变量在 internal/config/config.go 中被解析// internal/config/config.go SeedFrom string env:SEED_FROM envDefault: EnableRegistryValidation bool env:ENABLE_REGISTRY_VALIDATION envDefault:true所有配置项统一以MCP_REGISTRY_为前缀NewConfig()中通过env.ParseWithOptions解析。internal/importer/importer.go 的ImportFromPath方法支持三类来源本地 JSON 文件——即data/seed.json这类 ServerJSON 数组文件直接指向 seed.json 的 HTTP URL注册表 API 根路径——自动追加/v0/servers并按nextCursor分页拉取fetchFromRegistryAPI实现。导入时每条记录会经过validators.ValidateServerJSON校验见 internal/validators校验失败的记录会被跳过并记录日志而不是让整个批次失败。.env.example 中对离线开发给出了明确建议# Path or URL to import seed data (supports local files and HTTP URLs) # For offline development, use: data/seed.json MCP_REGISTRY_SEED_FROMdata/seed.json # Validate seed data against the registry rules on import (default: true) # Set to false for offline development when seeding from a local file, since # data/seed.json is not guaranteed to pass validation MCP_REGISTRY_ENABLE_REGISTRY_VALIDATIONfalseREADME.md 也给出了对应的完整命令MCP_REGISTRY_SEED_FROMdata/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATIONfalse make dev-compose而 docker-compose.yml 的默认值是从生产 API 拉取一个过滤后的服务器子集MCP_REGISTRY_SEED_FROMhttps://registry.modelcontextprotocol.io/v0/servers?searchdomdomegg目的是让本地环境与生产行为保持一致、且所有种子数据都能通过校验。这也解释了为什么改data/seed.json对线上注册表毫无影响——线上数据只能通过发布 API 写入。正确发布 MCP server使用 mcp-publisher CLI要发布自己的 MCP server官方路径是使用mcp-publisherCLI 工具。完整的分步教程见 docs/modelcontextprotocol-io/quickstart.mdx其核心流程如下在包中写入所有权验证信息以 npm 包为例需要在package.json中加入mcpName属性其值就是 server 在注册表中的名称使用 GitHub 认证时mcpName必须以io.github.你的GitHub用户名/开头{ name: my-username/mcp-weather-server, version: 1.0.1, mcpName: io.github.my-username/weather }非 npm 包PyPI、NuGet、OCI、MCPB的验证机制不同如 PyPI/NuGet 要求在 README 中写入mcp-name: server-name行见 package-types.mdx。先发布包本身注册表只托管元数据、不托管制品所以必须先把包发布到 npmnpm publish --access public。安装mcp-publisher支持预编译二进制、Homebrewbrew install mcp-publisher等方式。也可以在仓库内直接从源码构建make publisher # 构建到 bin/mcp-publisher ./bin/mcp-publisher --help对应 Makefile 中的publisher目标它会用go build并注入Version、GitCommit、BuildTime三个 ldflags。生成server.json运行mcp-publisher init它会非交互式地在当前目录生成模板自动检测包管理器package.json等、预填可检测字段无法检测的字段写入TODO:占位符。生成的模板形如{ $schema: https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json, name: io.github.my-username/weather, description: An MCP server for weather information., repository: { url: https://github.com/my-username/mcp-weather-server, source: github }, version: 1.0.1, packages: [ { registryType: npm, identifier: my-username/mcp-weather-server, version: 1.0.1, transport: { type: stdio } } ] }注意server.json的name必须与package.json的mcpName一致。认证并发布mcp-publisher login github # 走 GitHub 设备码流程 mcp-publisher publish # 发布 server.json发布后可通过搜索接口验证curl https://registry.modelcontextprotocol.io/v0.1/servers?searchserver-name。常见报错排查摘自 quickstart 的 Troubleshooting 表报错处理Registry validation failed for package包缺少所有权验证标记npm 为mcpNamePyPI/NuGet 为 README 中的mcp-name行Invalid or expired Registry JWT token重新运行mcp-publisher login githubYou do not have permission to publish this server认证方式与命名空间不匹配GitHub 认证下 server 名必须io.github.用户名/前缀命名空间的所有权校验在服务端有对应实现JWT 签名密钥的配置见 internal/auth/jwt.go要求JWT_PRIVATE_KEY是一个 32 字节的 Ed25519 seed。mcp-publisher各子命令init/login/logout/publish/status/validate的完整参数参考见 docs/reference/cli/commands.md。参与代码库开发协作渠道CONTRIBUTING.md 指出注册表团队使用多个协作渠道通常的推进管道是Discord——社区实时讨论Discussions——提出并讨论产品/技术需求Issues——跟踪范围明确的技术工作项Pull Requests——针对 issue 提交实现。即先在社区渠道提出想法在 Discussions 中打磨需求落到 Issue 后以 PR 形式贡献。README 中列出的 Registry Working Group 成员也是了解项目方向的入口。本地开发环境搭建贡献代码前需要能本地运行注册表。根据 README.md 的 Quick Start前置依赖为DockerGo——版本以 go.mod 中go指令为准Go 工具链会自动拉取ko——Go 容器镜像构建工具注册表镜像由 ko 构建golangci-lint——版本与 CI 中golangci-lint-action的固定版本保持一致确保本地 lint 结果与 CI 一致。启动完整开发环境make dev-compose从 Makefile 可见dev-compose依赖ko-build目标先用ko build --preserve-import-paths --tagsdev --sbomnone ./cmd/registry构建镜像并加载到本地 Docker daemon再执行docker compose up。启动后服务运行在localhost:8080PostgreSQL 采用临时存储每次重启容器都会重置数据库保证开发/测试的干净状态。其他常用目标运行make help查看全部目标作用make publisher构建bin/mcp-publisherCLImake build构建bin/registry二进制注入版本信息make dev-down停止开发环境docker compose downmake test-unit单测自动拉起/关闭 PostgreSQL生成覆盖率报告make test-integration集成测试./tests/integration/run.shmake lint/lint-fix运行 golangci-lint含格式化make validateschema 与示例校验validate-schemasvalidate-examplesmake check一键全量检查见下节make check提交前必过的检查组合CONTRIBUTING.md 给出的提交前检查命令是# Run lint, schema validation, and all tests # Note: this also runs make dev-down, stopping any running dev-compose environment make check对照 Makefile 第 85 行check目标的实际组成是四个子目标的串联check: dev-down lint validate test-all ## Run all checks (lint, validate, unit tests) and ensure dev environment is down echo All checks passed!逐段拆解dev-down——docker compose down先停掉正在运行的开发环境。这也是 CONTRIBUTING.md 中特别注释会停止正在运行的 dev-compose 环境的由来跑完检查后本地 8080 服务已不可用需要重新make dev-compose。lint——golangci-lint run --timeout5m包含格式检查需要 auto-fix 时用make lint-fix。validate——展开为validate-schemasvalidate-examples前者执行 tools/validate-schemas.sh 校验 JSON Schema 并运行check-schema确保server.schema.json与openapi.yaml同步工具实现在 tools/extract-server-schema后者执行 tools/validate-examples.sh 用 Schema 校验示例数据。test-all——test-unittest-integration。单元测试用-race -coverprofile覆盖./internal/...与./cmd/...若装了gotestsum则优先使用并生成coverage.html集成测试由 tests/integration/run.sh 驱动。因此一个健康的贡献工作流是make dev-compose开发 → 本地验证接口 →make check全量把关 → 提交 PR。小结发布 server 永远走mcp-publisherinit→login→publishdata/seed.json只是本地种子数据改它不会上线本地开发用make dev-compose/make dev-down管理环境离线场景用MCP_REGISTRY_SEED_FROMdata/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATIONfalse启动提交前用make checkdev-downlintvalidatetest-all完成与 CI 对齐的完整检查更多目标以make help为准需求与讨论走 Discord / Discussions / Issues / PRs 的协作管道深入细节可继续参考 README.md 的 Architecture 一节与 docs/ 下的完整文档。【免费下载链接】registryA community driven registry service for Model Context Protocol (MCP) servers.项目地址: https://gitcode.com/GitHub_Trending/registry43/registry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MCP Registry 贡献者指南：从发布 server 到提交代码的完整工作流
MCP Registry 贡献者指南从发布 server 到提交代码的完整工作流【免费下载链接】registryA community driven registry service for Model Context Protocol (MCP) servers.项目地址: https://gitcode.com/GitHub_Trending/registry43/registryMCP Registry模型上下文协议社区注册表的贡献指南覆盖了两个方向将你的 MCP server 发布到注册表以及直接向注册表代码库本身提交代码。本文基于仓库根目录的 CONTRIBUTING.md结合 Makefile、data/seed.json、README.md 与发布流程文档 quickstart.mdx系统梳理如何正确发布一个 MCP server与如何本地搭建开发环境、运行完整检查两条主线帮助你在动手前避免最常见的误区尤其是误改 seed 数据并掌握可复制的本地开发命令。第一件事不要把 server 提 PR 到 seed.json这是官方贡献指南中优先级最高的一条警告Do NOT open a pull request to add your server todata/seed.json.data/seed.json是仅供本地开发使用的种子数据。修改它不会把你的 server 发布到注册表上。这个文件的实际形态是一个ServerJSON数组以 data/seed.json 中的第一条记录为例每条记录包含name如io.github.domdomegg/airtable-mcp-server、description、repository、version、packages含registryType、identifier、transport、environmentVariables等字段与发布 API 接受的server.json结构一致——它存在的意义是让本地开发环境可以加载一份小型、可离线验证的数据集。为什么 seed.json 只影响本地环境从源码可以印证这一机制。注册表启动时通过环境变量MCP_REGISTRY_SEED_FROM指定种子数据来源该变量在 internal/config/config.go 中被解析// internal/config/config.go SeedFrom string env:SEED_FROM envDefault: EnableRegistryValidation bool env:ENABLE_REGISTRY_VALIDATION envDefault:true所有配置项统一以MCP_REGISTRY_为前缀NewConfig()中通过env.ParseWithOptions解析。internal/importer/importer.go 的ImportFromPath方法支持三类来源本地 JSON 文件——即data/seed.json这类 ServerJSON 数组文件直接指向 seed.json 的 HTTP URL注册表 API 根路径——自动追加/v0/servers并按nextCursor分页拉取fetchFromRegistryAPI实现。导入时每条记录会经过validators.ValidateServerJSON校验见 internal/validators校验失败的记录会被跳过并记录日志而不是让整个批次失败。.env.example 中对离线开发给出了明确建议# Path or URL to import seed data (supports local files and HTTP URLs) # For offline development, use: data/seed.json MCP_REGISTRY_SEED_FROMdata/seed.json # Validate seed data against the registry rules on import (default: true) # Set to false for offline development when seeding from a local file, since # data/seed.json is not guaranteed to pass validation MCP_REGISTRY_ENABLE_REGISTRY_VALIDATIONfalseREADME.md 也给出了对应的完整命令MCP_REGISTRY_SEED_FROMdata/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATIONfalse make dev-compose而 docker-compose.yml 的默认值是从生产 API 拉取一个过滤后的服务器子集MCP_REGISTRY_SEED_FROMhttps://registry.modelcontextprotocol.io/v0/servers?searchdomdomegg目的是让本地环境与生产行为保持一致、且所有种子数据都能通过校验。这也解释了为什么改data/seed.json对线上注册表毫无影响——线上数据只能通过发布 API 写入。正确发布 MCP server使用 mcp-publisher CLI要发布自己的 MCP server官方路径是使用mcp-publisherCLI 工具。完整的分步教程见 docs/modelcontextprotocol-io/quickstart.mdx其核心流程如下在包中写入所有权验证信息以 npm 包为例需要在package.json中加入mcpName属性其值就是 server 在注册表中的名称使用 GitHub 认证时mcpName必须以io.github.你的GitHub用户名/开头{ name: my-username/mcp-weather-server, version: 1.0.1, mcpName: io.github.my-username/weather }非 npm 包PyPI、NuGet、OCI、MCPB的验证机制不同如 PyPI/NuGet 要求在 README 中写入mcp-name: server-name行见 package-types.mdx。先发布包本身注册表只托管元数据、不托管制品所以必须先把包发布到 npmnpm publish --access public。安装mcp-publisher支持预编译二进制、Homebrewbrew install mcp-publisher等方式。也可以在仓库内直接从源码构建make publisher # 构建到 bin/mcp-publisher ./bin/mcp-publisher --help对应 Makefile 中的publisher目标它会用go build并注入Version、GitCommit、BuildTime三个 ldflags。生成server.json运行mcp-publisher init它会非交互式地在当前目录生成模板自动检测包管理器package.json等、预填可检测字段无法检测的字段写入TODO:占位符。生成的模板形如{ $schema: https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json, name: io.github.my-username/weather, description: An MCP server for weather information., repository: { url: https://github.com/my-username/mcp-weather-server, source: github }, version: 1.0.1, packages: [ { registryType: npm, identifier: my-username/mcp-weather-server, version: 1.0.1, transport: { type: stdio } } ] }注意server.json的name必须与package.json的mcpName一致。认证并发布mcp-publisher login github # 走 GitHub 设备码流程 mcp-publisher publish # 发布 server.json发布后可通过搜索接口验证curl https://registry.modelcontextprotocol.io/v0.1/servers?searchserver-name。常见报错排查摘自 quickstart 的 Troubleshooting 表报错处理Registry validation failed for package包缺少所有权验证标记npm 为mcpNamePyPI/NuGet 为 README 中的mcp-name行Invalid or expired Registry JWT token重新运行mcp-publisher login githubYou do not have permission to publish this server认证方式与命名空间不匹配GitHub 认证下 server 名必须io.github.用户名/前缀命名空间的所有权校验在服务端有对应实现JWT 签名密钥的配置见 internal/auth/jwt.go要求JWT_PRIVATE_KEY是一个 32 字节的 Ed25519 seed。mcp-publisher各子命令init/login/logout/publish/status/validate的完整参数参考见 docs/reference/cli/commands.md。参与代码库开发协作渠道CONTRIBUTING.md 指出注册表团队使用多个协作渠道通常的推进管道是Discord——社区实时讨论Discussions——提出并讨论产品/技术需求Issues——跟踪范围明确的技术工作项Pull Requests——针对 issue 提交实现。即先在社区渠道提出想法在 Discussions 中打磨需求落到 Issue 后以 PR 形式贡献。README 中列出的 Registry Working Group 成员也是了解项目方向的入口。本地开发环境搭建贡献代码前需要能本地运行注册表。根据 README.md 的 Quick Start前置依赖为DockerGo——版本以 go.mod 中go指令为准Go 工具链会自动拉取ko——Go 容器镜像构建工具注册表镜像由 ko 构建golangci-lint——版本与 CI 中golangci-lint-action的固定版本保持一致确保本地 lint 结果与 CI 一致。启动完整开发环境make dev-compose从 Makefile 可见dev-compose依赖ko-build目标先用ko build --preserve-import-paths --tagsdev --sbomnone ./cmd/registry构建镜像并加载到本地 Docker daemon再执行docker compose up。启动后服务运行在localhost:8080PostgreSQL 采用临时存储每次重启容器都会重置数据库保证开发/测试的干净状态。其他常用目标运行make help查看全部目标作用make publisher构建bin/mcp-publisherCLImake build构建bin/registry二进制注入版本信息make dev-down停止开发环境docker compose downmake test-unit单测自动拉起/关闭 PostgreSQL生成覆盖率报告make test-integration集成测试./tests/integration/run.shmake lint/lint-fix运行 golangci-lint含格式化make validateschema 与示例校验validate-schemasvalidate-examplesmake check一键全量检查见下节make check提交前必过的检查组合CONTRIBUTING.md 给出的提交前检查命令是# Run lint, schema validation, and all tests # Note: this also runs make dev-down, stopping any running dev-compose environment make check对照 Makefile 第 85 行check目标的实际组成是四个子目标的串联check: dev-down lint validate test-all ## Run all checks (lint, validate, unit tests) and ensure dev environment is down echo All checks passed!逐段拆解dev-down——docker compose down先停掉正在运行的开发环境。这也是 CONTRIBUTING.md 中特别注释会停止正在运行的 dev-compose 环境的由来跑完检查后本地 8080 服务已不可用需要重新make dev-compose。lint——golangci-lint run --timeout5m包含格式检查需要 auto-fix 时用make lint-fix。validate——展开为validate-schemasvalidate-examples前者执行 tools/validate-schemas.sh 校验 JSON Schema 并运行check-schema确保server.schema.json与openapi.yaml同步工具实现在 tools/extract-server-schema后者执行 tools/validate-examples.sh 用 Schema 校验示例数据。test-all——test-unittest-integration。单元测试用-race -coverprofile覆盖./internal/...与./cmd/...若装了gotestsum则优先使用并生成coverage.html集成测试由 tests/integration/run.sh 驱动。因此一个健康的贡献工作流是make dev-compose开发 → 本地验证接口 →make check全量把关 → 提交 PR。小结发布 server 永远走mcp-publisherinit→login→publishdata/seed.json只是本地种子数据改它不会上线本地开发用make dev-compose/make dev-down管理环境离线场景用MCP_REGISTRY_SEED_FROMdata/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATIONfalse启动提交前用make checkdev-downlintvalidatetest-all完成与 CI 对齐的完整检查更多目标以make help为准需求与讨论走 Discord / Discussions / Issues / PRs 的协作管道深入细节可继续参考 README.md 的 Architecture 一节与 docs/ 下的完整文档。【免费下载链接】registryA community driven registry service for Model Context Protocol (MCP) servers.项目地址: https://gitcode.com/GitHub_Trending/registry43/registry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考