Repository navigation
Make mcp-publisher available to people easily #358
Description
Activity
@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.
Reacted by claudeClaude 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-publisherPros:
- 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-publisherPros:
- 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 | shPros:
- 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@latestPros: Go developers expect this, automatic updates
Cons: Requires Go toolchain, slower adoption
Implementation: Ensure module is properly tagged5. Package Managers (apt/yum/chocolatey) ⭐⭐⭐
Installation:
apt install mcp-publisher/choco install mcp-publisherPros: Native OS package management
Cons: Complex approval processes, maintenance overhead
Implementation: Submit to each package repository6. Container Image ⭐⭐
Installation:
docker run --rm -v $PWD:/workspace ghcr.io/modelcontextprotocol/mcp-publisherPros: Consistent environment, you already use containers
Cons: Docker requirement, CLI UX friction
Implementation: Add publisher Dockerfile + registry push7. NPM Global Install (creative option) ⭐⭐
Installation:
npm install -g @modelcontextprotocol/mcp-publisherPros: 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):
- GitHub Releases - Add automated releases to your existing CI
- Shell installer - Simple script that downloads from releases
- 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 growsThis 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
@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-publishervsbrew install mcp-publisher.PS. I did that for toolhive and a few other go projects already via Goreleaser (it's a really nice project)
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.
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.
Reacted by adam jonesI 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.
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 👍Reacted by adam jonesFiled a PR against homebrew-core for publishing the mcp-publisher CLI - Homebrew/homebrew-core#236635
Reacted by adam jones and Tadas Antanavicius- added a commit that references this issue
on Sep 9, 2025 We're in homebrew core 🎉
Thanks @rdimitrov for the excellent work here, and @chenrui333 for the docs updates 🙌
Reacted by Radoslav Dimitrov and Tadas Antanavicius- added a commit that references this issue
on Sep 12, 2025
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-publisheror similar. Not sure what the best ways are to do this though (GitHub releases maybe?)