mcpm.sh - MCP package manager and registry

MCPM is what npm was to Node before everyone took package management for granted: a CLI plus a registry that turn "install this MCP server" from a JSON-editing chore into a one-liner. The CLI manages local servers; the registry at mcpm.sh/registry is the catalogue the CLI talks to. Either half works without the other, but the value comes from using both.

The thing it gets right that ad-hoc setups don't: you install a server once, globally, and then decide which clients see it via per-client config. That is the inverse of the default workflow, where each client gets its own copy of the server config and they drift.

Install

curl -sSL https://mcpm.sh/install | bash

If you'd rather use a system package manager:

brew install mcpm
pipx install mcpm
uv tool install mcpm
pip install mcpm

pipx and uv tool install are the cleanest for a Python-heavy machine - the binary lands in an isolated env without polluting the system Python.

The five commands you'll actually use

mcpm search <query>          # find servers in the registry
mcpm install <server>        # add to global config
mcpm ls                      # list installed servers
mcpm client edit <client>    # toggle which servers a client sees
mcpm run <server>            # execute the server (stdio by default)

mcpm run <server> --http exposes the server over HTTP instead of stdio - useful when you want to share one running instance across multiple clients on the same machine.

Profiles vs per-client config

A profile is a tag that groups servers. The split looks like this:

• Per-client config - "Cursor sees fs and github; Claude Desktop sees fs and slack."
• Profile - "My frontend profile is fs + github + figma; my oncall profile is grafana + slack + pagerduty."

Profiles are the right primitive when you switch contexts faster than you switch clients. Run mcpm profile create frontend, mcpm profile edit frontend to pick servers, then mcpm profile run frontend to bring up everything tagged that way at once. They compose with client config - you don't pick one model or the other.

Supported clients

Out of the box, MCPM manages MCP server config for:

• Claude Desktop
• Cursor
• Windsurf
• VS Code
• Cline
• Continue
• Goose
• 5ire
• Roo Code

Claude Code isn't on the official native list, but the registry entries themselves are client-agnostic - you can mcpm install <server> and wire the resulting command into Claude Code by hand.

When to reach for it

• You're managing more than three MCP servers and the JSON config files have started to disagree across clients.
• You want to share a curated server bundle with a teammate - mcpm is the only thing that turns "here's a list of servers" into something someone else can install in one command.
• You're building or publishing an MCP server and want it discoverable. The registry takes community contributions.

When not to

• You only run two or three servers and they're stable. Editing JSON once a quarter is fine.
• You need a hardened, audited package source for a regulated environment. The registry is open and community-driven; there's no audit disclosure or signing story documented.

Trade-offs to know about

The registry has no documented signing or supply-chain verification - installing a server is roughly as trusting as curl | bash. For internal tools that's fine. For production agents touching customer data, treat anything you install as code you'd review.

mcpm share <server> exposes a local server over a "secure tunnel" for remote access. That's useful for pair-debugging, but the docs don't go into the cryptographic details, so don't use it as your primary remote-server solution.

There's no documented self-hosted registry. If you need a private registry, you're on the do-it-yourself path for now - fork the registry repo, host the JSON, and point your CLI at it.

The MIT-licensed source and a single source of truth for server discovery are the long-term reasons this is worth standardising on, even with those caveats.