Make mcp-publisher available to people easily

[domdomegg]

Is your feature request related to a problem? Please describe.
Currently to get the mcp-publisher CLI they need to clone the registry, build it from source and run it here.

Describe the solution you'd like
We should make installing it easy, e.g. brew install mcp-publisher or similar. Not sure what the best ways are to do this though (GitHub releases maybe?)

[domdomegg]

@claude can you suggest at least 3 (mabye more) ways of doing this, based on our current setup and considering best practices for software distribution. We want to make it easy and convenient for server developers to publish to the registry, and making the CLI easy to install is part of that. Feel free to be creative, wacky etc. in your brainstorming, but clear and concise in your reasoning about which is the better option.

[claude]

Claude finished @domdomegg's task —— View job

---

Distribution Options for mcp-publisher CLI

Here are 7 distribution approaches ranked by ease of implementation and user adoption:

🏆 Top Recommendations

1. GitHub Releases + Automatic Binaries ⭐⭐⭐⭐⭐

Installation: curl -sSL https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher-$(uname -s)-$(uname -m) -o mcp-publisher && chmod +x mcp-publisher

Pros:

• Zero external dependencies, works immediately
• Your existing build script already supports this
• Industry standard (used by Docker, kubectl, helm, etc.)
• Can integrate into existing CI pipeline easily
• Supports all platforms you already build for

Cons: Manual download, no automatic updates

Implementation: Add release automation to existing CI pipeline

2. Homebrew Formula ⭐⭐⭐⭐

Installation: brew install modelcontextprotocol/tap/mcp-publisher

Pros:

• macOS developers expect this
• Automatic updates with brew upgrade
• Can create custom tap for faster approval
• Excellent discoverability

Cons: macOS/Linux only, requires maintaining formula

Implementation: Create homebrew-tap repository + release workflow

3. Shell Script Installer ⭐⭐⭐⭐

Installation: curl -sSL https://install.mcp.io/publisher.sh | sh

Pros:

• One-liner installation like Docker, k8s
• Works across all platforms
• Can detect architecture automatically
• Can install to common PATH locations

Cons: Users cautious of piping to shell

Implementation: Host script that downloads from GitHub releases

🔄 Additional Options

4. Go Install (if open source) ⭐⭐⭐

Installation: go install github.com/modelcontextprotocol/registry/cmd/publisher@latest

Pros: Go developers expect this, automatic updates
Cons: Requires Go toolchain, slower adoption
Implementation: Ensure module is properly tagged

5. Package Managers (apt/yum/chocolatey) ⭐⭐⭐

Installation: apt install mcp-publisher / choco install mcp-publisher

Pros: Native OS package management
Cons: Complex approval processes, maintenance overhead
Implementation: Submit to each package repository

6. Container Image ⭐⭐

Installation: docker run --rm -v $PWD:/workspace ghcr.io/modelcontextprotocol/mcp-publisher

Pros: Consistent environment, you already use containers
Cons: Docker requirement, CLI UX friction
Implementation: Add publisher Dockerfile + registry push

7. NPM Global Install (creative option) ⭐⭐

Installation: npm install -g @modelcontextprotocol/mcp-publisher

Pros: MCP server devs likely use npm, familiar UX
Cons: Requires Node.js, unusual for Go tools
Implementation: Create wrapper package that downloads binary

---

🎯 My Recommendation: Start with #1 + #2 + #3

Phase 1 (easiest, biggest impact):

1. GitHub Releases - Add automated releases to your existing CI
2. Shell installer - Simple script that downloads from releases
3. Homebrew tap - Create custom tap for faster iteration

Phase 2 (broader reach):
4. Add to official Homebrew core
5. Submit to apt/chocolatey if adoption grows

This gives you:

• ✅ curl -sSL install.mcp.io/publisher.sh | sh (all platforms)
• ✅ brew install modelcontextprotocol/tap/mcp-publisher (macOS/Linux)
• ✅ Manual downloads from GitHub releases
• ✅ Builds on your existing infrastructure

The beauty is each method can reference the same GitHub release artifacts, so you build once and distribute many ways!

Todo List:

• Analyze current project structure and build system
• Research common Go CLI distribution methods
• Suggest multiple installation approaches with pros/cons
• Provide recommendations based on best practices

[rdimitrov]

@domdomegg - I can help with publishing to brew 👍 We can use a custom tap for now and then have this in the upstream brew formula. The difference would be between brew install modelcontextprotocol/tap/mcp-publisher vs brew install mcp-publisher.

PS. I did that for toolhive and a few other go projects already via Goreleaser (it's a really nice project)

[domdomegg]

Nice! Do we even need a custom tap or could we try to get it into the main repo?

I've never used Goreleaser but looks reasonable and happy for you to set this up.

[rdimitrov]

My approach so far was always to start with a custom tap and then move to the main repo once I'm certain we nailed the release process.

I have to double check to see if they have some restrictions around how old should the project be before they accept maintaining/advertising a formula on their side.

Once we have it on homebrew-core this would make it even easier because then it's all going to be automatic, i.e. we do a github release -> brew has a cron job running every few hours that scans for new releases -> updates the manifest to point to the new assets automatically and that's it.

[domdomegg]

I think according to https://docs.brew.sh/Acceptable-Formulae we meet the requirements. These seem to be the core things:

The software in question must:

be maintained (i.e. the last release wasn’t ages ago, it works without patching on all Homebrew-supported OS versions and has no outstanding, unpatched security vulnerabilities)
be stable (e.g. not declared “unstable” or “beta” by upstream)
be known (e.g. GitHub repositories should have >=30 forks, >=30 watchers or >=75 stars)
be used
have a homepage
We will reject formulae that seem too obscure, partly because they won’t get maintained and partly because we have to draw the line somewhere.

We frown on authors submitting their own work unless it is very popular.

I think it would be a better experience to be in homebrew core, and MCP is very popular (66k stars on servers, 2.2k stars on registry).

That said plausibly we don't meet the 'stable' or 'be used' requirements out of the gate, and maybe we fall under the clause 'frown on authors submitting their own work unless it is very popular'. Happy to go with custom tap first if we are worried about this - could coordinate with the Homebrew folk to see what they think.

[rdimitrov]

Process-wise I guess it would be easier if we try with core first and if they reject us for now we can default to the tap. What I mean is for the tap approach we'd have to create a separate repository in the modelcontextprotocol, create a token from someone's account that has write rights on it), set that token as a secret in this repository and then use it from our CI so goreleaser can publish the formula to it. It's not difficult per see, but if we have it in core we would save ourselves all of this making it much simpler 👍

[rdimitrov]

Status update: Once #366 gets merged and we verify the release process is working we can proceed filing a PR against homerbrew-core with a formula for mcp-publisher 👍

[rdimitrov]

Filed a PR against homebrew-core for publishing the mcp-publisher CLI - Homebrew/homebrew-core#236635