Register in MCP Registry for better discovery

[LukasHeimann]

MCP Servers can be registered in the central MCP Registry, aiding discovery and setup of the MCP server. One requirement for that is to at least somewhat standardize the distribution, compare https://modelcontextprotocol.io/registry/package-types.

• package into an OCI container
• distribute the CLI via npm (using prebuild binaries)
• MCPB in the GitHub Releases

Are there any thoughts to create the necessary artifacts and register centrally?

[DeusData]

Thanks for raising this, and for linking the package-types requirement rather than just the registry — that is the part that determines whether this is cheap or expensive.

Where things actually stand, since the distribution surface is wider than it may look from the README:

Already shipping (pkg/ in the repo): npm, PyPI, Homebrew, Scoop, WinGet, Chocolatey, AUR, Go, and Glama. So your second bullet — distribute the CLI via npm using prebuilt binaries — is already done and has been for a while; that is an existing channel rather than new work.

Not present today: there is no Dockerfile or OCI image, no MCPB bundle in the releases, and no server.json registry manifest at the repo root.

So the gap between here and a registry listing is narrower than your three bullets suggest — the npm path already satisfies one of the accepted package types, which means registration would mostly be a matter of adding the manifest and validating the existing npm artifact, rather than standing up a new distribution channel.

The two additions have quite different costs, and are worth separating:

An OCI container is a real ongoing commitment. The project ships a single static binary across Windows, macOS and Linux on x86 and ARM, and a container adds a build matrix leg, a registry to publish to, and a security-scanning surface, for a tool that normally runs beside your editor rather than as a service. That is a maintenance question rather than a packaging one.

MCPB in GitHub Releases is much cheaper, since the release pipeline already builds and uploads per-platform archives.

Whether to register centrally is a public-surface decision for the maintainer rather than something I should commit to in triage, so I am recording it with the above rather than answering yes. It is a well-argued proposal and the discoverability case is real.

One question that would help whoever picks it up: in your experience, does the registry meaningfully drive installs for CLI-shaped servers, or mostly for hosted/remote ones? That would change how the cost/benefit reads.

[LukasHeimann]

Thank you for that answer! Yes, in this case (with npm and pypi already existing), a registry listing can already be done. I guess choosing the format is just a matter of client convenience. MCPB support is relatively limited right now, but npm or python has a broad enough availability.

Being in the registry will create visibility for the server. The MCP registry, afaik, federates somewhat automatically, so you would be available in places like https://github.com/mcp, which is e.g. used in VSCode to show MCP Servers in the same window as extensions to the editor. GitHub Copilot also bases its "MCP Allowlist" feature for enterprises based on (private) MCP Registry listings.

I have no idea how significant those numbers will be, though...